You have to be very careful with your programming when your dealing with graphics... AND games. Small changes can make huge differences. Now, your problem is that you really need to sit down and find those small changes. If you are using VC++ I recommend that you become familiar with the profiler. Also, concentrate on your innermost loops. For example, you have a game loop with a loop to draw characters with a loop to draw rows of pixels with a loop to draw single pixels. Concentrate on that loop drawing pixels, until it can''t possibly get faster (this is a great case for assembly) then concentrate on the loop drawing rows of pixels (may still need assembly) and so on.

Also you can add it up to see how many times you''re hitting those loops... I''ve had loops hit 300,000 cycles per frame... sometimes more. Another thing is to become a do-it-yourselfer. It''s easy to use someone elses generic code to do a simple task but when that generic code has to take into account display, system settings, alignment of the planets and the whereabouts of Hoffa''s corpse, your program gets bogged down.

Back in the day I''d write game code in a matter of a few hours and then spend the next two weeks optimizing (of course, this was in the DOS days and puters were slow, I won''t even get into the headaches of my Apple II days).

Anywayz, getting to my point... there''s a huge difference between the code ya get out of a book and the code you spend two weeks to a month slaving over... and Baldur''s Gate, I''m sure, is a pretty far cry from the code in any How-to book.

I seriously suggest (if you''re really interested in game programming) that you sit down and hack that code, dig into your system, find out what all that "black box" code is really doing, remove the code you don''t need, revise the fundamental way you''re doing things and learn assembly... assembly is very easy, especially for most purposes and worth the effort if you want that lightning fast code =)

- Jay



Many of the truths we cling to depend greatly on our own point of view

Get Tranced!

I recently had this problem with opengl - and i think i know what you're doing wrong.

Make calls to glBegin() and glEnd() only when you absolutely have to. I wrote a 2d game in opengl running at 15fps - it was calling glBegin() about several hundred times per frame. After some thinking i got it calling glBegin() about 10 times per frame, and my fps shot up to 100.

Try to use display lists wherever possible.

Also remember that if you call glBegin() within a display list "compilation" it is called every time the display list is used.

Edited by - Spiral on December 20, 2001 9:51:21 AM

Well, I still don't get it. I mean, my point is that Baldurs Gate was programmed to work on computers that are even under 200 mhz(thats what I have), and it is huge, so one small mistake in OpenGL shouldn't really give me trouble to the point where I can't move the window.

Even the code I take *directly* from the "OpenGL Game Programming" book is pretty slow, so I guess that it is more to the fact that I have a slow computer. But still, if a large 2D game can run with very litte "lag", then I think an SDL application where two boxes collide should run pretty damned fast.

Maybe I should make less global variables and stuff. I'll figure it some day, I always figure it out when I need to .

How much of a difference does assembly make in a program anyway? And what kind of assembly would I want to learn if I was working with Windows, SDL, and OpenGL? (I have seen like 5 different types and that confused the heck outta me)

And one other question. Is it so much faster to load a bunch of 32x32 bitmaps opposed to a 640 by 480 bitmap? I would think so but I dont seeaa difference.

Edited by - Drizzt DoUrden on December 20, 2001 4:09:00 PM