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.