Sign in to follow this  
nicksaiz65

Making a fast, efficient main game loop for a 2D platformer?

Recommended Posts

nicksaiz65    200
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.

Share this post


Link to post
Share on other sites
lride    674
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]

Share this post


Link to post
Share on other sites
kloffy    1318
[quote name='jbadams' timestamp='1352087741' post='4997427']
Try reading through "[url="http://gafferongames.com/game-physics/fix-your-timestep/"]fix your timestep[/url]" and "[url="http://www.koonsolo.com/news/dewitters-gameloop/"]deWiTTERS game loop[/url]". [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
[/quote]

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

Share this post


Link to post
Share on other sites
doyleman77    367
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)?

Share this post


Link to post
Share on other sites
L. Spiro    25617
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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this