summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2023-08-31til_setup: add another helper for setup_func baking failsVito Caputo
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.
2023-08-31modules/rkt: better handle EINVAL errors on finalizeVito Caputo
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.
2023-08-30setup: return to single setup_func() call siteVito Caputo
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.
2023-08-30til_settings: privatize til_settings_get_and_describe_value()Vito Caputo
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().
2023-08-30til/sdl_fb: handle baking errors in sdl_fb_setup()Vito Caputo
More setup_func conversion to returning the failed setting on errors during res_setup baking.
2023-08-30til/mem_fb: handle baking errors in mem_fb_setup()Vito Caputo
More setup_func conversion to returning the failed setting on errors during res_setup baking.
2023-08-30til_builtins: use til_settings_get_and_describe_setting()Vito Caputo
_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.
2023-08-30modules/checkers: handle baking errors in checkers_setup()Vito Caputo
More setup_func conversion to returning the failed setting on errors during res_setup baking.
2023-08-30modules/compose: switch to til_settings_get_and_describe_setting()Vito Caputo
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.
2023-08-30modules/rtv: handle baking errors in rtv_setup()Vito Caputo
More setup_func conversion to returning the failed setting on errors during res_setup baking.
2023-08-30modules/rkt: handle baking errors in rkt_setup()Vito Caputo
More setup_func conversion to returning the failed setting on errors during res_setup baking.
2023-08-30modules/montage: switch to til_settings_get_and_describe_setting()Vito Caputo
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.
2023-08-30modules/voronoi: handle baking errors in voronoi_setup()Vito Caputo
More setup_func conversion to returning the failed setting on errors during res_setup baking.
2023-08-30modules/swarm: handle baking errors in swarm_setup()Vito Caputo
More setup_func conversion to returning the failed setting on errors during res_setup baking.
2023-08-30modules/submit: switch to til_settings_get_and_describe_setting()Vito Caputo
submit_setup() doesn't have any res_setup baking -EINVAL error paths, but still transition over to enable potentially deprecating the value-oriented variant.
2023-08-30modules/strobe: handle baking errors in strobe_setup()Vito Caputo
More setup_func conversion to returning the failed setting on errors during res_setup baking.
2023-08-30modules/stars: handle baking errors in stars_setup()Vito Caputo
More setup_func conversion to returning the failed setting on errors during res_setup baking.
2023-08-30modules/sparkler: handle baking errors in sparkler_setup()Vito Caputo
More setup_func conversion to returning the failed setting on errors during res_setup baking.
2023-08-30modules/shapes: handle baking errors in shapes_setup()Vito Caputo
More setup_func conversion to returning the failed setting on errors during res_setup baking.
2023-08-30modules/roto: handle baking errors in roto_setup()Vito Caputo
More setup_func conversion to returning the failed setting on errors during res_setup baking.
2023-08-30modules/pixmap: handle baking errors in pixmap_setup()Vito Caputo
More setup_func conversion to returning the failed setting on errors during res_setup baking.
2023-08-30modules/moire: handle baking errors in moire_setup()Vito Caputo
More setup_func conversion to returning the failed setting on errors during res_setup baking.
2023-08-30modules/mixer: handle baking errors in mixer_setup()Vito Caputo
More setup_func conversion to returning the failed setting on errors during res_setup baking.
2023-08-30modules/flui2d: handle baking errors in flui2d_setup()Vito Caputo
More setup_func conversion to returning the failed setting on errors during res_setup baking.
2023-08-30modules/drizzle: handle baking errors in drizzle_setup()Vito Caputo
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.
2023-08-30modules/blinds: handle baking errors in blinds_setup()Vito Caputo
More setup_func conversion to returning the failed setting on errors during res_setup baking.
2023-08-30modules/plato: handle baking errors in plato_setup()Vito Caputo
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.
2023-08-30til_setup: add helper for setup_func baking failsVito Caputo
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.
2023-08-30til_settings: add til_setting_t variant for get_and_describeVito Caputo
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.
2023-08-30til_settings: add get_setting_by_{idx,key}() variantsVito Caputo
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.
2023-08-30modules/*: til_module_context_free() error pathsVito Caputo
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...
2023-08-30sparkler: parameterize particlesVito Caputo
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...
2023-08-29til: s/til_module_setup_finalize/til_module_settings_finalize/Vito Caputo
Mechanical rename for clarity reasons, primarily to better differentiate from the setup_func style til_module_setup()/til_module_setup_full() functions.
2023-08-29til: s/til_module_setup_randomize/til_module_settings_randomize/Vito Caputo
Mechanical rename for clarity reasons, primarily to better differentiate from the setup_func style til_module_setup()/til_module_setup_full() functions.
2023-08-29modules/strobe: add explicit "toggle" tapVito Caputo
This sets the flash state when driven by something (like rkt). When driven, the toggle tap will override hz altogether.
2023-08-29modules/strobe: tap hz valueVito Caputo
This enables dynamic external control of the strobe's frequency.
2023-08-29modules/strobe: s/ticks/last_flash_ticks/Vito Caputo
Clarifying trivial mechanical rename
2023-08-29modules/strobe: s/period/hz/Vito Caputo
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.
2023-08-29modules/rkt: drop ad-hoc last_ticks trackingVito Caputo
Commit 64a5b17 added this to til_module_context_t, so it's already being tracked now making this redundant.
2023-08-29main: prevent ticks from going backwardsVito Caputo
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...
2023-08-29main: apply submit-to-present delay to ticksVito Caputo
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.
2023-08-29til_fb: return queue delay from til_fb_page_get()Vito Caputo
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.
2023-08-29til_fb: track fb page submit-to-present durationVito Caputo
Preparatory commit for returning submit-to-present intervals w/til_fb_page_get().
2023-08-29modules/pixbounce: filter same-tick movementsVito Caputo
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
2023-08-28modules/spiro: filter same-tick context incrementsVito Caputo
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
2023-08-25libs/sig: improve ops_sin output w/varying hzVito Caputo
This commit makes ops_sin stateful by tracking last_ticks_ms and its theta angle. Unfortunately that necessitates serializing ops_sin on the output path, currently done using a mutex. See larger comment in ops_sin.c for why this is all necessary.
2023-08-24modules/shapes: clamp {scale,pinch_factor} to 0-1Vito Caputo
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.
2023-08-24modules/shapes: tap a bunch of the parametersVito Caputo
First stab at tapping the parameterized stuff in shapes.
2023-08-24modules/shapes: toggle pinches on n_pinches=0Vito Caputo
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.
2023-08-24modules/shapes: s/cos/sin/ for pinchesVito Caputo
Preparatory commit for potential n_pinches=0, sin(0)=0 which behaves better here where n_pinches=0 should be a noop.
© All Rights Reserved