As I see it, there are 4 ways people do timing. Can someone tell my why my opinions are wrong here? 1. Simple fixed rate timer Basically, the game waits for x ms to expire before processing the game loop. Pros: The easiest to implement Cons: Unless your internal timer is the same as the refresh rate, it will not be silk smooth. Example: Platypus, Demonstar My Opinion This is very basic, but it works. Lots of new coders use it. 2. High frequency internal timer, render at refresh rate This is where the game runs internally at, say, 250 fps and will run its game logic the needed amount of times to keep up with the refresh rate. Pros: Fairly easy to implement, very precise collisions, silk smooth in most cases. Cons: Some refresh rates are not 100% smooth, depending on internal frequency. If internal logic rate exceeds the internal fps, the result will be a nasty slowdown. Not efficient. Examples: Bricks of Atlantis, Bugatron, Pocket Tanks My Opinion This works surprisingly well. I used it for Cosmo Bots and it always appears smooth. However, in my games, my internal logic is always so simple that it can never get to the "Nintendo Slowdown" point. And I cap it to avoid this. Still, in low fps-situations, you are burning a lot of cycles for the game's logic that aren't really necessary. 3. Delta Value Timing This is where the game runs as fast as it can, and the "amount of time passed" is sent to the logic loops and objects move at their speed*time_passed. Pros: Always silk smooth, works even in very low fps situations, easy to implement, efficient. Cons: Can be tricky with physics/collisions, can make code messy Example: Heavy Weapon, Lego Builder Bots My Opinion Although it's easy to get in there, it means that time is factor in all movement- basically adding another variable to deal with. This causes the code to be more messy in the long run. Also, it's really tricky to get stuff like acceleration to work exactly the same on all computers. If you can deal with all that, it is smooth though. 4. Low internal fps with tweening This is where the game runs very slowly internally, say 25 fps. And smooths the rendering between the last two frames based on a time variable. Pros: Efficient, silk smooth, easy physics. Cons: Tricky to implement, inprecise collisions Examples: Best Friends, Quake 2 My Opinion This is my favorite method. It's efficient and looks nice. The only problem I have is that getting it to work "just right" takes a lot of fiddling- especially when objects become visible for the first time. I recently switched my current project from #2 to #4, and it wasn't fun, but it's working good now. In high fps situations (geforce card, etc) I see no actual difference though. On the low end, it does seem to run a bit better.