• entries
743
1924
• views
580445

platformer

138 views

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].

[EDIT]

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.664305, 0.662305, 0.656305, 0.666305, 0.681305, 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.

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.

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.

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
{
doGameLogicAndPhysics();
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).

Create an account

Register a new account