RE: [Plib-devel] ssg animation

[Dave M. <Dav...@dy...>]

i made a first pass at these changes because i will need the extra frames
soon.
i'm interested in the realtime/frame-locked feature, but i'm unsure of how
you wanted to implement that so i'll leave it to you.

--Dave

Steve Baker wrote:
> > Dave McClurg wrote:
> > 
> > Proposed changes:
> > 
> > ssgSelector would allow more than 32 frames by adding a 
> max_kids param to the constructor
> > 
> >   ssgSelector ( int max_kids = 32 ) ;
> > 
> > the derived classed ssgRangeSelector and ssgTimedSelector 
> would also take this param.
> 
> What about the current ability (which I use quite a bit) to 
> pass an integer mask
> with one bit per child object to enable you to select 
> multiple child objects at
> once?
> 
> > also, i would like to move this
> > 
> >   _ssgFrameCounter++ ;
> > 
> > from the top of ssgCullAndDraw() to the bottom of 
> ssgCullAndDraw() because i want
> > the animation rate to be based on logic frames and not 
> render frames.
> 
> Yes - that's becoming important.
> 
> I was planning on making a new member function in 
> ssgTimedSelector to allow you
> to ask for either 'realtime' of 'frame-locked' animation.
> 
> There are cases when each is useful - and I'd like to mix 
> them in the same
> application sometimes.
> 
> > I'll just call ssgSetFrameCounter(fc) before calling 
> ssgCullAndDraw().
> 
> That'll work in the short term.
> 
> > My logic frames are scheduled with a timer so that I always 
> have 60 logic frames
> > per second regardless of my render frame rate.  My 
> animation plays correctly
> > on slow machines and fast ones.  I prefer this over 
> non-determistic simulations
> > where the number of logic frames varies and uses floating 
> point time intervals.
> 
> Yes - but there are times when frame-locked synchronisation 
> is *CRITICAL*.
> 
> One example is in a weather simulation model we have at work that does
> lightning bolts.  You need the lightning bolt to appear as briefly as
> possible - yet never NOT happen because the previous frame 
> took too long
> to render.  To make the lightning look brighter, we do the 
> visual trick
> of pre-rendering a black lightning bolt, then doing the white one and
> then another black one.  Its CRUCIAL that each of those three things
> lasts just one frame - irrespective of the elapsed wall-clock time.
> 
> Anyway - doing this per-object rather than for the entire program
> seems crucial to me.
>