🔒 Locked

Need help on performance problems

Started by itz_faraz Mar 14, 2005 at 1:08 AM 13 replies 2.5k views

Original Post

Mar 14, 2005 at 1:08 AM

Hello people Ive been working on a game similar to SimCity 4. Here's how it looks uptil now:

Please download from here the sample exe of the game so you can help me out in the below queries. The game is built in Visual Basic 6, DirectX 8.1, using orthographic projection. Supports terrain rotation, zooming, grid lines. I am very new to graphics programming and therefore I am already facing the following problems in which Im totally lost; dont know what to do about them: 1. I think the frame rate is not good enough in respect of the current game position. Its only a terrain right now, still not enough frame rate. (well, thats what I think.. what do you think?) The whole terrain is built in TRIANGLELIST format. All the vertices are placed into a single vertex buffer and Index buffer. Is this a good idea? Because thats just it.. only a terrain and a single vertex buffer. Still the FPS is not adequate enough. What is the best way? I thought of using quadtrees but got stuck in the idea that how would I perform ray-picking on it.. because my terrain is not flat.. if I click a mountain which is in the 2nd quarter, using quadtrees it might detect it as if I clicked in the 1st quarter. 2. The FPS gets lower everytime a house is placed on the terrain. I cant understand.. everything is quite simple in my code, but the game performance shows signs of high inefficiency. 3. Ive gone through all ends to figure out how to detect which tile the mouse is over on the terrain. I finally found that out but its not working very well. Its toooo slow. I first obtain the mouse screen coordinates, normalize them, and do the necessary stuff (inverting camera matrix, determining the ray direction, etc). And just to see which tile I clicked, I go through a long loop in which I create a plane using each triangle's coordinates and check if ray intersects it or not. (two triangles make up one tile.. so in the default map the terrain is of 42x34 tiles.. makes it total 1428 tiles, ie. 2856 triangles are tested on each mousemove event.. yuck!) 4. Im also having trouble with lighting the terrain.. but thats not a big issue so I wont discuess it here right now. - Thats it.. the above are the problems Im facing about which I have no clue how to solve them. Im a newbie at graphics/directx programming so I may be wrong about what I said about quadtrees.. thats what I need help of this forum to straight out my concepts. I have turned off the Day/Night mode in the game.. actually I have turned off all the lighting effects and now Im using lit vertices. Also read the Readme.txt in the zip file to all the keyboard controls. I can also provide the source code.. please help me out especially in the ray-picking issue.. its really bugging me. I was told that visual basic 6 is not a good language to build directx apps and it is the major cause of low performance. Well I believe its true but only in respect of high/powerful games, not in my simple game engine. What do you say? Faraz Azhar

itz_faraz

Mar 14, 2005 at 1:10 AM

PS. Click the 'B' button on the bottom-left panel of the game to build a house on the terrain.

Tarviathun

Mar 14, 2005 at 2:33 AM

The first thing that comes to mind is that you might be using the debug version DX, which would cause a large slowdown in performance. I haven't downloaded your program, the main reason it's 3:40am and I've still got hw to do.

Not sure what to say on the ray thing, right off. My brain isn't functioning too terribly well at this hour.

itz_faraz

Mar 14, 2005 at 4:09 AM

Quote:
Original post by Tarviathun
The first thing that comes to mind is that you might be using the debug version DX, which would cause a large slowdown in performance. I haven't downloaded your program, the main reason it's 3:40am and I've still got hw to do.

Not sure what to say on the ray thing, right off. My brain isn't functioning too terribly well at this hour.

Ive heard a lot of people on this forum and other places that there is an icon in the control panel which allows the debugging level and retail/debug version support for DirectX. Since I have DirectX 8.1 SDK for VB6 installed on my system and DirectX 9 is also installed (not the SDK) and Im using WinXP SP1, I dont see any icon there.

And what difference would it make in my programming if I were using Retail version instead of Debug version? Whats so special about debug version? The maximum detail about debug error that it gives is "Automation Error". Furthermore, I was told by someone else, who tried this game of mine on his system, that the FPS is low.. I dont think he has debug version installed.

Tarviathun

Mar 14, 2005 at 6:35 AM

Alright, so maybe you coded it poorly. That was the first thing that came to mind. The special thing about the Debug version is that it allows you a whole lot more information on the program running. You have to output it yourself, catch you're own errors, but it allows you a whole lot more flexibility in the actual debugging process. That extra crap in there slows shiz down.

