Hi Guys! My question is simply: What kills the performance of a game? What makes it run slowly and what should i be aware of when coding the game? -Thanks

Poor designs, naive designs, & really crappy implementations.

Poor implementation of object orientation is often a culprit (that''s not saying that object orientation slows it down if you do it correctly), inefficient algorithms (why do you need to calculate the square root 500 times a frame, why not store it after you get it, type of things, heh), avoid massive deferencing, precalculate everything you can so that it doesn''t have to be done during run time, not remembering that C and C++ have lazy interpretors, using for loops where pointer incrementing while loops work just as well, et cetera .

"Finger to spiritual emptiness underlying everything." -- How a C manual referred to a "pointer to void." --Things People Said

http://www.gdarchive.net/druidgames/

Yep... definately agree with this one.

I''m working on a project at the moment, and my frame rate dropped from 60fps to 30fps with only 20 lines of code for some collision detection.

Why? Because I forgot that the thing I was testing the collision on never moved out of the middle of the screen, but I was calculating it''s space anyway.

Ripped out all of that, precalculated it once and hey, back up to 60fps again... and gave myself a big slap about the head as well for not thinking properly from the outset!

Collision detection and AI is probably where you will lose the most performance and they are extremely processor hungry. Simplify where you can (there is no point in doing accurate detection on a dodecahedron when a sphere would suffice is there?)

BE WARNED!!!


-- And that''s my $0.02 worth --

Hang on, where I come from, $0.02 is rounded down. Does that mean my opinion is worthless or priceless?

Talent²

These two are equally bad at slowing down games:

while( 1 );

Use LINUX

Yours sincerely,

Benjamin Wise
CEO Fractal Dreams of Digital Polynomials

In my experience, "The last thing you check".

I highly suggest getting the NuMega suite of tools if you''re working with MSVC. From what I understand, it''s fairly cheap, and TrueTime and BoundsChecker just rock.

Remember the 80/20 rule-of-thumb: 80% of your execution time is probably happening over 20% of your code. Spend your energy optimizing that 20%, and leave the rest to interns. Heheheh.

There are a lot of things that could hurt performance. Too much time done for bounds checking, as psychic_treason mentioned can be a bear. Also, not freeing your objects when you are finished can cause memory leaks which eventually lead to Virtual Memory issues and disk thrashing. These are two of the easiest to spot. You can also look performance in other ways, inefficient use of recursion, and function calls can cause you to loop longer than you need to. Too many alloc/deallocs lock up time as well.

There are a lot of good articles on performance, like is it better to make use recursion (void me(){ //stuff void me()) or use iteration (while(...)). Which sorting algorithms are the best - quick, binary, bubble. Take a look around, I''m sure you will find some good tips on how to keep things speedy.



-----------------------------
kevin@mayday-anime.com
http://www.dainteractiveonline.com

you know what would be cool? If there were some optimization game. Like you get a small game which has been intentionally written in an unoptimized manner...some things would be obvious, and others would be not so obvious. The trick writing it though, would be to make sure no functions would have to be re-written after being optimized. To avoid having the project fall apart.

Then there's always poor optimisations, or rather pre-mature optimisations. As Michael Abrash states in one of his books on the subject, "Assume nothing". As a programmer that has been around for a while it is important to understand that optimisation tricks changes with hardware, so what was the best way to do things a couple of years ago may very well be the worst thing to do now. This is why pre-mature optimisation is dangerous, it is usually not very well thought through, and is based on what the programmer believes (read: assumes) to be fast, it may very well not be. At the same time the optimisation may very well go where it is quite unnecessary since the programmer puts it where he believes (read: assumes) the code is too slow, it may very well be code that hardly gets executed. Besides it also tends to make the code ugly.

A good example of optimisation rules that changes:
A couple of years ago it was all about look-up tables (LUTs) - don't calculate, look up. Today with the extremly fast CPUs (at calculating stuff) and the big cost of cache-misses, the rules have changed - don't look up, calculate. Now this doesn't mean that you should never use LUTs, since some calculations are still too slow, but be careful not to overuse it. And as the caches grow, the rules may very well change again....

Edited by - amag on March 9, 2001 3:44:16 AM

quote:

---

Original post by psychic_treason
I''m working on a project at the moment, and my frame rate dropped from 60fps to 30fps with only 20 lines of code for some collision detection.

---

Sounds like vsync. If your system cant handle 60fps but it can handle, say 50 fps, then it will run at 30fps. Disabling vsync will allow it to run at the framerate its capable of doing.