| Age | Commit message (Collapse) | Author |
|---|
|
Just moving some unnecessary computation and derefs out of the
inner render loop... nothing major, good for about +1 FPS here.
|
|
clang rightfully complained about this, these are floats
|
|
This oversight was triggering warnings on an M1 Macbook/clang.
|
|
Small micro optimization avoiding bounds check for respawned
elements, plus comment fixup.
|
|
Due to floating point errors this loop would occasionally miss
the last spoke as-is.
A quick fix is to just round down the accumulator before
comparing it... this function in general needs to all be cleaned
up, esp. since the conversion to floats.
An obvious repro of this issue, fixed by this commit:
'--module=spokes,iterations=2,count=3,twist=0.125,thickness=2' \
'--video=sdl,ratio=full,fullscreen=off,vsync=on,size=640x480'
The low count of 3 makes the missing spoke quite visible...
|
|
This was done in the obvious way, using a little accessor
everywhere the T value s retrieved that checks+applied the
current setting.
|
|
This overlaps somewhat with bottom={a,b}, but applies generally
to all styles.
The reasoning behind this is the same as bottom=.
Not this is only the setting, not the implementation, which will
follow shortly.
|
|
This makes the setting actually transpose a_module<->b_module for
style={interlace,paintroller,sine}. The default is for a_module
to be the logical bottom (bottom=a).
|
|
This adds a bottom={a,b} setting when
style={interlace,paintroller,sine}
Note this only introduces the settings, not the implementation.
The impetus for this is when experimenting with mixer transitions
in a work-in-progress, you'll sometimes want to invert the bottom
vs. top layers just to see how that looks. Instead of having to
transpose the a_module<->b_module setting values, this provides a
separate setting achieving that, which will simply be ignored for
the irrelevant mixer styles.
Conceptually "bottom" vs. "top" doesn't really apply to all the
styles however. style=interlace already feels a bit forced to
include here, but in the code it's clearly part of a group with
paintroller and sine, so it's included here.
But one could argue that *all* styles should have some kind of
toggle to swap a_module<->b_module. Except there will probably
be another setting introduced to invert T as well, which would
effectively achieve that for the modules where "bottom" vs. "top"
doesn't conceptually fit.
|
|
This adds a common retro demo transition using
converging/diverging horizontally interlaced sine offsets to
transition to/from a_module->b_module
Some stubs have been left in place for a vertical variant, and
some TODOs for future settings/taps. As-is it's a largely fixed
horizontal thing, introducing just the new style=sine variant
with no additionl settings or taps for now.
I particularly enjoy:
--module=mixer,style=sine,a_module=roto,b_module=roto
|
|
This switches the perimeter and stride math to use floating
point, done in a kind of fast and nasty naive substitution
manner.
That's necessary for getting away from the even stride
calculation / spokes calculation in favor of supporting arbitrary
spoke counts, without introducing discontinuities at the
boundaries of the mirrored sides
The new setting is count= with a handful of reasonable presets.
It's a little awkward since this is expressed as half the actual
count, naming could probably be improved.
|
|
This isn't actually needed just for the settings now that
til_module_context_t.setup always has a reference to the baked
setup, and always gets created even if there's no bespoke context
created.
|
|
Let's not handle negative values for these in the setup, even if
it's all multiple choice options that don't include erroneous
negatives. Technically you can feed in whatever using the ":"
force prefix...
|
|
Just starting to transition obvious integer taps from float to
ints.
|
|
It's looking like truncation is more often annoying, let's try
rounding.
|
|
Previously only FLOAT and DOUBLE were handled, and several module
taps have been created as those types to make them available for
rkt sequencing despite being integers. (book/page for instance)
As more taps get implemented, it'll only become increasingly
silly for everything needing an integer sequenced to be handling
this conversion itself when a generic clamp+truncation would
suffice.
This commit adds such handling of integer taps. No rounding is
performed, nor wrapping on overflow/underflows. Just clamping to
the type's limits as defined by {stdint/float}.h (while at it
I've added clamping of the FLOAT type which technically was
already necessary but ignored).
Future commits will likely switch some FLOAT taps to appropriate
integer types, cleaning up some ad-hoc conversion code in various
modules.
|
|
This assumption broke with the introduction of a default tile for
non-overlay mode.
|
|
This module started out as a way to test a line drawing algorithm, but
ended up looking interesting enough to include as a module of it's own.
#ZephyrCommit #BirdwalkCommit
|
|
This module cycles through a set of modules referred to as pages.
Settings include:
pages={list,of,modules}
rate=float page flipping rate
direction=float page flipping direction
taps are exposed for controlling rate and direction real-time,
with the addition of an explicit page index tap for overriding
the automatic flipping normally influenced by rate and direction.
Note that when using rkt with these taps, it immediately becomes
limiting that there's no ability to specify NaN as a track value
for temporarily relinquishing control of the page idx. It'd be
very useful to let the automatic flipping run the show at
whatever rate the rkt tracks specify, until the page idx was
asserted to a specific page, then holding it on that page until a
NaN row for the page track was encountered, restoring automatic
flipping. This needs to get added in both the Rocket library and
RocketEditor to be supported, as well as getting wired up to the
rkt integration.
|
|
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.
|
|
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
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
Minor oversight when this was written, this fragmenter is private
to checkers.
|
|
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.
|
|
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.
|
