| Age | Commit message (Collapse) | Author |
|---|
|
This is primarily intended for overlay use, but when not an
overlay uses a little builtin seed-derived tile as a fallback.
Currently the only settings are {x,y}=-1..1 for the direction
vector. Speed is currently fixed to 1, the vector is always
normalized.
Nothing terribly exciting.
|
|
|
|
|
|
This introduces a Second Reality inspired transition I've dubbed
"paintroller".
When selected, you get two additional settings:
orientation={horizontal,vertical}
passes={N}
There's room for improvement, like the fragmenter should probably
be chosen differently depending on orientation.
|
|
This is mostly just a preparatory commit for style=paintroller,
but style=interlace overlaps with it in this area so broke out
into separate commit for the interlace-relevant part.
|
|
If a caller wants to rely heavily on til_fb_fragment_copy() for
clipping, it'll be normal for situations like zero or negative
W/H of the clipped area. Those would just be zero copy
scenarios, so simply return instead of asserting.
|
|
This was accidentally inverted, which is especially annoying when
experimenting with styles - the T value should be equivalent
regardless of mixer style.
Trivial fix.
|
|
Near the fringes of 0,1 it should just be considered 0,1, which
handles rounding error as well as slightly increasing the
quantity of frames the fast path will tend to run on interpolated
fades.
|
|
Another mixing variant. Similar cost to style=blend in that it
must render both [ab]_module every frame, but doesn't have the
overhead of interpolating the pixels.
As-implemented this always interlaces by horizontal line
granularity. It'd be nice to be able to vary that with a runtime
setting to make it potentially chunkier.
|
|
No functional change except technically the ticks to rads modulo
|
|
Apparently no existing were really taking advantage of this
ability. The x,y,w,h parameters are also supposed to impart clip
bounds, should they be smaller than the union of the src and dest
fragments.
|
|
Prior to eb13ccdb (use sysconf on *nix) this #ifdef bug went
unnoticed because the non-MACH code still compiled successfully
on windows, just never got executed because the windows block
returns.
But after eb13ccdb the sysconf stuff needs defines not present
for windows and things won't build, uncovering this silliness.
Now only build the windows code on windows, and the non-win code
everywhere else... with MACH being a special case of the
everywhere else default.
|
|
This can potentially be negative depending on what n_queued
returns, and the early-exit comparison considered that by using
<= 0 but size_t is unsigned, so it just wraps around then
segfaults in the Very Large Copy attempt.
Trivial fix, interestingly discovered during windows testing
where the SDL driver was readily causing this to go negative - it
never happend in linux testing.
|
|
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.
|
|
These were missed by 6c657a9
|
|
This is a bare minimum binding of some critical knobs so rkt can
influence spiro
|
|
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.
|
|
For modules like modules/playit, it's desirable to easily keep
them out of randomizers picking visual modules to use and the
like. Until now that's been achieved via its experimental flag,
but that should go away.
|
|
clang gets upset about this, so make it explicit.
|
|
This was surprisingly not angering gcc but throws a warning under
clang, it's a real mistake.
|
|
When seekable libplayit was leaking the prerendered buf.
It's generally harmless since this tends to only occur once per
invocation and process exit cleans up anyways. But it's nice to
keep ASAN/leak reports free of noise.
|
|
This adds a new "meta" module which registers itself as a
pre-render context on the stream, to render whatever module is
specified as the "module=" setting.
The impetus for this is background music in rkt creations, so one
can avoid enduring the rigamarole of plugging something like a
"playit" instance into every scene.
With this "pre" builtin one can just use something like
"pre,module=playit,itfile=music.it" as a scene, and that will get
the playit module playing music.it hooked into the stream,
without the need to always have it present in every scene's
settings.
There's a TODO item noting the need for taps to control the
active/inactive state of the pre instance this adds. For now,
once you have a "pre", whatever module it contains will be
rendered before the main stream context set
w/til_stream_set_module_context() gets rendered. That's fine for
now, but there will need to be more control especially as more
complex productions happen involving multiple songs.
|
|
Since ref can be used to reference any module type by path,
including ones that don't touch the fragment, it's inappropriate
to integrate via render_fragment() since that will cause an
implicit clear of the fragment.
This is exactly the type of scenario render_proxy was added for,
so use it here.
|
|
Like til_module_t.render_audio(), this hooks into the render path
without triggering the implicit fragment clearing of the usual
render_fragment/prepare_frame/finish_frame methods.
But unlike render_audio(), it receives the full suite of
parameters including the fragment pointer.
The impetus for this is implementing builtins that serve as a
sort of pass-thru or proxy to another module, like the "ref"
builtin (which should probably change to use this instead of its
current render_fragment() hook). Because sometimes the proxied
module isn't something drawing to the fragment, so the implicit
fragment clearing shouldn't occur. But if the proxied module
/does/ touch the fragment by implementing one of those methods,
then the proxy module's use of til_module_render() would still
trigger the implicit clear when appropriate.
|
|
This adds an api for maintaining a list of pre-render module
contexts on-stream which will be rendered via til_stream_render()
before rendering hte main module context on the stream that's
been set via til_stream_set_module_context().
til_stream_add_pre_module_context()
til_stream_del_pre_module_context()
are the new functions, no references are taken for now (but
comments note the possibility of adding that)
This is just a preparatory commit, no real functional difference.
|
|
til_stream_render() bumps the frame counter, so there's no more
need for a discrete frame start mechanism.
|
|
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.
|
|
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.
|
|
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
|
|
There's already a pause triggered here, but the audio wasn't
getting paused as well.
|
|
Replace vestigial casted setup dereferences with already present
local typed setup variable.
|
|
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.
|
|
- 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.
|
|
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.
|
|
More preparatory work for adding an .IT file playback module
|
|
Preparatory commit for implementing an .IT file playback module
|
|
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.
|
|
Preliminary means of making the audio context available to
modules.
|
|
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.
|
|
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.
|
|
Preparatory commit for a vsync setting sharing these values.
|
|
Preparatory commit for introducing c->renderer_flags to allow
vsync configure at runtime.
|
|
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().
|
|
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.
|
|
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.
|
|
Preparatory commit for implementing nonblocking connects in
modules/rkt, shouldn't change anything by itself.
|
|
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.
|
|
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.
|
|
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}.
|
|
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.
|
