[Golist] Go Pulse.

Thu May 15 12:36:49 PDT 2008

>So, this leads me to wonder about how to deal with adaptive update rates
from Go.
Sorry I was a bit long on this point, but I think it illustrated what you
described.

Finally we are straight to the point that Moses set as an objective for GO
at its anception ;)
GO integration within Tweening - 3d real time - physic engines - collada 
And the use of its pulse as a central point to make things gather. I've
heard that Moses is talking with papervision3D team, to improve
GO and Papervision3d cooperation. Certainly it is also about pulse.

>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

Yes, it will be a very strategic decision...

If I go with 1, from the top of my head:

We may have PulseItems
Managed by a PulseItemManager
PulseItemManager require at least one PulseItem(which is the default) and
can register more.
Each PulseItem registesr targets which use its pulse, these targets
implement IPulseTarget with makePulse function
When a pulse happens targets have their makePulse Method called.

PulseItemManager can also have a module to track 
>resource, fps, cpu usage, maybe even memory usage if your 
>update is memory 
Aka PulseLimiter which if it is on check memory usage.
If a PulseItem IsRessourceLimited the pulse rate is limited based on
PulseLimiter rate ;)

A PulseItem may define 
>var desiredFPS:Number = 30;
IsRessourceLimited
Methods
registerTarget
unregisterTarget

Pushing things forward...
A PulseItem may go further also for example you may have targets groups
which can be passed from one PulseItem to another, depending on the
situation.

STOPSTOPSTOP Fantasy ;)

I just let ideas flow as you Martin ;)

Best regards.

Cedric M. (aka maddec)

Interactive Creator
Adobe Flash/Flex/AIR Specialist 
Since 1998
----------------------------------------------------
http://analogdesign.ch
http://analogdesign.ch/blog
visual & interactive communication
----------------------------------------------------

>-----Message d'origine-----
>De : golist-bounces at goasap.org 
>[mailto:golist-bounces at goasap.org] De la part de Martin Wood-Mitrovski
>Envoyé : jeudi, 15. mai 2008 16:17
>À : Mailing list for the Go ActionScript Animation Platform
>Objet : Re: [Golist] * Go Demo Contest - win an iPod Shuffle! *
>
>> 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 ;)
>
>
>
>_______________________________________________
>GoList mailing list
>GoList at goasap.org
>http://goasap.org/mailman/listinfo/golist_goasap.org
>