|
There's still a handful of modules doing ad-hoc radians
accumulation in a static variable by simply adding a small value
like .01 every render.
This worked OK in the early days when 1. no rototiller instance
was ever run long enough for that accumulator to become a large
value where floating point precision started rearing its ugly
head. and 2. rototiller never really drew the same module
multiple times in compositing a frame.
Now that rototiller can produce some rather interesting outputs
the first assumption isn't really true - I've fixed memory leaks
to enable long-running sessions, so these potential precision
problems should get dealth with.
And with rtv+compose/checkers+fill_module it's quite common to
have a module rendering things many times in a single frame. So
that previously tolerable laziness of using a static accumulator
is no longer acceptable, since every invocation of the module's
renderer would bump the accumulator. When you have something
like checkers using blinds for the filler, every individual cell
is unintentionally advancing the blinds when they're intended to
be at the same phase.
So this helper is being added to conveniently turn ticks into
something you'd pass directly into cosf/sinf without worrying
about precision issues.
Future commits will start bringing modules over to use this
helper instead of whatever they're doing with static variables
or in-context accumulators etc.
There's also another reason to prefer deriving "T" from ticks
on every frame; we can do things like fast-forward/rewind effects
on modules by manipulating the ticks input value. If the modules
are accumulating this state privately, manipulating ticks won't
have the intended effect. Of course not all modules are amenable
to this kind of thing, stuff like swarm and sparkler where they
do a sort of simulation contain a pile of state that isn't
ticks-derived on every frame and can't really be converted to do
so.
|
