summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2023-09-03modules/flow: don't reap elements on screen-space exitVito Caputo
This is too aggressive and produces some undesirable visible artifacts on the periphery, especially for slow-moving small-size fields. In such scenarios the elements near the edges would be excessively pruned when the direction wandered off-screen, then leaving an overly sparse region when the direction inevitably wandered back. This is still an issue but it's far less prominent when only clipping to the flow field boundaries... since the FOV doesn't quite encompass the edges of the flow field. Now the elements can survive wandering a bit off-screen, and re-enter.
2023-09-03drm_fb: better handle empty modes/connectors resultsVito Caputo
Phil tripped over this when his TV powered off in the midst of playing with rototiller over hdmi output. The NULL mode/connector was being supplied as the til_setting_spec_t.preferred value throwing an assert in til_setting_desc_new(). Just detect this exception and return an error.
2023-09-03modules/voronoi: spot-fix a crash Phil reportedVito Caputo
The repro is: --seed=0x64f6820b '--module=compose,layers=blank\,pixbounce\\\,pixmap_size\\\=0.8\\\,pixmap\\\=err\,pixbounce\\\,pixmap_size\\\=0.4\\\,pixmap\\\=ignignokt,texture=voronoi\,cells\=512\,randomize\=on' '--video=mem,size=3840x2160' The major culprit seems to be the combination of high resolution, and small number of voronoi cells (cells=512), with randomize=on which exercises jumpfill every frame. The way jumpfill is implemented currently is racy by design to allow threading, and mostly works fine despite not really being how the algorithm is intended to work. The assumption has been, something like: "the seeds are already placed before the threaded phase, so the threaded jumpfill should at least find stable seed cells in the face of racing against other tiles being jumpfilled simultaneously" But it appears that assumption isn't always true, in that we won't necessarily find one of the seed cells at the start of the jumpfill when there aren't that many cells (512) compared to the area of the voronoi (3840x2160). By noticing when we've finished a tile's jumpfill with remaining unassigned cells, we can just repeat the jumpfill, with time passed, and the other tiles will have made progress on their work propagating more knowledge of where cells are... so the subsequent pass will probably leave nothing unassigned. This approach sucks, but stops the crashing. It'd also be possible to just change the way cells are looked up so there's no potential for a NULL pointer dereference, just have some uninitialized cell color which gets shown erroneously in the output. That avoids the computational cost of repeating the tile's jumpfill, and likely nobody would notice the likely single pixel of error for a single frame. I'm just doing this quick and dirty fix to prevent the crashing for now, and would like to just revisit voronoi more thoroughly with an eye towards decoupling the voronoi cost from the resolution. It's a cheap hack the way there's a distance entry per pixel, done just to simplify the implementation when I slapped it together on a Zephyr train ride.
2023-09-03modules/flow: add colorsVito Caputo
This is a first stab at colorizing the output. The flow field now has two v3f_t datums per cell, direction and color. It's a bit pastel-y and color choice/palettes definitely needs work, at least some gamma correction would make sense. But I kind of like the pastel look actually, some of the combinations start looking very 80s aesthetic. A good way to watch flow's possibilities is: --module=rtv,channels=flow,duration=10,context_duration=10,caption_duration=0 \ --video=sdl,fullscreen=on --defaults --go The long-ish duration really gives a chance to get into the groove of things before switching
2023-09-02til_fb: verify fb_ops and setup creator matchVito Caputo
Just another defensive programmer error assert, though exceedingly unlikely we definitely shouldn't be getting til_setup_t's created by someone else.
2023-09-02til: verify module and setup creator matchVito Caputo
til_module_create_contexts() currently supplies the til_module_t* independent from the til_setup_t*, but since the addition of til_setup_t.creator, we actually get the module from the setup as well. So let's at least assert that they match, since it'd be a real problem if a setup from a foreign creator somehow got here. It's tempting to refactor to just derive the module from the setup altogether and stop passing that around separately, but that kind of sucks as-is because til_setup_t is used by more than just rendering modules. It makes me lean towards deprecating til_setup_t.creator and instead having the various til_setup_t users subclass it with their own types like til_fb_setup_t and til_module_setup_t which each get typed creators, then pass those around. It's starting to smell like over-engineering, let's just roll with the assert.
2023-09-02modules/flow: minor cleanup of ff_new()/ff_free()Vito Caputo
Simplify ff_new() failure path by using ff_free(), also make ff_free() more ergonomic by returning NULL.
2023-09-02flow: implement a 3D flow field moduleVito Caputo
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.
2023-08-31modules/moire: tap n_ringsVito Caputo
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.
2023-08-31modules/moire: parameterize number of ringsVito Caputo
This was hard-coded @ 20 for no particular reason. Varying this paramater greatly affects the output, it should also be exposed as a tap.
2023-08-31modules/pixbounce: make pixbounce threadedVito Caputo
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.
2023-08-31modules/*: use til_setup_free_with_ret_err() where aproposVito Caputo
Just some more res_setup baking failure path cleanups, largely mechanical change.
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.
© All Rights Reserved