| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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
|
|
It might be worthwhile to support >1 for these, but as-is it
crashes due to assumptions WRT shape size not exceeding frame
dimensions.
This just prevents crashes if someone tries putting a >1 value in
something like a rkt track for scale/pinch_factor.
|
|
First stab at tapping the parameterized stuff in shapes.
|
|
This also makes the pinches-dependent settings always get
initialized, since when tapped if you moved n_pinches from 0 to
non-zero, the pinches-dependent settings would abruptly become
relevant mid-flight. So this ensures they can have some sane
values, in case they haven't also been set via taps when
n_pinches became non-zero.
|
|
Preparatory commit for potential n_pinches=0, sin(0)=0 which
behaves better here where n_pinches=0 should be a noop.
|
|
Threaded rendering was added in 011d4df35
|
|
This needs the stream pulled in so the signature changed to
accomodate that.
Also modules/rkt was calling this conditionally which won't be
compatible with the per-frame driver race model, so always call
it to maintain the driving position every frame.
|
|
Mechanical change of ensuring what little taps are implemented
always get updated @ til_module_t.context_create() time as well
as on every frame.
This ensures the pipes are registered on stream immediately upon
context creation, rather than appearing only once the context
gets rendered the first time.
|
|
Another trivial leak fixup.
|
|
This triggers immediate cleanup of the replaced context.
It's being done after the new context is fully installed as the
replacement, with an eye towards enabling a baton style handoff
of the existing context's owned pipes to the replacement, for
taps they have in common. That's not being done yet, but it'd be
impossible if the gc occurred before creating the replacement,
since the existing context's pipes would already be untapped (and
removed).
|
|
Another trivial leak fixup
|
|
On shutdown til_stream_untap_owner() will call into the pipe_dtor
hook if set. So until now this was just (harmlessly) leaking the
rkt_pipe_t allocated by the pipe_ctor hook on the road to process
exit.
But in the interests of silencing ASAN about leaks on graceful
exit, I'm tying up these loose ends.
This dtor will also be utilized for performing a FORGET_TRACK via
Rocket once that's a thing.
While here I also got rid of the pipe_dtor return value, as it's
unused with no clear potential purpose (for now).
|
|
This is mainly to prevent the mixer's b_module=compose default
from always sending the randomizer down a deep nested compose
scenario.
But it's also just giving the mixer random variety in both a/b
modules, while keeping compose out.
This alone seems to go a long way towards preventing
problematically deep randomized setups under rtv.
|
|
Not bothering with fixing this because rtv needs its channels
setup redone altogether to better resemble something like
rkt::scenes, but allowing partial specification of the settings
as a means of controlling specific settings while randomizing the
rest.
|
|
This was prevented before but lost in the shift to
til_module_setup_full() wrappers...
|
|
cleanup_channel() is called from rtv_destroy_context(), which
can be called by a gc. The gc isn't reentrant and generally
isn't expecting this, so it breaks in hilarious ways when this
happens, usually ending in a segfault.
gc should probably get some defenses for asserting on reentry...
for now let's just prevent crashing by removing the gc call from
the destroy path.
|
|
b6362c54 introduced shapes_destroy_context() for the radcache,
but didn't actually cleanup the context, oops.
trivial fix
|
|
The existing code wasn't clipping correctly to the right/bottom
edges of the incoming fragment when the xoff/yoff was 0 but
xshift/yshift non-zero. In that case the incoming fragment bound
was unintentionally being enlarged, resulting in an overrun when
the such a cell was filled/cleared.
It was discovered watching montage under rtv, which stumbled
across running checkers w/size=128 on a montage tile of 128x96.
The height/y coords of the single checker cell filling the whole
montage tile weren't getting clamped properly down to the 96-tall
tile.
The shifting for centering checkers introduced some really
annoying arithmetic in this fragmenter.
|
|
Trivial changes to improve some naming / scoping, done while
investigating a bug.
Nothing functionally changed
|
|
This module is here to stay
|