However, this doesn't really seem to be your problem. So, can't really help you too much there. I'm not a VB coder, I'm a C++ guy. All I can really say is, if your problem is determining where your mouse clicks in your world, then try a different method. I don't know what that'd be, I don't do stuff in isometric. But I love stating the obvious, so there it is.

itz_faraz

Mar 15, 2005 at 12:43 AM

nobody else got anything to say ? any advice?

kburkhart84

Mar 15, 2005 at 9:53 AM

Just how low is your FPS. That and how many tris are you drawing? The visual basic language is slower than C++ usually, but not by such a margin that it is unusable, especially if you are using DirectX or OpenGL with hardware accelerated graphics. Look at how much you are actually drawing. Also, What are your system specs. Maybe for some reason it is drawing everything in software mode who knows.

EDI

Mar 15, 2005 at 10:43 AM

Are you sorting by texture?

if you arnt then the worst case scenario, is that you are doing, a SetTexture and a DrawPrimitive call for each tri/quad.

a better aproach to this, is to sort your quads based on the textures they use, this way, you can potentially render a bunch of tris with only a single SetTexture, and given that the tris will be sorted it means they are adjacent to one another in the Vertex Buffer, so you can use a single DrawPrimitive call to draw a bunch of them.

I get the feeling that you are already doing this, but if you arn't then it is likely the culprit.

davidx9

Mar 15, 2005 at 10:57 AM

Make sure you only have the functionality you need enabled. My prog was really slow until i realised i was alpha testing every poly, i restricted alpha to only when i needed it and my fps increased by 100.

Alpha is just an example in my case, perhaps you have other things you don't need enabled. Try to batch all of your rendering, and use small textures if possible, or have multiple textures within one image, and let the tex coords sort it out.

itz_faraz

Mar 16, 2005 at 6:16 AM

OK Im assuming you guys havent seen the demo yet.

All in all (excluding the GUI) I have these things which are drawn in every render call:

1. The whole terrain is in one single vertex buffer. Terrain is built on TriangleList format. So There is only one call for SetTexture and DrawIndexedPrimitive for the whole terrain.

2. Then there are two separate vertex buffers for the two side-crusts. One SetTexture call, and two DrawPrimitives (no index buffer here)

3. Then there is the background grid. It is only a single quad of a very large size and texture contains a square shape. So to create a grid, texture is repeated about 100 times on that quad. One SetTexture call and one DrawPrimitive call.

Thats it. All in all.

Im not sure about the FPS. I think the FPS is ok. Thats why I wanted you guys to check the demo and see that with the above kind of geometry, is the FPS ok or not. Thats what I wanted to ask.

I have solved the ray-picking problem.. was simple maths but couldnt figure it out. :)

GCoder

Mar 16, 2005 at 6:46 AM

Well, I ran the demo...

I left it in the default resolution on my machine of 1600 x 1200...and it sat there for a very long time on your loading screen until I finally pressed enter and it closed down. Upon trying a different resolution (640 x 480) the loading screen came up and an error dialog box popped up saying "COuld not initialise graphics adaptor. Please run settings.exe ....."

The log file states :

"ERROR: Device creation failed, falling back to Software Vertex Processing...
Device creation failure!
->VB Error: Automation error
->DirectX Error: D3DERR_NOTAVAILABLE "

it's a crummy GeForce 4 MX 440 so it's not surprising. Thought I'd just let you know anyway. Perhaps you have some sort of hardware dependant feature enabled? (I hate this MX440 so much!!! - Work card :o\)

GCoder

itz_faraz

Mar 17, 2005 at 4:33 AM

Quote:
Original post by GCoder
Well, I ran the demo...

I left it in the default resolution on my machine of 1600 x 1200...and it sat there for a very long time on your loading screen until I finally pressed enter and it closed down. Upon trying a different resolution (640 x 480) the loading screen came up and an error dialog box popped up saying "COuld not initialise graphics adaptor. Please run settings.exe ....."

The log file states :

"ERROR: Device creation failed, falling back to Software Vertex Processing...
Device creation failure!
->VB Error: Automation error
->DirectX Error: D3DERR_NOTAVAILABLE "

it's a crummy GeForce 4 MX 440 so it's not surprising. Thought I'd just let you know anyway. Perhaps you have some sort of hardware dependant feature enabled? (I hate this MX440 so much!!! - Work card :o\)

