Jump to content
  • Advertisement
  • entries
  • comments
  • views


Sign in to follow this  


Right. Based on the general feeling from the thread on the subject, I've decided that a fixed time-step physics update, seperated from the rendering, is the only viable way to write a 2D platformer that will be frame-rate independant.

Someone has pointed me to a first class article on the subject, so I now reckon I can start to proceed. I need to test the approach out thoroughly tonight, then I can start building a test application to post somewhere and hopefully get loads of you lot with different monitor refresh rates to test and report back any problems to me.

Good stuff. Nice to have a project on the go again.

Also, today I drew snow on my avatar. Happy Christmas. [EDIT - got bored with that so now my Orc sprite is my avatar, and he's wearing a very cool airbrush-based Santa hat, if I say so myself].


Fixed timestep seems to work like a charm, as per the figures below. The first figure is the highest pixel attained and the second is the proportion of a second (in actual time) the entire jump took to execute. The lines represent the loop running with no Sleep() then with Sleep()s of 10, 20, 30, 40 and 50:

305, 0.664
305, 0.662
305, 0.656
305, 0.666
305, 0.681
305, 0.664

Then the result with no Sleep(), but the time each frame divided by two (to simulate a 120 fps set up):

305, 0.664

Fantastic results and exactly what I wanted. And no more messing about with Vy-=300*Time; nonsense either!

Groovy. This guy is my new favourite explains-physics-to-idiots person.
Sign in to follow this  


Recommended Comments

Thanks for the link - I've been loosely following the advice you've been getting on 2D physics as it's going to be a issue for my games too. I've been wondering how to get my equations of motion to work properly with a non-constant time step, so it's been a help for me to see what solutions you've been experimenting with.

Share this comment

Link to comment
Yeah, that site seems excellent. The guy seems to be completely aware of the problems that non-mathematician programmers have with all the math jargon.

I reckon you have to have fixed time step in a 2D platformer and this approach of decoupling the physics from the rendering seems to work perfectly so far, at least in my very simple test.

How well it actually works in practice remains to be seen, of course.

Share this comment

Link to comment
I'm sure that what you're doing is close (I think?) to what I used for Skirmish (and virtually all subsequent games :P), but here's the gist:

float timePassed = 0;

// ... main loop
timePassed += timeSinceLastFrame;
while(timePassed > (1000.0f / 60.0f)) // keep updating to maintain 60 updates per second
timePassed -= (1000.0f / 60.0f);

So now you're updating at a fixed rate, but any 'overtime' per frame is preserved, which should remove the jittering you describe (unless it's a product of something else).

Hopefully that was helpful!

Share this comment

Link to comment

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
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!