TIGSource Forums

I want a variable passage of time in the throwing game I'm making. Take a look at the fight in this clip from 300 to see what I mean:

300 fight scene (http://www.youtube.com/watch?v=Sh9ZEonBtfk)

I tried changing the frame rate of the game at runtime (in AS3) but it just looks like it's chugging on some badly written code.

I'm currently using verlet integration to move the character, but that won't allow me to run the physics at half speed or whatever because it relies on the position of the character in the last frame. I need a new physics model (but one that isn't overkill, it's a throwing game, it doesn't need to deal with complex polygon collisions).

Any suggestions?

fixed rate logic and delta time are the key concepts  i would say.

with them you could give in a desired update-logic speed (in millisecs / per frame)
as a output you'll get the amount of update-steps taken in a frame (speed independant.)
i am sure your physics module knows how to update itself , given the amount of steps .

you'll encounter stuff as interpolating/tweening also, but they are easier then they sound.

changing framerate during runtime is not the way to go, because it messes everything else up, and you can't tell if other people have computers that can run at your framerate anyway.

sorry if the post is unclear, i'm feeling abit unclear also :)

Depending on your needs there are a few different things you could do.

- Run Verlet (or other fixed-timestep) with a smaller timestep and simply do more steps per frame when running at full speed. Likely to get you performance issues, but if you do not have enough physics for it to become a problem, it should work fine.

- Use Euler/Improved euler instead of verlet. It allows you to have variable timesteps and is faster but produces a less physically correct simulation and is more likely to break apart if you are doing fancy stuff (joints etc). Also has the problem that results become highly dependent on the simulation frequency, meaning whether you enable slow-motion or not have a huge impact on the results.

- Run Verlet and simulate it in real-time, only interpolate between current physics frame and next physics frame when not enough time has passed to produce a new frame. Faster than the other solutions and as deterministic as just doing ordinary simulation in real-time but since you get a lot less detail per frame it might look weird.

Check out this article (http://gafferongames.com/game-physics/fix-your-timestep/).  He explains how to set up a framerate independent physics loop, and goes over how to handle slow motion using interpolation.

Good luck!

That link is the one!
that originally taught me this thang,
cool.

Glenn Fiedler is awesome. I learned network programming from his articles.

Cheers folks. I just switched over to Euler, changed the damping modifier to a friction modifier and added a global timeStep variable that affected all executed movement and changes to movement.

I didn't need an RK4 but the explanation of it let me know I was doing the right thing when I trawled through the code making changes everywhere.