GCoder

I also use GeForce 4 MX440. Have you tried many (if not all) screen resolutions? I think I remember that 32 bit mode for 640x480 & 800x600 cause problems. Try 16 bits too.

My initialising code is very designed such that it checks for availability of everythng before creating a device. It checks the validity for screen resolution, enumerates depht buffers and picks the best one, checks the vertex processing types (pure, hardware, software). And even if the create device fails at this position, it tries creating again using software vertex processing. Shouldnt cause problems.

I usually work on 1024x768x32 resolution on my GeForce 4.

digital_phantom

Mar 18, 2005 at 3:21 AM

I ran your demo on my computer and this was the results for me.

* In 640x480 resolution, the game ran as 160fps
* In 800x600 resolution, the game ran as 90fps

This is because I believe that there is way more stuff to draw,
but when you zoom in the game gets slower.

* When clicked the mouse's middle button, the game crashes.

* The sun effects and such does not work, I click the sun icon
and nothing happens.

* For determining which tile the mouse is over, your using the
way I'm doing it for my real-life simulation game.
But there is a method I believe would be faster but I ran into
a problem with it. Have you ever programmed a tile-based game
like a RPG? Well to determin what tile the mouse is over
you would take the mouse coords (x,y) and divide each coord
by the tile size. Tile.X = (Mouse.X / 32). There is more adjustment to
do that value, but roughly that gives you the X tile the mouse
is over.

If you need me for anymore information feel free to e-mail at
vbmaul@yahoo.com , I would be glad to help.

itz_faraz

Mar 21, 2005 at 3:41 PM

Quote:
Original post by digital_phantom
* When clicked the mouse's middle button, the game crashes.

No idea why that is happening. I havent coded at all for mouse middle button. And Im not even using DirectInput, Im using plain GetAsyncKey api.

Quote:

* The sun effects and such does not work, I click the sun icon
and nothing happens.

Yes its turned off. Ignore that.

Quote:

* For determining which tile the mouse is over, your using the
way I'm doing it for my real-life simulation game.
But there is a method I believe would be faster but I ran into
a problem with it. Have you ever programmed a tile-based game
like a RPG? Well to determin what tile the mouse is over
you would take the mouse coords (x,y) and divide each coord
by the tile size. Tile.X = (Mouse.X / 32). There is more adjustment to
do that value, but roughly that gives you the X tile the mouse
is over.

Ive searched just about everywhere but I cant find a good method of determining which tile the mouse is over. The suggestion youre giving is only good for transformed graphics (fixed sizes, and pre-determined positiions of tiles and other objects; all in 2D coordinates) Im using actual 3D orthographic projection.. so cant use this method here. Well... thats what I think. Am I wrong? Any better way to solve this problem.

Solias

Mar 22, 2005 at 12:42 PM

Quote:
Original post by itz_faraz
Ive searched just about everywhere but I cant find a good method of determining which tile the mouse is over. The suggestion youre giving is only good for transformed graphics (fixed sizes, and pre-determined positiions of tiles and other objects; all in 2D coordinates) Im using actual 3D orthographic projection.. so cant use this method here. Well... thats what I think. Am I wrong? Any better way to solve this problem.

Well yes and no. As long as you are using an orthographic projection and your tiles are the same, you could use the same logic a 2d tile based game would use to calculate tile coords from screen coords. You are both putting a regular tile pattern into screen space.

The problem is that your tiles are not flat in the x,y plane, they have a z component (assuming that z is "up"). This means that more than one tile can "own" a given part of the screen, one will be drawn in front of the other. This problem actually exists for sprite based games as well if they support multiple heights.

In your case there is a well defined mapping between screen space and world space, which is inverse of the transform and projection matricies you applied to the terrain when you rendered it. The problem is that a point in screen space will become a ray in world space. One option would be to read back the depth value stored in the depth buffer and use that as the z coord for the window, then transform that value back into 3d space. The Opengl utility lib provides a helper function for this, d3d might have something similar in it's utility lib.

Another option would be to partition your terrain in 3d space such that you only need to test the tiles that could intersect the ray. An oct or quad tree could work for this (the quad tree would need to test against the projection of the ray), but you need to be careful that the overhead of the partition is worth it. You could also use this for culling portions of the terrain that are off screen when drawing.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.