When creating a game loop, what are the most important factors to consider timewise?
Printable View
When creating a game loop, what are the most important factors to consider timewise?
Be careful on loops inside loops: check the inner loops and see if you have values there you could calculate before the loop. Add more variables if you need them so you don't recalculate things that are often. Also use lighter calculations when possible, ie. use Value * Value instead Value ^ 2 or Value + Value instead of Value * 2.
For basic VB6 optimization I have written a FAQ. It might be handy when you are looking for basic elements in your code that could be made faster.
In the end, the basics and facts of optimization:
- use the lightest methods mathwise (= easiest for CPU to calculate)
- check for the actual amount of calculation you are doing: see how much you can do in advance and do only what you really need to do
- avoid using techniques that are known to be slow
- more code is often faster than short code (with what I mean: more code = simple stuff, only necessary calculation; short code = advanced, slow functions or extra calculation)
Ok, thanks.
Now, on the math, say I have to multiply a value by something like 32. Will it actually be faster to type out val + val + val ... 32 times?
Also, I've heard that using classes to store and work with data is slower than just storing data into UDT's. Is this by a significant factor? What setup for data or code structure is going to yield the greatest speed?
Also, be sure to lock the framerate at at certain FPS, such as 60.
No: each operation does add up into the execution time, so there is a certain point when adding up becomes slower than doing a single multiplication. However, you could do this kind of trick to keep the count lower:Quote:
Originally Posted by Nove
VB Code:
But it is probably still slower than using only * 32, so this trick might come handy only with lower multiplication amounts. Maybe a good idea to benchmark it sometime.
Generally the fastest should be just using plain variables all the time, but that would be insane with a bigger project. Also, there is never point in optimizing everything: the target is to find a good balance. If doing something as a class is really handy, you should go for the class module. Especially if the class would have a good amount of code. Of course you need to reconsider the memory usage: if you need a few thousand objects, you might consider doing it in a less memory consuming method.Quote:
Originally Posted by Nove
Also, I have found it generally good to first make something that works and then improve the code based on that experience. Doing something optimized right away, especially a thing you've never really done before, is rather bothersome as doing optimized code is very time consuming. It is first good to see the thing working.
For the FPS I have one tip that is not speed related: make internal FPS, ie. bullet and ship moving, have a higher FPS than the final graphics display FPS. This gives much better feel to an action based game, because even though every change doesn't appear to the screen, things in the background happen more accurately.
For example: internal FPS = 120, visual FPS = 60; bullets need to fly half the speed so collision detection is two times more accurate as well. And even if the visual FPS gets slower, the internal FPS should stay at 120, letting the game feel smooth. If there is not enough processor power, you can purely take it away from the visual FPS without affecting the internal game speed (unless the computer is so slow that it cannot handle the internal FPS stuff).
Ok thanks. A few more questions.
When you have reasonably small loops, is it faster to just type out the code?
In subs and functions, is there any speed difference between a byval or byref argument?
With my current knowledge, passing numbers ByVal is often faster than ByRef. However, passing strings is faster ByRef. And arrays you can only pass ByRef anyways. Though the speed difference is very small. The good thing about ByVal is the possibility to validate the variable directly by changing it if it is out of range. And the good thing about ByRef is the ability to edit multiple variables passed to the procedure. These things are good to consider when making own procedures.
Loops are faster when they're typed out, though the speed difference is remarkable only on very lightweight calculation that is repeated many times. So if the loop code is more than, say, 10-15 lines, I wouldn't type it out but keep it as a loop purely for clarity reasons. And most of the time is spent in the code within the loop anyways. You might find interesting differences between For ... Next loops and Do ... Loops if you benchmark reallife code samples: both have their own strong area.