| Age | Commit message (Collapse) | Author |
|---|
|
This is kind of a particle system, where the particles are pushed
around through a 3D vector space treated as a flow field.
No physics are being simulated here, it's just treating the flow
field as direction vectors that are trilinearly interpolated when
sampled to produce a single direction vector. That direction
vector gets applied to particles near it.
To keep things interesting the flow field evolves by having two
distinct flow fields which the simulation progressively
alternates sampling from. For every frame, both flow fields are
sampled for every particle, but how much weight is given to the
influence of one vs. the other varies by a triangle wave over
time. When the weight is biased enough to one of the flow fields
near a peak/valley in the triangle wave, the other gets
re-populated while its influence is negligible, also
interpolating its new values with 25% influence from the active
field.
The current flow field population routine is completely random.
Yet there's a surprising amount of emergent order despite being
totally randomized direction vectors.
Currently supported settings include:
size= the width of the 3D flow field cube in direction vectors
(the number of vectors is size*size*size)
count= the number of particles/elements
speed= how far a particle is moved along the current sample's
direction vector
This was first implemented in 2017, but sat unfinished in a topic
branch for myriad reasons. Now that rototiller has much more
robust settings infrastructure, among other things, it seemed
worth finishing this up and merging.
|
|
This has a nice side effect of being able to have no rings at all
via 0.
Note it would be potentially interesting to tap n_centers, but
that's substantially more complicated as those have allocated
state per-center. Maybe the centers= setting could be treated
as a max, then the tap could vary within that limit.
|
|
This was hard-coded @ 20 for no particular reason.
Varying this paramater greatly affects the output, it should also
be exposed as a tap.
|
|
Pixbounce isn't a particularly costly thing to render, but when
used as part of a composition, any time wasted with idle CPUs is
CPU time potentially stolen from other layers which could be
utilizing those CPUs.
So in this commit I've done a rather minimal conversion of the
pixbounce code to support threaded rendering. It basically
doubles+ lone pixbounce FPS in --video=mem tests here.
|
|
Just some more res_setup baking failure path cleanups, largely
mechanical change.
|
|
This introduces til_setup_free_with_ret_err()
which just does the common idiom of:
- free the setup
- return with err code
so all these failure cases can be reduced to just a direct return
of calling this function.
Simpler version of til_setup_free_with_failed_setting_ret_err(),
which could have been reuesed for this by making the settings-related
parameters optional... but this way the call sites are less verbose
and these are tiny helpers it's harmless.
|
|
Similar to setup_interactively(), rkt_scener needs to handle
EINVAL errors on res_setup baking @ finalize.
Until now it had handled EINVAL @ finalize by failing the
operation and returning to the main scenes prompt.
With this commit rkt_scener now returns the user to the failed
setting, enabling correcting the problem.
It's a little janky, but not too bad. See comments for why.
|
|
Now that all the module setup_funcs are returning a res_setting
w/-EINVAL in res_setup baking, it should be fine for
setup_interactively() to resume using the single setup_func()
loop passing res_setup, and always using res_setting on -EINVAL.
This is especially desirable now that :-prefix settings are
accepted as overrides. You can now get arbitrary values down to
the res_setup baking phase, previously when you got something
wrong there you'd get an ambiguous error without a setting path.
With this commit, you should get a much more useful error
including a setting path.
This partially undoes 5191d68, where res_setup-baking was split
off from the core loop, to occur after the res_failed_desc on
EINVAL storage.
|
|
This function is effectively deprecated, but
til_settings_apply_desc_generators() still makes use of it.
So for now just making it private until I feel like either
refactoring the desc generators to not use it, or maybe just
moving a simpler open-coded form into
til_settings_apply_desc_generators().
|
|
More setup_func conversion to returning the failed setting on
errors during res_setup baking.
|
|
More setup_func conversion to returning the failed setting on
errors during res_setup baking.
|
|
_ref_setup() doesn't have any -EINVAL failure paths in res_setup
baking, but let's get off til_settings_get_and_describe_value()
so it can go away.
|
|
More setup_func conversion to returning the failed setting on
errors during res_setup baking.
|
|
compose_setup() doesn't have any res_setup baking -EINVAL error
paths, but still transition over to enable potentially
deprecating the value-oriented variant.
What error paths it does have during res_setup baking is nested
in the underlying tile's module setup, and that should be
propagating up any -EINVAL failures with the res_setting already
populated.
|
|
More setup_func conversion to returning the failed setting on
errors during res_setup baking.
|
|
More setup_func conversion to returning the failed setting on
errors during res_setup baking.
|
|
montage_setup() doesn't have any res_setup baking -EINVAL error
paths, but still transition over to enable potentially
deprecating the value-oriented variant.
What error paths it does have during res_setup baking is nested
in the underlying tile's module setup, and that should be
propagating up any -EINVAL failures with the res_setting already
populated.
|
|
More setup_func conversion to returning the failed setting on
errors during res_setup baking.
|
|
More setup_func conversion to returning the failed setting on
errors during res_setup baking.
|
|
submit_setup() doesn't have any res_setup baking -EINVAL error
paths, but still transition over to enable potentially
deprecating the value-oriented variant.
|
|
More setup_func conversion to returning the failed setting on
errors during res_setup baking.
|
|
More setup_func conversion to returning the failed setting on
errors during res_setup baking.
|
|
More setup_func conversion to returning the failed setting on
errors during res_setup baking.
|
|
More setup_func conversion to returning the failed setting on
errors during res_setup baking.
|
|
More setup_func conversion to returning the failed setting on
errors during res_setup baking.
|
|
More setup_func conversion to returning the failed setting on
errors during res_setup baking.
|
|
More setup_func conversion to returning the failed setting on
errors during res_setup baking.
|
|
More setup_func conversion to returning the failed setting on
errors during res_setup baking.
|
|
More setup_func conversion to returning the failed setting on
errors during res_setup baking.
|
|
More setup_func conversion to returning the failed setting on
errors during res_setup baking.
Also fixed a bug while here in the style_values error detection;
it was misusing nelems() on the array when it's NULL-terminated
with a sentinel. But this was only triggered if a user force
overrided the setting with the :-prefix syntax, since otherwise
the setting had to be in the values set according to the
front-end. It was known there'd prolly be bugs when adding that
: override prefix support. A lot of the module-local setup
baking code has been neglected/bitrotted/carelessly changed over
time, depending on front-end values policing to keep things on
the rails.
|
|
More setup_func conversion to returning the failed setting on
errors during res_setup baking.
|
|
Switching over to the newly added setting-centric variants
enables ergonomically returning the failed setting during baking.
With this commit, modules/plato becomes the first to properly
return the setting which failed to parse during baking res_setup.
|
|
This introduces til_setup_free_with_failed_setting_ret_err()
which just does the common idiom of:
- free the setup
- store the failed setting
- return with err code
so all these failure cases can be reduced to just a direct return
of calling this function.
|
|
This is kinda icky copy-pasta vs. the previous commit.
But this function is just an inherently crufty helper, hopefully
the value-centric variant can be removed at some point.
|
|
Currently everything wanting to get a settings value goes through
til_settings_get_value_by_{idx,key}() functions which return the
value rather than the setting directly to the callers.
This was a convenient thing initially, but it's becoming apparent
that most of the setup_funcs using these actually need the
til_setting_t* for improved error handling in the res_setup
baking phase.
So this commit basically just converts the existing functions
into bare til_setting_t* returns, leaving the existing get_value
variants as helper wrappers around them.
Subsequent commits will rework the myriad setup_funcs to use the
new variants, eventually letting setup front-ends like
setup_interactively() to make use of the res_setting on res_setup
baking failures too.
For now both variants will coexist, during the reworking. The
get_value variants may go away at some point if nothing is making
use of them.
|
|
Several modules still had vestigial ad-hoc free() cleanups on
error paths in their create_context().
Largely mechanical change of replacing those with
til_module_context_free() which is more appropriate, since the
til_module_context_t holds a reference on the setup. A plain
free() will leak that reference.
But it's only on create_context() failures which are uncommon,
so this was in practice mostly harmless...
|
|
Having everything in fixed defines severely constrains the
diversity of particle behaviors and appearances.
This commit has been sitting around bitrotting since 2017, but
now that there's all this settings infra. and randomizing via
rtv, it seems worth landing, so I've rebased and am merging to
prevent a bitrot->rebase recurrence.
As-is, this commit ~minimally establishes a somewhat streamlined
parameterizing mechanism w/X-Macro patterns, while wiring up a
few of the obvious use cases surrounding xplode/burst, colorizing
the default sparkler explosions while at it.
It appears that when I first hacked this up I did some
experimentation with parameters as well, so there are some tweaks
to the behavior as opposed to a strict conversion of the fixed
defines to parameters. They seem minor enough to just leave be.
Plus a few minor optimizations like converting divides to
multiplies were in there.
Future commits can now wire up settings to choose from parameter
presets for different sparklers...
|
|
Mechanical rename for clarity reasons, primarily to better
differentiate from the setup_func style
til_module_setup()/til_module_setup_full() functions.
|
|
Mechanical rename for clarity reasons, primarily to better
differentiate from the setup_func style
til_module_setup()/til_module_setup_full() functions.
|
|
This sets the flash state when driven by something (like rkt).
When driven, the toggle tap will override hz altogether.
|
|
This enables dynamic external control of the strobe's frequency.
|
|
Clarifying trivial mechanical rename
|
|
Preparatory commit for exposing strobe::hz as a tap, it seems
awkward to work in periods especially in the track data.
Though I do like the 0-1 range of period, though that doesn't
even hold for slower than 1HZ frequencies so... it's kind of a
lie anyways.
At least if the track is called "hz" anyone will know what the
values mean and easily reason about them. So I'm making the
setting consistent with the soon to be added "hz" tap.
|
|
Commit 64a5b17 added this to til_module_context_t, so it's
already being tracked now making this redundant.
|
|
Outside of overflow (which I'm ignoring for now) ticks shouldn't
go backwards. With the introduction of adding the frame-buffer
delays, which vary, there's the potential for the delay to go
from large to short in quick succession, to such a degree that
the next render's now+delay is in the past relative to the
previous now+delay.
For now this simple fix is to just track the last_ticks and
always use the maximum of the last_ticks and now+delay, ensuring
it never goes backwards.
This was making alphazed exit prematurely at spurious times by
sending the rocket_row into oblivion because (ticks - last_ticks)
was negative w/unsigned arithmetic. This will all get more work,
and maybe ticks should be allowed to go backwards actually, but
some things are assuming that's not the case as-is.
Regardless, it's not desirable for ticks to go backwards because
of the frame-buffer delay. In that case just chill on the ticks
advancement for a frame. This will need revisiting for sure, as
I don't think re-rendering the exact same tick as the last frame
is likely to be what's wanted either. Probably some little
advancement should still be performed...
|
|
This should push the ticks value ahead by 1-2 frames worth of
time, when rendering is meeting/exceeding the frame rate. Which
is the appropriate thing to do, since rendering is effectively
slightly ahead of the clock, producing visuals for now+N-frames
into the future.
When rendering lags behind, there's basically no delay, and
rendering is just operating on the "now" ticks which will be
flipped to ASAP once submitted.
This will probably be revisited once audio is rolled in, since
that too will need to be kept in sync with the visuals'
perspective of time.
|
|
til_fb is triple buffered, but when rendering lags behind the
queue is empty making present-to-delay intervals smaller than
when rendering is keeping up and the queue is kept full.
This returns the duration of the returned pages last
submit-to-present delay, effectively measuring how long a page
can expect to wait to be flipped to/presented currently.
A subsequent commit will apply this delay value to the ticks
supplied to rendering.
|
|
Preparatory commit for returning submit-to-present intervals
w/til_fb_page_get().
|
|
This needs a bit more work, but at least filtering the same-tick
renders avoids the many-movements-per-frame potential when used
as something like a checkers::fill_module
|
|
This needs a bit more work, but at least filtering the same-tick
renders avoids the many-increments-per-frame potential when used
as something like a checkers::fill_module
|
