Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Visual vs Physical

Sign in to follow this  


I fixed several issues over the last few weeks that dealt with the difference between the visual & physical aspects of the game.

This is particularly important because of the way Ancient Galaxy handles physics vs visuals. Basically, the physics is run at a fixed frame rate of 60hz, and the visuals are interpolated between the last two physics frames.

If the frame rate falls behind, you can get into the 'well of despair', where each subsequent frame takes longer and longer because you are doing more and more physics ticks. Eventually you are forced to go into slow motion mode if the frame rate drops too low.

The stepping code would figure out how many msecs had passed since it was last called, then do as many ticks of the simulation in 16 msec chunks as possible, then use the # of msecs left over / 16 as the lerp factor between the last two physics frames.

My first try at a fix, which I doubted would work, but was so easy I had to try it, was to simply step the physics by either 16, 32, 48, 64, etc. msecs at a time. Of course, I'm not doing swept capsule tests, so this caused the player to fall through the world at times.

The next idea worked out better, and sped up the game, while still providing consistent results. The idea was to pass down to the stepping code the tick count ( 16 msecs ), as before, but also the # of times to step ( 1 by default ). In the case where the fps was >= 60, this acts just like the old code. Otherwise, certain parts of the simulation can be stepped in larger than 16 msecs steps.

The particle collisions work via raycasts, for instance, so they are fine to use any step size.

The collision code, however, could now loop internally, rather than the entire simulation looping. This way is much more cache coherent than the old method, and provided a nice speedup.

Old Way :

For each 16 msec time step this frame
Do object 1 for 16 msec
Do object 2 for 16 msec
Do Object 3 for 16 msec
do Particles for 16 msec

New way :

For each 16 msec time step this frame
Do object 1 for 16 msec
For each 16 msec time step this frame
Do object 2 for 16 msec
For each 16 msec time step this frame
Do object 3 for 16 msec

Do Particles for 16 * N msec

Now these won't produce completely identical results, but for my purposes, it works quite well.

One of the other fixes was to the camera lerping code, which was causing camera jerkiness at low fps. The camera follows the player, and the player's position etc. must be lerped between the last two physics frames as well. But, the player location must e known before setting up the camera, even though he hasn't been lerped yet. Fixing this really improved the feel at lower fps.

Another visual / physical problem occured with the entities, causing an entity to repeatedly add itself to the tree of entities, while never getting removed. This was a nice memory & perf leak I fixed yesterday.

Some perf fixes to remove the dynamic ambient occlusion on entities.

Still having some perf issues - we need to move the cal3d animation to the vertex shader.
Sign in to follow this  


Recommended Comments


Are you looking at any of the physics hardware or multi-threading stuff thats starting to appear? Seems this sort of timing fun might be, at least partially, alleviated via a MP design.

Maybe I'm going mad, but I was sure you posted something about a deal with Ancient Galaxy showing off some of the new Ageia PhysX PPU stuff... ??


Share this comment

Link to comment
Yes, I actually spent last week in St. Louis working with the Ageia engineers to incoporate the hardware fluids into the engine. I'd post some screens, but it still not visually tweaked, but it does run fast!

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!