5 replies to this topic

[nicksaiz65]

I have recently finished a level editor that I plan to use to create levels for a 2D platformer that I am working on. Now, I am working on a program that will actually play the levels and let the user play them. However, I intend to sell this game, so it will need to be fast, and run the same speed on all computers. For it to do this, the main game loop will need to be structured well. I understand I will need to use timers, especially for rendering the game, but what would be the best way to go about this? Also, does it matter what order I do the tasks in? For example, should I take their input before I draw them? When should I test if they are on solid ground? Also, I am programming in Blitz Plus, so pseudocode would be appreciated if possible. Thanks.

[lride]

You should calculate how much time has passed between each frame and use that time to update your game
And if you are running some physics, it is good idea to use fixed fps. To do this you can create some delay between each frame if a frame is finished early.
Every game loop will look similar to this
[source lang="cpp"]while(GameIsOn){ handleEvent(); update(delta_time); draw();}[/source]

[jbadams]

Try reading through "fix your timestep" and "deWiTTERS game loop".

[kloffy]

Try reading through "fix your timestep" and "deWiTTERS game loop".

Classic articles, especially the Gaffer one.

After reading deWitter, I am wondering: Is it really fair to say that the "constant game speed" solutions help with input response time on slower machines? The article certainly seems to suggest that, stating it as a flaw of the other approaches. Furthermore, this idea is reinforced by the notion that your game logic will be independent from your rendering. However, what you are really doing is giving your physics simulation time to catch up if the rendering is running slow. The catching up is done in a rapid sequence of fixed-length incremental steps. If I am not mistaken, the main purpose of this is to make sure that your simulation is well behaved. However, this should not really affect input response time, right? In a sense, the simulation is running in virtual time, whereas user input happens in real time.

Either way, it is a good article on an interesting topic. The intent of my post is to verify that my understanding is correct and to help others that may be confused.

Edited by kloffy, 05 November 2012 - 09:26 PM.

[doyleman77]

this is where it confuses me. at a certain point, the articles lose me on exactly what model I should be using on certain scenarios. from what I gather, though, it's almost always better to just use a fixed frame rate (ie 30 - 60)?

[L. Spiro]

Fixed frame rate or fixed logical-update rate?
They are not the same thing. The frame rate should be whatever it can be. Logical updates should be fixed (usually to around 30 times per second).


L. Spiro