summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-11-18til_stream: drop til_stream_start_frame()Vito Caputo
til_stream_render() bumps the frame counter, so there's no more need for a discrete frame start mechanism.
2023-11-18main: use new til_stream_render() apiVito Caputo
Instead of just calling til_module_render() with the top-level module context, use the newly added til_stream_render() and til_stream_set_module_context() to achieve the same thing. This is a preparatory commit for handling pre/post-render module contexts automagically in til_stream_render(). e.g. stuff like background music would be hooked into the stream as a pre-render context.
2023-11-18til_stream: add til_stream_render()Vito Caputo
This introduces a concept of a stream's module context, which is used to render the stream via til_stream_render(). The context is set using til_stream_set_module_context(), but at this time no reference is taken - it just puts the context into the stream for use by the render calls. The caller is responsible for ensuring it persist as long as the stream uses it. This is a preparatory commit for implementing pre/post render module contexts that get hooked into a stream. The impetus for this is supporting background music via modules like playit, without requiring stuff like rkt scenes to always include the bgm context in the scene's module context heirarchy. Nothing is functionally different here, the commit only adds the new interfaces for setting the context and rendering via stream instead of til_module_render() of the context you'd now set on the stream.
2023-11-18drm_fb: use shadow buffers when device prefers itVito Caputo
I noticed the sdl_fb backend seemed to often have significantly better FPS in fullscreen use vs. drm_fb fullscreen. Looking at the libdrm api I saw this PREFER_SHADOW capability and noticed my laptop's gpu driver sets it... With this change, despite the additional memcpy(), the drm fullscreen FPS seems significantly better. A subsequent commit will make this an overridable runtime setting
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-14build: build and link libplayitVito Caputo
More preparatory work for adding an .IT file playback module
2023-11-14libs/playit: add libplayit submoduleVito Caputo
Preparatory commit for implementing an .IT file playback module
2023-11-14til: introduce til_module_t.render_audio entrypointVito Caputo
Simple audio rendering modules need a way to render their audio without affecting the fragment's state. By providing a til_module_t.render_audio() a module indicates it's only an audio renderer, and its render won't trigger an implicit clear of the frame's fragment. There might be a new flag added to indicate when modules are audio modules, but this is good enough for now.
2023-11-14til_stream: add til_audio_context_t to til_stream_tVito Caputo
Preliminary means of making the audio context available to modules.
2023-11-14til: add preliminary audio backendVito Caputo
This is an early implementation of something resembling an audio backend for rototiller/libtil. The assumption for now is that everything will use signed 16-bit native-endian stereo output @ 44.1khz.
2023-11-10build: restore -Werror to CFLAGSVito Caputo
f89689b unintentionally removed this for some reason. Just noticed a build with warnings wasn't failing...
2023-11-09sdl_fb: introduce vsync={on,off} settingVito Caputo
Defaults to on, controls inclusion of SDL_RENDERER_PRESENTVSYNC in the flags passed to SDL_CreateRenderer(). Useful for obesrving how high FPS can be with the overhead of the GPU upload, unlike --video=mem which tells you how fast FPS can be entirely headless.
2023-11-09sdl_fb: s/fullscreen_values/bool_values/Vito Caputo
Preparatory commit for a vsync setting sharing these values.
2023-11-09sdl_fb: s/flags/window_flags/Vito Caputo
Preparatory commit for introducing c->renderer_flags to allow vsync configure at runtime.
2023-11-06doc: mention YouTube development playlistVito Caputo
HACKING.txt should point readers interested in such things to the video tutorials now that there's enough content in that playlist to start being potentially useful:
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-31libs/rocket: bump submodule for new sockio supportVito Caputo
Preparatory commit for implementing nonblocking connects in modules/rkt, shouldn't change anything by itself.
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-16doc: add YouTube playlist URL to READMEVito Caputo
The playlist isn't comprehensive yet, but it's better than nothing for folks that just want to see something before spending time on figuring out how to clone, build, execute, etc.
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-11doc: minor HACKING.txt fixupVito Caputo
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: implement txt_render_fragment_offsetted() variantVito Caputo
Instead of rigid txt_align_t enums to specify how the text is aligned relative to the x/y coordinates, you specify float offsets in normalized coordinates -1..+1 allowing fine-grained control of the offsets. modules/asc will use this to automatically adjust the offsets when requested, so x/y coordinates may be varied dynamically using taps with the text automagically adjusting its offset to try stay in-fragment.
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-03libs/txt: fix width measurement without a \nVito Caputo
Silly oversight preventing some haligns from working right if the string doesn't have a newline... uncovered while testing a new txt module's alignment settings.
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-10-02til: introduce til_value_to_pos() helperVito Caputo
This copies from checkers_value_to_pos() turning it into a libtil helper. It's a common operation in setup_funcs to map a setting value to a numeric position in the list of values.
2023-09-08til_builtins/blank: add force= settingVito Caputo
When using the blank builtin for profiling purposes it can be necessary to ensure it actually incurs the cost of clearing.
2023-09-07doc: add links for browsable source repo to READMEVito Caputo
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-07doc: trivial fixup to README citationsVito Caputo
fix misplaced :
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.
© All Rights Reserved