summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-08-13main: free setups and settings in shutdownVito Caputo
more cleaning up stuff on exit
2023-08-13modules/rtv: don't gc from cleanup_channel()Vito Caputo
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.
2023-08-13modules/shapes: plug context leakVito Caputo
b6362c54 introduced shapes_destroy_context() for the radcache, but didn't actually cleanup the context, oops. trivial fix
2023-08-13sdl_fb: plug title leakVito Caputo
trivial fix of a trivial leak on teardown
2023-08-13main: switch to til_fb_halt()Vito Caputo
This gets rid of the rototiller_thread() pthread_cancel() based exit which seemed to rarely make clang's ASAN (-fsanitize=address) very angry with a segfault in libc somewhere Instead of trying to chase that down I'm just getting rid of it, it's unnecessary.
2023-08-13til_fb: introduce til_fb_halt()Vito Caputo
This makes it so til_fb_page_get() will return NULL when the fb has been "halted". If til_fb_page_get() is already waiting for a page to become available, it will be woken up by til_fb_halt(). Preparatory commit for eliminating the reliance on pthread_cancel() to terminate rototiller_thread() on shutdown. Cancellation is always a PITA, especially cross-platform, but in general it's so easy to have subtle bugs when using it.
2023-08-13til_fb: track all pages and free them in til_fb_free()Vito Caputo
Pages that have been handed out from the inactive list didn't live on any lists, not until they were submitted. This commit keeps all pages on a separate list to make cleanup of outstanding pages in til_fb_free() trivial, which has also been introduced here. Just tidying up the shutdown to get rid of a bunch of harmless leaks, in an effort to make ASAN more useful in detecting real leaks on graceful exits.
2023-08-13til_stream: assert when gc leaks in til_stream_free()Vito Caputo
It's expected that all mondule contexts will have been cleaned up by the final gc in til_stream_free(). If the gc returns a non-zero skipped count, it suggests there's a program bug leaking registered contexts.
2023-08-13til_stream: return skipped count from til_stream_gc_module_contexts()Vito Caputo
Preparatory commit for making til_stream_free() assert on leaked module contexts.
2023-08-13til_stream: always assign n_module_contexts in registerVito Caputo
Leaving the larger n_module_contexts on reuse creates the potential for a NULL ptr dereference in places like gc which check the refcount of each countext in the set, without testing for NULL. Rather than making everything check for NULL, just shrink the count when it gets reused in a smaller case. This whole reuse thing is kind of a silly little optimization anyways, and will be revisited when cloning either happens or the sets become deprecated. For now just prevent creating situations that can crash.
2023-08-13til_stream: fix parent_path leak in til_stream_untap_owner()Vito Caputo
Plug a small leak
2023-08-13til_stream: gc module contexts on til_stream_free()Vito Caputo
Technically this was leaking contexts but it's only done on the road to process exit currently anyways.
2023-08-12til_fb: fix bug in til_fb_fragment_slice_single()Vito Caputo
Silly bug, these fragmenters need to be revisited in general to have less copy pasta across the texture fragment and main fragment. Easily triggered with: --seed=0x64daba35 '--module=compose,layers=julia\,checkers\\\,size\\\=:96\\\,pattern\\\=checkered\\\,fill_module\\\=:checkers\\\\\\\,size\\\\\\\=128\\\\\\\,pattern\\\\\\\=checkered\\\\\\\,fill_module\\\\\\\=moire\\\\\\\\\\\\\\\,type\\\\\\\\\\\\\\\=pinwheel\\\\\\\\\\\\\\\,scale\\\\\\\\\\\\\\\=1\\\\\\\\\\\\\\\,pinch\\\\\\\\\\\\\\\=0\\\\\\\\\\\\\\\,points\\\\\\\\\\\\\\\=5\\\\\\\\\\\\\\\,spin\\\\\\\\\\\\\\\=.1\\\\\\\,dynamics\\\\\\\=alternating\\\\\\\,dynamics_rate\\\\\\\=1.0\\\\\\\,fill\\\\\\\=textured\\\\\\\,fill_color\\\\\\\=0xffffff\\\\\\\,clear\\\\\\\=textured\\\\\\\,clear_color\\\\\\\=0x000000\\\,dynamics\\\=alternating\\\,dynamics_rate\\\=1.0\\\,fill\\\=textured\\\,fill_color\\\=0xffffff\\\,clear\\\=textured\\\,clear_color\\\=0x000000,texture=plasma' '--video=sdl,fullscreen=off,size=640x480'
2023-08-12modules/checkers: fix clipping bug in fragmenterVito Caputo
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.
2023-08-12modules/checkers: minor cosmetic changes to fragmenterVito Caputo
Trivial changes to improve some naming / scoping, done while investigating a bug. Nothing functionally changed
2023-08-09modules/mixer: remove TIL_MODULE_EXPERIMENTAL flagVito Caputo
This module is here to stay
2023-08-09modules/mixer: %S/fade/blend/gVito Caputo
Blend is a more accurate word for what's being done. Fading is something you can achieve with the blend mode, if you use something like "blank" as one of the modules. But when you have two modules generating content, it's not a fade, it's just a blend. It might make sense in the future to support a "fade" which assumes a solid color for one module rather than having to use the "blank" builtin which burns memory bandwidth on a blank frame.
2023-08-08modules/rtv: til_module_setup_full()-ize snow_module=Vito Caputo
Just more largely mechanical changes transitioning ad-hoc nested module handling over to til_module_setup_full().
2023-08-08modules/roto: trivial indentation fixupVito Caputo
2023-08-07modules/rkt: add EDITSCENE state akin to NEWSCENEVito Caputo
Now you can seed the scene editing with a top-level serialized scene in "as_arg" form, just like NEWSCENE. The current scene being edited is shown in serialized form for convenient copy & paste into an editor for manipulation, between the []s both to also show what the default seed will be if you just press enter. When using the copy & paste w/editor approach, you'd just paste the tweaked form directly into the waiting prompt before hitting <enter>. Regardless of what happens at the initial EDITSCENE prompt, the current implementation always goes through an interactive visiting of all the settings. Simply pressing enter at those individual settings will accept their current value from the serialized seed, or a default if not present in the settings.
2023-08-07modules/rkt: make NEWSCENE state a simple functionVito Caputo
This doesn't need to be a distinct state since it's basically just a banner for the start of the newscene process which never recurs, it's not an interactive prompt or dialog of any kind...
2023-08-07modules/checkers: fix radcache partial initialization bugVito Caputo
Running something like: '--module=checkers,size=64,fill_module=shapes,style=circle --defaults --go' Would show some artifacts in the top portion of the filled cells at certain phases of the spining shape. This was introduce by the radcache, and it's caused by the overhanging tiles on the perimeter and how their being clipped was carrying into the radcache contents then used for all subsequent renders. This commit just makes setting radcache.initialized conditional on the incoming fragment being a full-frame fragment as a quick fix. See comment for more info on what to do long-term.
2023-08-07modules/checkers: ensure all fill_module_contexts renderVito Caputo
There's potential for some of the per-cpu fill_module_contexts to go unused for an entire frame. When this occurs, depending on the fill_module in use, it can lead to their context's state diverging. To mitigate this possibility, add a tidying up pass in checkers_finish_frame() where such straggler contexts are identified and forced to render once into a cell-sized waste_fb of off-screen memory. This ensures all contexts see all frames/ticks that any participated in, preserving their clone status across the board. Prior to this you could see jittering in something like '--module=checkers,fill_module=roto' as the roto contexts diverged on the r/rr variables when some didn't get in on the action of some frames. See large TODO comment for why this approach is used instead of something less wasteful of cpu time. If this approach is kept, it might make sense to do the waste rendering in parallel. Systems with large numbers of cores could end up with many stragglers, depending on how many cells there are vs. cpus. I don't have any such systems so it's difficult to test any efforts in that vein.
2023-08-06modules/roto: only update fill_fb on changed ticksVito Caputo
In compositions where roto recurs in the same frame, it's wasteful to keep rendering the fill_fb contents manifold for the same tick. They shouldn't be varying anyways... It'd be different if the fill_module rendered directly to the output fragment in an overlay manner, but the current roto implementation doesn't do that. It's just sampling fill_fb like a tiled texture sampler would. The performance hit here is easily observed by doing something like: --module='checkers,size=4,fill_module=roto\,fill_module\=moire' --video=mem --defaults --go Before this change, FPS=1 on my i7 X230. After, FPS=~400.
2023-08-05modules/mixer: til_module_setup_full() for inputsVito Caputo
Switch to til_module_setup_full() for handling the module setup of the input {a,b}_module settings
2023-08-05modules/compose: til_module_setup_full() layers=/texture=Vito Caputo
Switch to til_module_setup_full() for handling the module setup of the individual layer module settings as well as the texture. Since compose served as the development mule for adding nested settings, there was a lot of verbose comments that no longer seemed necessary since much of the dust has settled. The separate compose_layer_module_setup() and compose_texture_module_setup() wrappers feel a bit like copy-pasta too. I'm tempted to stop using these and just open code the til_module_setup_full() calls, except they get performed twice due to the split finalize, so it's probably still a net win as-is.
2023-08-05til: fix til_module_setup_full() exclusionsVito Caputo
Stupid bug in untested/unused exclusions handling
2023-08-05modules/montage: til_module_setup_full() for tiles=[...]Vito Caputo
Switch to til_module_setup_full() for handling the module setup of the individual tile module settings.
2023-08-05til_builtins: add flag to "blank" builtinVito Caputo
Missed one!
2023-08-05modules/roto: til_module_setup_full() for fill_module=Vito Caputo
Switch to the generic til_module_setup_full() and rely on the "none" builtin's NULL res_setup on finalize to indicate when no fill_module is desired. This gets rid of the need for a separate til_module_t* handle for the fill_module, since til_setup_t.creator can be used for that, and the NULL til_setup_t* to indicate no fill_module. Basically discards some busy work style code, there's more cleanups needed surrounding this stuff though. More or less identical to the previous change to modules/checkers.
2023-08-05modules/checkers: til_module_setup_full() for fill_module=Vito Caputo
Switch to the generic til_module_setup_full() and rely on the "none" builtin's NULL res_setup on finalize to indicate when no fill_module is desired. This gets rid of the need for a separate til_module_t* handle for the fill_module, since til_setup_t.creator can be used for that, and the NULL til_setup_t* to indicate no fill_module. Basically discards some busy work style code, there's more cleanups needed surrounding this stuff though.
2023-08-05setup: handle ':' prefixes in setup_interactively()Vito Caputo
This was done for rkt_scener already, this commit brings interactive setup inline WRT :raw_value overrides on multiple choice settings.
2023-08-05modules/{compose,montage,rtv}: exclude builtinsVito Caputo
Basically everywhere the TIL_MODULE_HERMETIC|TIL_MODULE_EXPERIMENTAL exclusions were being applied needed TIL_MODULE_BUILTIN added. Mostly this is to prevent randomizers from tripping over builtins in the available modules lists they draw from. Because builtins aren't visually interesting by themselves, and in some cases don't currently even have a means of being randomized properly like ref's path setting. This wasn't needed previously since builtins were kept off the modules list altogether. But since 1a6210be that changed and they must be explicitly filtered by flag instead. Note I deliberately left the rkt case with just a TODO comment. It's not a randomizer situation, and it might be acceptable to let rkt just show everything all the time in the module lists. That whole situation there is for advanced users. Also note that without this, rtv et al would easily trigger an assert on NULL setup due to the "none" builtin. Since there's still work to be done there in callers properly handling NULL @res_setup on a successful finalize. But this commit mitigates that by avoiding the builtins in the randomizers.
2023-08-05til: use set_raw_value() in randomize_setup() overridesVito Caputo
Missed this in the last round of moving things to the new raw_value() setter/getter api This snippet of copy-n-pasta the few setup front-ends continue to have should really be factored out into a libtil helper
2023-08-05main: handle NULL res_setup a la "none" builtinVito Caputo
This will just quietly exit successfully if "none" is provided as the root rendering module. It's not really a case worth bothering with doing something more about... the user did this pointless thing on purpose. Let's just not crash. While here I may have fixed a bug surrounding til_quiesce() not being called on the teardown path.
2023-08-05til_builtins: add "none" builtinVito Caputo
Sometimes nested modules are optional, in those cases I've usually been using the "none" module name to indicate this and the ad-hoc setup stuff can easily bypass module setup on that. This commit is a step towards having a "none" builtin that provides a til_module_t.setup() which succeeds but only produces a NULL res_setup when asked to finalize. So if callers just handle a successful finalize case that writes NULL at res_setup equivalent to "disabled", this all Just Works. Currently that's not an expected thing, but future commits will bring everything else on the same page. For callers who want to require the module and not offer "none", they can just put "none" in the explicit exclusions list passed to til_module_setup_full().
2023-08-05til: make builtins first-class modules w/new flagVito Caputo
Also move builtins to a separate listing while at it For now this results in the builtins showing up in the modules list alongside the actual rendering modules. Future work must refine this UX, maybe by adding some metadata to the spec.values for categorizing/prioritizing what's shown always vs. what's present but hidden without asking to be shown hidden stuff or whatever. Just consolidating some junk and working towards every nested module setup going through the same machinery, and always being able to access the builtins.
2023-08-05modules/rkt: simplify setup finalizing via setup->creatorVito Caputo
This gets rid of the ad-hoc module lookups previously necessary for finalizing the nested module setups. Now that the til_estup_t.creator tracks the creating module, the rkt_scene_module_setup() wrapper can take care of finalizing.
2023-08-05til_setup,*: add til_setup_t.creator pointerVito Caputo
Particularly with nested modules it's annoying to have to stow the module separate from the setup during the setup process. If the baked setup included the module pointer in the non-module-specific-setup part of the setup, then nested settings could finalize using the generic module setup wrapper and just rely on this til_setup_t.creator pointer to contain the appropriate module. Which should enable tossing out a bunch of copy-n-pasta surrounding nested modules setup. Note this has to be a void* since til_setup_t is a generic thing used equally by both the fb code and the module code. Hence why this is called "creator" and not "module", as well as the void* as opposed to til_module_t*. Also if rototiller ever grows a sound backend, the setup machinery will be reused there as well, and it'll be yet another creator handle that isn't an til_fb_ops_t or a til_module_t. It's assumed that the callers producing these setups won't be trying to pass them to the wrong places i.e. a module setup getting passed to an fb backend and vice versa. I'm mildly annoyed about having to move the various til_module_t blocks to above the module's foo_setup(), but it seemed like the least annoying option. This may be revisited.
2023-08-04modules/rkt: make default module "compose"Vito Caputo
Most of the time in scener you want to add a compose, you basically never want blank, so the :blank thing was kind of silly from the perspective of what happens most often.
2023-08-04modules/rkt: utilize til_module_setup_full()Vito Caputo
rkt_setup() and rkt_scener_update() had distinct implementations for scene module setup. This consolidates that where trivial to both use the new til_module_setup_full() with appropriate parameters, wrapped up in rkt_scene_module_setup(). The finalizing phase is still ad-hoc which is mildly annoying, but if finalizing just passed into rkt_scene_module_setup() there wouldn't be the til_module_t onhand for sticking in rkt_scene_t. So the code to extract and lookup the module from the settings would still be needed anyways, as the whole til setup_func api isn't limited to modules so the baked til_setup_t doesn't come back with a til_module_t hanging in there. Maybe in the future this gets changed a bit, there could for instance be a void* in til_setup_t where something usage-specific goes, like the relevant module in the case of a module's setup. Something to consider for the future. Consolidating these in the pre-finalize phase at least ensures consistent behavior in initial rkt::scenes setup vs. scener editing/new scenes.
2023-08-03*: nested settings should get the raw valueVito Caputo
When creating nested setting instances, just pass down the full raw value so if there's any prefix on the value it can be realized as a prefix for the first entry in the nested instance.
2023-08-03modules/rkt,til: use set_raw_value() api for overridesVito Caputo
The application of overrides was still done via ad-hoc value manipulation. This changes to use til_setting_set_raw_value() in the obvious manner.
2023-08-03til_settings: honor til_setting_t.nocheck in spec_checkVito Caputo
Trivial refactor s/til_setting_spec_check/til_setting_check_spec/ so it operates on a til_setting_t as opposed to the bare value. With the containing til_setting_t onhand it can be responsible for bypassing the check when til_setting_t.nocheck is set. Adjusted callers in setup_interactively() and rkt_scener_update() accordingly.
2023-08-03modules/rkt: don't disconnect on -EINVAL from finalizeVito Caputo
It's relatively acceptable to use this hammer for the other errors like ENOMEM especially when this isn't some enterprise-y service that must endure overload conditions gracefully. But the setup_finalize() step is rather likely to find invalid settings, especially now that til_setting_t.nocheck with the ':' prefix is a thing. This commit doesn't try resume the setup at the invalid setting (yet, that will require further til_module_t.setup() method work), but it at least doesn't rudely disconnect. The user just gets dumped back to the SCENES state main prompt.
2023-08-03modules/rkt: use the raw module name when randomizingVito Caputo
The existing code assumed til_module_t.name was equivalent to the name setting's value. That's no longer a safe assumption, and if the module was made possible via something like nocheck, that needs to be preserved in the randomized setup. So this gets the name out of the setting instead, using the new raw value getter.
2023-08-03modules/rkt: support ':' prefixed setting valuesVito Caputo
This makes RKT_SCENER_FSM_SEND_NEWSCENE_SETUP* handle ':' prefixed values correctly, now using the new til_setting_[sg]et_raw_value() API instead of directly messing with til_setting_t.value. It should now be possible to specify anything as a value regardless of what's in the list for multiple choice settings. Which does create opportunity for serious breakages... there will definitely be crashes if you do silly things. Some til_module_t.setup() methods have historically assumed the spec_check would police the values reaching them. Those will have to be made more robust now that this is getting wired up.
2023-08-03til: til_module_setup_randomize() raw value for spec.preferredVito Caputo
Now whenever a setting value/preferred input is derived from a setting, it'll want to get the raw value to preserve any prefix.
2023-08-03til: always apply filters in til_module_setup_full()Vito Caputo
The filter bypass was kind of a hack and resulted in unfiltered module lists in rkt_scener edits. Now that there's an explicit syntax for bypassing checks, the user can just do that to access what's filtered. So get back to appropriately consistent filtered results.
2023-08-03modules/rkt: rkt_setup() s/blank/:blank/Vito Caputo
Since blank is a builtin, at least for now it requires explicit override since the builtins aren't added to the modules values list and filtering is going to be always applied shortly.
© All Rights Reserved