Need help speeding up my code....

OpenGL OpenGL: Basic Coding
1

I was just wondering if anyone would be willing to look over some code I had to see if they could find out why it’s running so slow. I’m working on a 3D Bomberman clone (who hasn’t done one of these?) in GLUT as my first OpenGL/GLUT project and I’m fumbling my way through, but would like some guidance from some of you graphics gurus out there. The code can be located at http://www.bcyde.com/bomberdraw.zip .

I have a few ideas where things should be sped up (in the drawmap background function where I draw the breakable bricks), but I’m unsure what the best ways of doing it are instead of checking the map array every frame. Keeping the breakable blocks in their own vertex array seems a bit tricky since they can be blown up and array elements would have to be re-ordered and removed.

Any help would be greatly appreciated. **Note, the code is GLUT in a Visual C++ workspace, the machine I am using is P-III 600 with a Matrox G400.

[This message has been edited by bcyde (edited 11-01-2001).]

2

I’m not sure if anyone is going to be willing to do all the hard work to tune your application. But here is the standard way to optimize code.

Profile before optimizing. How are you going to speed things up if you don’t know what to speed up?

Find out if your application limited, transform limited, or fill limited. Then figure out how your gonna fix that problem.

Here’s a link to help you out: http://www.opengl.org/developers/code/sig99/advanced99/notes/node343.html

SL

3

Thanks for your reply. I agree with what you said about not finding many people willing to look at my code, but I figured I’d just give it a try especially since there really isn’t much going on in the code yet. It basically just loads a map from a text file and draws textured cubes, that’s why I figured I’d give it a shot. Anyways, thanks again for your input and I’ll try following the advice in the link you posted.

4

I looked at it. Seemed to run fast enough for me. Though I did notice a few bugs in your keyboard handler, and I thought it odd that you are using 3D geometry with an orthographic projection.

[This message has been edited by DFrey (edited 11-01-2001).]

5

Thanks for taking the time to look at the code. Yeah, I haven’t done anything with perspective yet (but I’ll probably do that next). I was wondering what type of system you have (processor and graphics card) and if you noticed any glaring wasteful functions or stuff that’s just plain wrong (other than the keyboard stuff). Thanks again, I really appreciate it. Oh side note… sorry for the really ugly textures that don’t match, I just grabbed whatever I could find to test texture mapping…

[This message has been edited by bcyde (edited 11-02-2001).]

6

The DrawBlock function could be changed so that you use a display list to hold the block, and then use glScale*() & glTranslate*() to place it. This will dispense of the statements like (i*BLOCKSIZE). This is generally quite bad because you are making the same calculation a number of times, why not just do it once and then store the value? Alternatively, by creating a unit length object in a display list, you can pass the sizing and positioning calculations to tnl hardware, again saving you a bit of time.

//Ian says C++ shouldn’t use switch statements, but what would be better in this case?
tell ian to read a book on C++! I’d like to see his if/else statements!!


glTranslatef ( (map.GetMapWidth() * BLOCKSIZE)/2, (map.GetMapHeight() * BLOCKSIZE)/2, 0);

does this ever change? doing repeated calculations again…(not that it’s severe)

To be honest, the code has a long way to go before you’ll encounter speed problems. Generally it’s pretty clean.

7

The system I used has the following spec: 700 MHz Duron, TNT, Win98, and was set 32 bit color. With respect to the code, its hard to say, since I’ve never played Bomberman I’m not quite certain what would be the best way to arrange the code. But with repsect to this code I looked at, I did not notice any geometry changing. For each block, each vertex was fixed with respect to all the other vertices of the block. This suggests a display list would be best used in this case. Now this assumes the blocks are always opaque. If some blocks are transparent then the transparent blocks would best be made using a vertex array of depth sorted triangles.

8

Don’t mean to clog this thread with “thanks for the reply” posts, but just wanted to let you guys know I really appreciate your help and time. I will be working on what you guys have suggested about the display lists.