[Golist] * Go Demo Contest - win an iPod Shuffle! *

[Martin Wood-Mitrovski]

> 1: I can speedup the resfresh rate if I need a smooth tweening transition on
> my 3D (independant from user moving of  3d in real time ).
> 2: I can slowdown the refresh rate if I need full power for other
> transitions in other part of the website.
> 3: I can track system responsiveness and avoid slowdowns of the playback of
> flvs, meaning that the 3d refresh rate is quicker on a quick computer with
> ressource enough, and put at its minimum rate on an old slow computer.
> 
> Regarding point 3, the simple approach would have been to have the 3D
> playing without this optimisation, then what's happening:
> 3d slows down because of too much things happening in the same time, but
> other part of the website are also slowing down,
> for example, here my flvs (which are my main content). I've often seen this
> unoptimized way of handling real time 3d.
> 
> With my solution, the 3d rendering seems to slow down the same as above, but
> in fact it is intentional and managed to give more power to the flv
> playback. Then the flv playbacks runs more smoothly.
> 
> I'm sure that this approach may benefit from GO pulse, I'll experiment it as
> soon as possible ;)

So, this leads me to wonder about how to deal with adaptive update rates from Go.

I've only had a brief look into the lower levels of the GoEngine so I dont know 
what approach would be the best.

I can see that the pulse interval for a particular IUpdatable is used to 
register that object when calling GoEngine.addItem, so to implement adaptable 
updates im guessing you would either

1. register multiple IUpdatable objects with different pulses and switch between 
them from the subsytem that is using them.

2. register a single high-frequency IUpdatable and implement something like an 
update skip count to modulate the actual updates. e.g. you register with a pulse 
interval of 10, and when the engine calls your update you do this

...

skipCount--;

if(skipCount == 0)
{
   // do the actual processing

   skipCount = numberOfUpdatesToSkip;
}

....

so if numberOfUpdatesToSkip is 3 you get an effective pulse interval of 30.

and then you can control the numberOfUpdatesToSkip depending on some metric / 
resource, fps, cpu usage, maybe even memory usage if your update is memory 
intensive.

Im starting to think that this would make a really interesting layer to build on 
top of Go which you could easily plug in to, like an AdaptiveGo class which you 
can configure for common scenarios

// The frames per second you want to maintain
var desiredFPS:Number = 30;
// the longest time between updates allowed
var maxUpdateTime:Number = 250;

var adg:AdaptiveGo = new AdaptiveGo(AdaptiveGo.FPS, desiredFPS, maxUpdateTime);

then it will monitor your fps and adjust the max skip count accordingly, up to a 
maximum where updates would occur every maxUpdateTime.

of course you would want to use the current time parameter passed to the update 
to get the time between updates so you could make sure everything was 
independent of frame rate / update rate.

anyway...something like that might be cool, im just letting the ideas flow ;)