summaryrefslogtreecommitdiff
path: root/src/modules
AgeCommit message (Collapse)Author
2023-11-21modules/rkt: send \r\n instead of \n from scenerVito Caputo
The nature of scener is to also be used from windows clients like windows telnet, but just sending \n to that results in stair-stepping.
2023-11-21modules/{compose,mixer}: more TIL_MODULE_AUDIO_ONLY exceptsVito Caputo
These were missed by 6c657a9
2023-11-19modules/spiro: add some taps for controlling l/k/roundsVito Caputo
This is a bare minimum binding of some critical knobs so rkt can influence spiro
2023-11-18*: apply TIL_MODULE_AUDIO_ONLY where appropriateVito Caputo
This changes modules/playit from experimental to "audio only". Several other modules now incorporate the new flag into their excludes to prevent inclusion where inappropriate.
2023-11-18modules/flow: silences warnings about implicit castVito Caputo
clang gets upset about this, so make it explicit.
2023-11-18modules/asc: fix asc_setup_t.halign type mismatchVito Caputo
This was surprisingly not angering gcc but throws a warning under clang, it's a real mistake.
2023-11-17modules/rkt: pause audio too on no scene/end pauseVito Caputo
There's already a pause triggered here, but the audio wasn't getting paused as well.
2023-11-14modules/compose: trivial cleanupsVito Caputo
Replace vestigial casted setup dereferences with already present local typed setup variable.
2023-11-14til_stream,rkt,main: add stream audio controlVito Caputo
Until now everything interested in audio just used a plain getter on the stream to get at the context. But with how things work currently, audio is always left in a paused state until explicitly unpaused. This works fine with modules/rkt, which manages pause/unpause explicitly. When there's nothing like modules/rkt in charge though, the audio just sits stuck paused. Meaning if you do some simple thing like --module=playit, it won't ever get unpaused. With this commit, something like modules/rkt takes control of the stream's audio context, in a way that prevents anything else from taking control of the same context on the same stream. That enables having main try take control of the audio context after creating the module contexts, then in the rendering thread ensure the audio is unpaused if main is in control of the audio context and something's queueing audio frames. For now there's no mechanism for releasing control of the audio context. It doesn't seem appropriate to make this more elaborate than necessary. There's basically just two use cases WRT audio: 1. Something like rkt, which takes control once for the process and stays in control until process exit. 2. Something far simpler where nothing's taking control like rkt, and main just needs to get things unpaused when needed because something's generating audio frames.
2023-11-14modules/rkt: begin til_audio integrationsVito Caputo
- til_audio_seek() when Rocket sets the row - til_audio_{pause,unpause}() when Rocket (un)pauses This is of limited use as-is, rkt probably needs a sister concept of scenes for songs, which similarly to scenes would be selected by index in a discrete Rocket track. As-is to make music work one must always incorporate something like a modules/playit context into the current scene so it always gets rendered alongside the visuals. That's quite cumbersome and annoying. Another possibility would be introducing something like a "register" built-in that, like "ref", takes a context path, and maybe something like a pre/post setting. That would put it in the rendering path of the stream before or after any explicit renders... Then all one would need is to register a modules/playit context with the song of interest to have it play, and create that as any other rkt "scene", and reference its context from "register" which could bind a tap for controlling the registered/unregistered state. It needs more fleshing out, but what's here seems worth merging as-is for now.
2023-11-14modules/playit: add an .IT file music player moduleVito Caputo
Rudimentary .IT file music playback via libplayit. When seekable=on, the file is 100% pre-rendered at context create, then simply copied into the audio queue @ render_audio. When seekable=off, the file is mixed incrementally per-frame @ render_audio in max of bufsize=N_frames increments. The bufsize here basically just determines the maximum time spent rendering audio in a single go, and how much tolerance of frame delays due to slow rendering there will be before dropouts occur.
2023-11-06modules/compose: handle layers/texture create failuresVito Caputo
Some trivial error handling improvements for compose... til_module_t.create_context() should really return -errno instead, since some modules try do stuff like opening files or network connections @ create_context().
2023-11-03modules/*: drop til_setup_t.free_func() NULL setup checksVito Caputo
Trivial cleanup. These are unnecessary nowadays since til_setup_free() won't invoke the free_func() on a NULL setup, and everything uses til_setup_free() to free a til_setup_t.
2023-11-02til,checkers: move checkers_rgb_to_uint32() to libtilVito Caputo
Becomes til_rgb_to_uint32(). Nothing functionally changed, just making this generally available for anything wanting to parse an rgb hex string into a uint32 packed pixel in a setup_func.
2023-10-23build: tidy up some Makefile.am filesVito Caputo
Been ignoring this mess for too long, just whitespace changes - nothing functionally different. This makes diffs far easier to read when libs or modules get added/removed etc. Some of the other Makefile.am files could use similar tidying, but these are the most commonly messed with in the course of rototiller development.
2023-10-19modules/stub: add a stub sample moduleVito Caputo
Intended as a bootstrap for new module creation, particularly aimed at new contributors. No module context, fragmenting, taps, or settings are implemented, to keep things as simple as possible.
2023-10-16modules/pixbounce: use float for multiplierVito Caputo
The lack of support for fractional multipliers prevents pixbounce from drawing anything in small frame scenarios, like as a checkers fill_module. You can easily reproduce this by doing: --module=pixbounce,pixmap_size=0.8,pixmap=err --video=sdl,size=64x64 --defaults --go Which after this commit works... While here I did a minor optimization removing some divides, and fixed up the assumption that fragment->{width,height} == fragment->frame_{width,height} in pixbounce_prepare_frame(). It should have been using .frame_{width,height}.
2023-10-11modules/compose: don't use *res_setting for textureVito Caputo
This is vestigial from pre-everything's-til_setting_t days, where the local setting values were just the bare char* value, requiring getting at the related til_setting_t via *res_setting. Now that's unnecessary since the local texture variable is now a til_setting_t*, so clean this bit up.
2023-10-11modules/blinds: uninline the per-blind functionsVito Caputo
In the pre-threaded blinds days these were tiny functions, not anymore. Plus it's not like there's very many blinds ever anyways so the number of calls isn't huge, making the syntactic sugar aspect of "inline suggests hot" a bit misleading here.
2023-10-11modules/checkers: staticify checkers_fragment_tile_single()Vito Caputo
Minor oversight when this was written, this fragmenter is private to checkers.
2023-10-04modules/asc: turn into a "built-in" moduleVito Caputo
This deviates from the established pattern of all built-in modules being in til_builtins.c, but that's ok. The main impetus for this is to just get asc out of rotation for randomized compose layers, since it's so uninteresting. But it's also valid as a built-in since it's primarily for diagnostic purposes anyways.
2023-10-03modules/asc: add justify= and [hv]offset= settingsVito Caputo
justify= now supports "aligned" and "offsetted", justify=aligned being the existing behavior where you would specify halign={left,right,center} and valign={top,bottom,center}. When justify=offsetted is specified however, {valign=,halign=} are unused and instead {hoffset=,voffset=} are expected, as either hoffset=auto/voffset=auto for automagic offsetting according to the x/y coords, or explicit offsetting using -1..+1 normalized fractional values serving as coordinates within the rendered text's rectangle where to anchor the x/y coordinate. By using halign=auto,valign=auto one can carelessly vary the x/y coordinates using the taps (i.e. via rkt) without having to deal with justification concerns (modulo large texts that can't possibly fit), as the offsets will automatically adapt according to the coordinates.
2023-10-03libs/txt,modules/*: rename txt_render_fragment()Vito Caputo
Mechanical rename to txt_render_fragment_aligned(), updating all existing call sites accordingly. This is a preparatory commit for introducing an offsetted variant of txt_render_fragment() (txt_render_fragment_offsetted()). No functional difference, purely naming changes.
2023-10-03modules/asc: tap x/y coordinatesVito Caputo
Nothing terribly exciting, the string can now be moved dynamically via taps in the usual manner. When nobody's driving the taps they just use the setting, still defaulting to 0,0 (centered).
2023-10-03 modules/flow: whitespace fixupVito Caputo
Just removing a spurious newline noticed while grabbing some taps boilerplate for asc...
2023-10-03modules/asc: implement a simple ascii text moduleVito Caputo
This just binds the simple libs/txt/txt.c stuff to a rendering module, exposing the minimal options as settings. It's handy for testing libs/txt/txt.c, and introduces a module requiring free-form strings potentially including newlines be handled properly as settings values. This latter aspect is important for improving settings syntax, any improvements must handle these more complicated scenarios and now there's a good test case for exercising those nuances. I suppose there might also be use in the creative process if you want a text element but haven't got around to hacking up a prettier module for it yet. Just use this one temporarily. See commit for some remaining TODO items.
2023-10-02modules/checkers: adopt til_value_to_pos() helperVito Caputo
Mechanical transition from checkers_value_to_pos() to the now libtil-provided equivalent of identical implementation.
2023-09-07modules/flow: add TODO blurb abot per-cpu seedsVito Caputo
Writing this down so it doesn't completely fall off my radar.
2023-09-06modules/flow: fix elements overflow bugVito Caputo
s->count isn't always perfectly divisable by n_cpus, which is why ctxt->n_elements is computed from n_cpus * elements_per_cpu in the transition to threaded rendering for flow. That's all fine and dandy, but the ctxt->elements initialization loop was still using the vestigial s->count from the pre-threaded implementation. So on core counts where ctxt->n_elements was smaller than s->count, initialization scribbled. Thanks Sketch for assistance in chasing this down w/ASAN enabled on a box that exhibited crashing w/rtv,channels=flow.
2023-09-05modules/flow: fix default countVito Caputo
57bae7 removed the default from the settings list when bumping the counts, oops!
2023-09-05modules/flow: add "(threaded)" labelVito Caputo
The convention has been to label threaded modules in their description.
2023-09-05modules/flow: bump the counts up a bitVito Caputo
Now that there's threaded rendering, handling larger counts without bogging down the frame rate on anything remotely modern is feasible.
2023-09-04modules/flow: restore previous Z depthVito Caputo
While optimizing the threaded rendering in commit 6d6c141, the pos.{xy} expanding from 0-1 to -1..+1 were eliminated from the inner loops in favor of just having the positions always in -1..+1 coordinates. But I missed that it was only the x/y coordinates which were being expanded, with .z being left in the 0-1 space, which had a desirable aesthetic effect of condensing the Z space, flattening everything. This commit undoes that, without reintroducing the expansion to the inner loops. It's a bit crufty because now .z is treated exceptionally throughout as 0..1 while {.x,.y} are in -1..+1, but it's fine for now.
2023-09-04modules/flow: implement threaded renderingVito Caputo
This exploits the just added multipass rendering support. In the first pass, the flow-field is sampled and applied to the elements, with every thread operating on its own subset of the elements list. Since the flow-field sampling is all read-only, it's perfectly safe too do in parallel. Nothing is drawn in the first pass, it's only the elements updating according to the flow-field which is performed. In the second pass, the elements are rendered in parallel using the slice_per_cpu fragmenter. Since the elements are kept on a simple array, with no spatial indexing, every thread must visit every element. Since the fragmenter used divides the frame into horizontal slices, every thread needing to reject elements not overlapping its region can take some shortcuts in easily identifying elements entirely outside its region. But the whole 3d->2d projection step must still be performed for every element's current position and +n_iters final position for the frame, which does have a divide unfortunately. Nonetheless, this change improves frame rates substantially on my 2c/4t i7 X230 as benchmarked w/--video=mem,1366x768: --seed=0x64fa9508 '--module=rtv,channels=flow,duration=3,context_duration=3,caption_duration=0,log_channels=on,snow_duration=0,snow_module=none' '--video=mem,size=1366x768' rtv channel settings: 'flow,size=4,count=40000,speed=.8' FPS: 261 FPS: 265 rtv channel settings: 'flow,size=4,count=1000,speed=.9' FPS: 1153 FPS: 3204 FPS: 2934 rtv channel settings: 'flow,size=8,count=5000,speed=.9' FPS: 2923 FPS: 1634 FPS: 1592 rtv channel settings: 'flow,size=2,count=50000,speed=.4' FPS: 1006 FPS: 219 FPS: 268 rtv channel settings: 'flow,size=16,count=30000,speed=.8' FPS: 304 FPS: 350 FPS: 343 rtv channel settings: 'flow,size=16,count=30000,speed=.02' FPS: 379 FPS: 503 FPS: 472 rtv channel settings: 'flow,size=8,count=1000,speed=.16' FPS: 1393 FPS: 3822 FPS: 3876 --- Prior to this commit: --seed=0x64fa9508 '--module=rtv,channels=flow,duration=3,context_duration=3,caption_duration=0,log_channels=on,snow_duration=0,snow_module=none' '--video=mem,size=1366x768' rtv channel settings: 'flow,size=4,count=40000,speed=.8' FPS: 53 FPS: 53 rtv channel settings: 'flow,size=4,count=1000,speed=.9' FPS: 426 FPS: 1366 FPS: 1335 rtv channel settings: 'flow,size=8,count=5000,speed=.9' FPS: 1097 FPS: 368 FPS: 367 rtv channel settings: 'flow,size=2,count=50000,speed=.4' FPS: 279 FPS: 73 FPS: 74 rtv channel settings: 'flow,size=16,count=30000,speed=.8' FPS: 71 FPS: 71 FPS: 70 rtv channel settings: 'flow,size=16,count=30000,speed=.02' FPS: 136 FPS: 305 FPS: 305 rtv channel settings: 'flow,size=8,count=1000,speed=.16' FPS: 972 FPS: 2593 FPS: 2634
2023-09-04til: support multi-pass renderingVito Caputo
Modules can now use the til_module_t.finish_frame() return value to trigger re-rendering by returning 1, returning 0 finishes the frame. A smattering of til_module_t.finish_frame() implementations were largely mechanically updated to match this change by returning 0, since nothing actually uses multi-pass rendering yet. The impetus for this is experimenting with the flow module doing two passes of threaded rendering per frame. A first pass to sample the flow field and update the elements, per-cpu, but drawing nothing. Then a second pass to render the elements in a tiled manner.
2023-09-03modules/flow: expose speed as a tapVito Caputo
Nothing too crazy here, the speed= setting still controls the speed in lieu of something driving the tap.
2023-09-03modules/strobe: trivial fixup; s/<=/</Vito Caputo
Remove strobe_update_taps() redundant assignment if already zero
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-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-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-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-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.
© All Rights Reserved