   game speed tricks and traps
  I am learning a bit about 2D sprites and 3d stuff ATM with directx/c++.My prog has a frames per second counter I made (timegettime) which runs about 600-700 fps so far. I believe it only needs 30-60 FPS to be real time.I added a if statement which make 4 comparisons with an array against  a variable. This slowed my game down by 200-400fps, also the fact some array elements were accessed and didn't exist (and it still ran). What things do you avoid that slows the game down.Are vectors slow or 2d arrays, an array of object pointers etc.Does OOP effect the game speed much. I much prefer OOP comapred to C style but I use the C style for learning purposes first.   
  If you graph the function (1/x) you will see that it is not a linear function...this is the nature of measuring 'frames per second.'  What you really want to be looking at, when going from an 'empty' application to gradually adding functionality, is the 'seconds per frame' variable (the 'x' parameter of the function stated above).  A linear change in the seconds per frame does not result in a linear change in frames per second.I consider 'vectors' (I assume you mean std::vector) to be about as cost inefficient as a dynamic array (accessing data through a pointer requires 2 lookups: 1 to get the memory address, another to get the variable once the system has its memory address)...as long as you don't go out of control, using vectors can be just fine.As per using OOP as it relates to speed, well, you'll hear a lot of people telling you of the overhead of using OOP, especially in the case of inheritance and virtual functions, etc...again, this is because of pointers, and the fact that accessing data or a function through a pointer is more costly than any 'static' data.  However, if your design is efficient, this is a negligible 'problem.'   ;  Beginners worry too much about frame rate and optimization. Optimization is not a beginner subject. It requires knowledge and experience to optimize effectively. If you are a beginner and your game runs at 30 fps, then that is good enough. There are more important things to worry about.On the other hand, if your frame rate is under 30 fps, then you probably need some help. Either something is really wrong, or there is a much better way to do what you are doing.;  So how do you do things the right way to begin with if we aren't supposed to worry about framerate until were more advanced? it would be an awful waste of time to completely rewrite a program to make it more efficient in order to increase framerate when we could simply to everything right to begin with.   ;Quote:Original post by _Sauce_how do you do things the right way to begin with...?Minimize swaps per frame.Batch everything possible.Optimize GPU + CPU + More than 1 CPU (let them all run at the same time);Quote:Original post by _Sauce_So how do you do things the right way to begin with if we aren't supposed to worry about framerate until were more advanced? it would be an awful waste of time to completely rewrite a program to make it more efficient in order to increase framerate when we could simply to everything right to begin with.Doing everything right is not 'simple'. It's far more important to a) get stuff working, and b) do program design 'right' before ever worrying if it's fast. And really, what you think is 'right' now will quickly change as you learn.   ;Quote:Original post by _Sauce_So how do you do things the right way to begin with if we aren't supposed to worry about framerate until were more advanced?You don't. :)You have plenty to worry abotu, without ensuring you get the design "right" the first time around.Quote:it would be an awful waste of time to completely rewrite a program to make it more efficient in order to increase framerate when we could simply to everything right to begin with.Easier said than done though. In practice, it tends to be a lot easier to first write the program *as good as you can*, and then rewrite it to fix the flaws from the first iteration.That's called refactoring, and it's a pretty damn important concept if you ever hope to make programs more complex than Hello World. [smile]Trying to get everything right to begin with just ensures one thing. You'll never get anything done. Guaranteed... And then you can *really* start worrying about an awful waste of time... [lol]However, there's nothing wrong with asking about the performance impact of different features and paradigms. Just don't try to make everything "the best" way to begin with.So yeah, don't worry too much about performance, unless you start dipping below, say, 30FPS.About vectors, they can be just as fast as an array.However, in Visual Studio 2005, they perform bounds-checking on the [] operator, which carries a bit of overhead.You can disable this behavior by defining some macro (can't currently remember what it is)OOP doesn't really matter. Yes, inheritance and other OOP features have a bit of overhead, but you'd get the same overhead if you were to implement the same functionality in a non-OOP manner. And when you don't use those features, OOP is just as fast as non-OOP.   