summaryrefslogtreecommitdiff
path: root/src/modules
AgeCommit message (Collapse)Author
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-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-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-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-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-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.
2023-08-01modules/rkt: make the default base= "rkt"Vito Caputo
The "tiller" base (base being a Rocket concept) was always a bit spurious. Maybe "til" would make more sense, but "rkt" is more contextually specific. I think when I originally picked "tiller" I was prioritizing picking something unlikely to collide with another directory name. But the way Rocket is naming the directory in the filesystem it gets suffixed with an _ anyways.
2023-08-01modules/rkt: make "blank" default scenes=Vito Caputo
The "compose,compose,compose,compose" default was never intended to be permanent, but gave a set of scenes to test the Rocket integrations like scene selection and scene-specific tracks without any additional effort. Now that there's scener for easily adding/editing scenes, and things are just generally more mature, I think it makes sense to just go back to something minimal here. I'd really rather just have it be "", but that's not handled well presently. There isn't really a way to start with an empty scenes set for rkt. Which is awkward, but "blank" is close. It'd just be nice to start with an altogether blank slate rather than having to always edit the default first scene when starting anew...
2023-07-31modules/rkt: remove TIL_MODULE_EXPERIMENTAL flagVito Caputo
Now that the "scener" interface seems to be semi usable and capable of editing... things are looking more complete in the sense that there's no huge gaping holes and a lot of the dust has settled. It's also looking pretty good for this sticking around long-term, so I'm removing the experimental flag making this more discoverable and visible in general. There's still work to be done surrounding GNU Rocket the library, like getting it using non-blocking connects, and there's a need for forgetting tracks which the protocol doesn't support currently. But it'd be silly to wait on getting those things upstream before making rkt more visible.
2023-07-31modules/signals: experimental signals moduleVito Caputo
Playing with libs/sig in 2D, this isn't really an interesting module by itself in terms of visual output. But it might have utility as a diagnostic thing if libs/sig becomes a more used thing. At the very least, for now, it's useful for observing affects of and iterating on libs/sig development. So I'm merging this, just gated behind TIL_MODULE_EXPERIMENTAL so it's not in rtv rotation or presented as something in the usual modules list.
2023-07-30modules/rkt: first stab at scene editing for scenerVito Caputo
This augments the NEWSCENE_SETUP state to also handle editing existing settings, which is slightly different but actually overlaps with the already implemented invalid input stuff. There's still work to do, and the UX is kind of awkward at best. But this takes us from having no ability to edit existing scenes, to being able to actually make edits interactively while it's all live... with a modicum of interactive guidance via the setup machinery. It basically behaves just like creating a new scene, except instead of the <enter>-accepted "preferred" values, you accept the existing relevant setting. So as-is, when editing, you have no shortcut for getting back the "preferred" value for a given setting. That's been replaced with the existing value for that setting. You also get seemingly spurious redundant queries for module names in things like compose::layers, but they're really not the same since the first time you get asked it's actually the full settings string you're getting an opportunity to specify wholesale, but can accept to seed the layer's settings as-is, which you will then be given an opportunity to edit piecemeal. It's that subsequent piecemeal editing of the individual settings within the nested instance that can feel like a spurious duplication, especialy when a given layer has just a bare-value module name and no subsequent settings.. like "plasma". You'd be asked if you want "plasma" for the layers/[N], then asked if you want "plasma" _again_ for the layers/[N]/[0] since the module name is an unnamed setting at position 0 within the layers/[N] instance. It was tempting to try streamline that a bit, but there's actually utility in having an opportunity to paste in a full settings string for the layers/[N] if you have a serialized scene onhand you want to dump in there. Then after that, you can juts smash enter as much as necessary to accept what you pasted in without editing those in the piecemeal phase. Or, if there was actually something in what you pasted you did want to change, change it during that piecemeal phase. I think it at least kind of works.
2023-07-30modules/checkers: add blurb about context clonesVito Caputo
There's an outstanding issue surrounding the need for context clones, and I'd just like to write something down somewhere before it falls off my radar. Presently it's just checkers that exercises this need, so it makes sense to put it here for now, until I get around to actually taking action on the issue.
2023-07-28modules/*: use til_fragmenter_slice_per_cpu_x16() where applicableVito Caputo
Mechanical change switching til_fragmenter_slice_per_cpu() users over to til_fragmenter_slice_per_cpu_x16(), except sparkler where it's quite detrimental to performance.
2023-07-28modules/rkt: minor error message formatting fixVito Caputo
Better spearate the generic error line from surrounding text with an extra newline
2023-07-28modules/rkt: s/_EDITSCENE/_SCENE/Vito Caputo
This was a bit of an aspirational misnomer, editing scenes isn't actually implemented yet. What the EDITSCENE state currently implements is the per-scene dialog+prompt, which originally was going to just be the scene editing flow but became more of a "view a specified scene's details" with a prompt of its own. Nothing functionally changes, just mechanical internal renames.
2023-07-25modules/rkt: fix vestigial til_str_newf() useVito Caputo
This is leftover from development when it used a fmt string in combination with the key, before the desc path was getting properly appended.
2023-07-21modules/shapes: drop atan2_approx()Vito Caputo
With the addition of the "radcache" in b6362c, the need for a faster approximate atan2f() is largely eliminated. And there seems to be a bug in the implementation as-is taken from https://mazzo.li/posts/vectorized-atan2.html You can see the bug as vertical line artifact around the center where the X coordinate would be 0. Rather than debug what's wrong with this approximation's implementation surrounding its quadrant adjustments, let's just resume using atan2f() and let the cache keep things quick.
2023-07-17modules/rkt: limit Rocket reconnect frequency to 2HZVito Caputo
On Linux I don't notice a significant affect on anything letting rkt try connect every frame when offline but in creative mode. On Windows however, Dan reported significant latencies in the Scener prompt responsiveness and visible slowdowns in this condition. I suspect the WIN32 Rocket library's sync_tcp_connect() code is the real problem here. But for now I can ameliorate things a bit by just hammering on that code path less when unconnected.
2023-07-16modules/rkt: pause on entering scene 99999Vito Caputo
This is only relevant to creative mode. Stops RocketEditor from continuing playback endlessly until user intervention beyond the current end of the demo.
2023-07-16modules/rkt: track last scene in ctxt->last_sceneVito Caputo
Prepartory commit for pausing playback upon entering 99999 scene It needs to trigger only on the edge of entering the scene to permit RocketEditor to unpause playback even if still in scene 99999, if that's what the user is trying to do. It'd be annoying to have it just keep asserting a paused state until the scene idx leaves 99999... But this also enables triggering anything on scene change edges, for future stuff.
2023-07-16modules/rkt: cleanup Rocket track namesVito Caputo
- strip off the leading /path/to/rkt/module prefix - separate taps from their scene context path with ':' vs. '/' RocketEditor doesn't currently support recursive grouping, so this is as good as it gets. Note this commit will break the existing tracks for alphazed, so you'll have to use a newer .zip for track data if building your rototiller from source. Or build from a prior commit.
2023-07-16module/rkt: pull rkt_context_t to sync_get_trackfVito Caputo
Preparatory commit for rewriting track paths a bit to better group things in RocketEditor. I'll need access to rkt_context_t.til_module_context_t.setup->path for prefix matching purposes..
2023-07-15modules/roto: implement fill_module= settingVito Caputo
This makes it possible to tiled+rotate the output of another module in the same manner checkers::fill_module fills cells with module output. The default stays "none" for the classic roto with the psychedelic color cycling. When !"none" the color cycling doesn't get applied currently. It might be interesting to try support that in the future though.
2023-07-14modules/rkt: remove vestigial "/scenes" path appendVito Caputo
During rkt_scener development this append was at one time needed, as there was no retained reference to the scenes_settings for deriving paths from. Now that the path is derived from the actual scenes setting instance it's just resulting in a double trailing /scenes in the "/module/rkt/scenes/scenes:" heading Purely cosmetic fix
2023-07-13modules/rkt: '=' for current Rocket scene in scenerVito Caputo
Pressing '=' at either prompts now makes scener's current scene the current Rocket scene. While you could already do this manually by just looking at the scenes list for the one with the '*' in the Rocket column while either watching a production and pressing <enter> repeatedly to keep refreshing the scenes list... that's cumbersome and annoying, now just use this shortcut. Since this just copies Rocket's scene to the Scener scene index, it needed to properly handle scene 99999... hence the previous commits.
2023-07-13modules/rkt: include EXITED [99999] in scenes listVito Caputo
While there's no actual context for 99999, it's a state we need to represent visibly somehow.. so just make it appear like an epilogue scene off the end. I've included the Rocket/Scener/Pinned status columns consistently as well so you at least still get a visible indication when you've done something like pinned 99999 somehow (not that this is possible presently, but with future changes there will be more ways to copy the Rocket idx into Scener's idx)
2023-07-13modules/rkt: add 99999 exit scene defineVito Caputo
rkt_scener needs to know this value so define it in rkt.h and switch over all the existing 99999 instances.
2023-07-12modules/rtv: perform gc immediately in cleanup_channel()Vito Caputo
Until channel context paths are distinct it's buggy to let the contexts linger while constructing the next channel's contexts. Originally when the gc was added here the intention was to support stuff like the "ref" module and get the channels settings wired up immediately with more focus on rtv's details in this area. Supporting stuff like contexts backing some layers persisting across channels, while the others were swapped out, seemed potentially interesting (and it still is). But the rkt stuff became prioritized as rtv is more like a fuzzer than anything despite being the default module. And rkt related activities will continue for now, so let's just get rtv less likely to crash. A reliable repro for triggering an ASAN UAF bug without this commit is: --seed=0x64af3b05 '--module=rtv,duration=1,context_duration=1,channels=compose,caption_duration=2,snow_duration=0,snow_module=none,log_channels=on' '--video=sdl,fullscreen=off,size=640x480' A few channels in blinds will UAF while updating taps stored in a freed context, because the previous channel has a blinds in the same layer as the newly setup channel, putting the contexts at exactly the same paths on-stream. There's probably another bug in here that I need to dig into, but coexisting contexts at the same path on-stream was never the intention. The syncronous immediate gc ensures nothing remains of the previous channel before constructing the new one at the same path.
2023-07-12modules/rtv: fix settings path for channel settingsVito Caputo
The channel module name was being used as the settings instance name, which is redundant to the entries[0] "value as label" behavior with the module name also @ entries[0]. The resulting paths resembled: /module/rtv/compose/compose/layers/[N]/... /module/rtv/compose/compose/texture/... Now they are: /module/rtv/channel/compose/layers/[N]/... /module/rtv/channel/compose/texture/... There's still work to be done in this area of rtv. It's unclear if even a static "/module/rtv/channel" is correct, or if it should show the subscript of the channels[] entry currently being used when that becomes a proper nested settings situation, i.e. /module/rtv/channels/[0]/compose/layers/[N]/... ... /module/rtv/channels/[1]/spiro ... /module/rtv/channels/[2]/roto ... for a "channels=compose,spiro,roto" kind of hypothetical another option which might make sense is to have the channel path more like an auto-increment identifier so the channel contexts have unique paths and don't collide on the stream. This could be important for scenarios utilizing the "ref" module and trying to reuse parts of the context from one channel to the next. When the paths collide things tend to break in weird ways presently. this area needs more thought
© All Rights Reserved