Aragorn7

BackSurface.DrawFast(0, 0, MapSurface, Map.Rect, DrawFastFlags.DoNotWait) Change that to DrawFastFlags.Wait See if that helps. Also, you probably shouldn't be using "Draw Fast". Try using BltFast().

Ya, I would wonder if you added some lighting in the future, and it went away. Sometimes the problem was that you didn't have any lights in the first place. But I really don't know lighting at all whatsoever...lol.

I have never done lighting in my life. I am currently working on a 2D game that doesn't have anything to do with lighting whatsoever. I suggest you look over your code and check for any little problems you might see logically. If you can't find anything, wait a day and look at it again, you are sure to find something new. If you can't find the problem after all of that, just continue with your project and hope that when you add your own lighting...it will all be fixed.

Installing DirectX runtimes? Or installing the SDK? Either way, I would search the Microsoft Knowledge Base for your solution. It seems like a wierd enough error that it might be covered in their knowledge center. Also...do you have service pack 2? That could cause problems also.. -_-

If you are a beginner to DirectX/Drawing API's in general, you will probably want to learn directX first. DirectX9 is a lot easier, but once you learn DX8/9 it will be a lot easier to learn OpenGL. OpenGL is really nice if you want to make a game run on Linux/Mac. I think warcraft3 used both...but you never really got to choose between them in-game. I know you can play it on Mac, so it has to support OpenGL or an equivilent.

PerspectiveFovLH(float, float, float, float) That makes sense, all of those should be floats. 'Viewspan in RADIANS 'Aspect ratio 'The nearest Z coordinate that is shown 'The farthest Z coordinate that is shown Another problem might be that MDX is pulling another error on you. They overload too many functions with that build. C# also might be different than VB.NET. @PentiumGuy: I use camera transformations simply because I like to control what the user can see. I don't use the sprite class though. ;)

I suggest you move the camera, not the actual stuff. Just move the camera and have a drawing system that only draws stuff that the camera can see. D3DDev.Transform.View = mCamera.LookAtLH( _ New Vector3(mCameraX, mCameraY, mCameraZ), _ [color=Green]'Where is the camera located?[/color] New Vector3(mCameraX, mCameraY, 0), _ [color=Green]'Where is the camera looking?[/color] New Vector3(0, 1, 0)) [color=Green]'Which direction is up? Positive Y coordinates are up in this case[/color] (Where mCamera is a matrix, D3DDev is the direct3d device) (mCameraX,mCameraY,mCameraZ are simply Single datatypes that define the camera position) This is how you transform the view sir... ;) NOTE: Make sure you initialize the camera before you do this however... D3DDev.Transform.Projection = Matrix.PerspectiveFovLH( _ 90 * (Math.PI / 180), _ [color=Green]'Viewspan in RADIANS[/color] 4 / 3, _ [color=Green]'Aspect ratio[/color] 1, _ [color=Green]'The nearest Z coordinate that is shown[/color] 50) [color=Green]'The farthest Z coordinate that is shown[/color]

Yep, I am surprised I forgot camera manipulation. Changing the camera can help a lot too....the less stuff the game can see...the better. ;)

You probably won't find anything easy. I suggest you try Winsock. http://www.vbip.com/winsock-api/default.asp I am sorry these tutorials are not based on VB.NET....but its the best I could find on a moments notice.

Yep, it really depends on example. For example (no pun intended), outdoor games that have huge rolling hills NEED fog out of necessity. If they don't have it, they will not be able to have a very large world to move around in. ;) For inside type games, you don't need fog at all. The walls hide the rest of the level from you...so there is no reason to waste FPS on fog. It all depends upon what you want to do.

It can allow you (the programmer), to reduce the visible distance further, thus reducing the amount of poly's needing to be displayed. This is used in a lot of games to actually increase the FPS because a lot less really needs to be drawn. It really all depends on how much stuff you have in the "world space" at once. If your game is fairly basic, you still will want to use fog to make it seem less fake as stuff "dissapears". Some games don't need to make stuff dissapear though...so in that case fog would decrease the FPS.

This is usually how DirectX or any API for that matter works. You learn bits and pieces at a time, but never learn it all.

Well, if I could edit it, I would say it would raise the FPS. ;) It was a typo....after writing 2 paragraphs about applied 3D graphics theory, you start to lose your mind. ;) You should definitely make it so that people can CHANGE the fog in the game though, because some people don't like fog, whereas I enjoy a little just to spice things up.

Most games have a sphere of influence around the player and certain things are displayed depending on how far away that player is from these objects. Grass and other static flare is usually a very small sphere, while players and bullets are almost always displayed (in FPS's). The best example of flare being used in a game so far is Tribes Vengeance. You just gotta have the game only draw stuff that is "of priority". So you have to set up a priority system and a state system that allows changes to the priority. Every priority of objects would have a specific sphere of influence. You might also wanna look up fog, that can lower teh FPS like crazy if done correctly.

Set the device = nothing when the application regains focus. Once you destroy the device, then you need to reinitialize it (and all of the textures too).

http://www.xtremedotnettalk.com/showthread.php?t=88192&page=2 Answer is there.

Yes, I suppose so....I hate windows mouse input, or is that keyboard input? Windows mouse input isn't half bad, but the keyboard input should be made using Direct Input.

That would be sweet if there was a way to use code to find out if direct X is installed...but I don't think it is possible. Simply because a program can't even run if certain references don't exist (ie directX). Maybe if you had a launcher program that didn't require directX and then somehow found out how to do it with code....

Ya, I would hope it didn't have any effect. If it did...I would be worried. ;) That is because when you have fullscreen, it gives you exclusive rights to the screen pretty much. Which means a really nice boost in speed. The reason why your paint trick works is not because loops are "slow", it is because GDI+'s paint() function is slow. When you override it like that, you are effectively speeding it up.

Booom! Im here.... I think it would own because, I don't like directX associated with GDI+ anyways. DirectX is just so much damn faster. ;)

In all honesty, I haven't come across one tutorial that didn't have its quirks. I think that it is part of the learning experience for them to have quirks. If you can fix the quirks, you have successfully "learned" the material.

You are correct on both points. Testing on a REALLY nice computer is sort of worthless...that is why you should work on optimization later on in the project when you can test it on a different computer. BTW, I would like to point out that VB.NET has AWESOME memory management. It is like 2.33 times better than VB6. Don't believe me? http://216.5.163.53/DirectX4VB/Tutorials/GeneralVB/GM_NETvsVB6.asp

Ya, I do know how to do that, but I didn't like the boxed in functionality. To update the interface, you can't just change the script, you have to recompile. That is what bothered me about interfaces. I still use an interface to expose the script, but only for certain initialization steps. Some day I will change it, but in the beginning of the program/game, you really don't know how things will turn out by the end. So you might end up recompiling that DLL 10000 times if you aren't careful.