| Age | Commit message (Collapse) | Author |
|---|
|
This is one of those crufty *NIX/C things. I'm tempted to just
rename these to TIL_MIN/TIL_MAX, but here just avoid redefining
them and accept what's predefined assuming it behaves the same.
Tripped over by Sketch building on an M1 MacOS box
|
|
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.
|
|
Trivial fixup; this will always assert on the NaN case which is
expected when ratio=full.
|
|
First stab at supporting explicit aspect ratios.
This performs the adjustment when needed in til_fb so it's
automatically applied to all fb backends.
The syntax is ratio=W:H with ratio=full being special cased for
when no aspect ratio adjustment is desired (just use whatever the
fb page dimensions are, usually specified via size= in the fb
backend's settings, or display native res when fullscreen=on)
For now when an aspect ratio is specified it always fits the
content within the alotted space... there is no
full-but-ratio-preserved-by-clipping-if-needed variant like widescreen
TVs often have.
|
|
Preparatory commit for aspect ratio settings at the fb layer.
This slightly reworks how main::setup_video() integrates the
selected fb backend's setup_func to better resemble how the
module setup_funcs work now, with more clearly separated
settings-building and setup-baking/finalizing phases. Which
makes inserting the ratio setting in the middle of the front-end
and back-end setup_funcs fairly trivial.
Not a fan of all the casts, but there will probably be more
helpers introduced to take care of that and make
til_video_setup_t more of a first-class thing facilitating the fb
stuff.
|
|
Preparatory commit for wiring up aspect ratio settings at the fb
middle layer. This will be a bit crufty initially, but should
cleanup alright over time. til_video_setup_t will be passed
around the fb stuff instead of a bare til_setup_t.
|
|
Noticed while working on unrelated til_fb stuff; once
_til_fb_page_new() started taking a mutex, its use in
til_fb_new() was too early relative to initializing said mutex.
Funny that this never blew anything up nor angered ASAN, just
having the memory allocated and zeroed goes a long way towards
hiding such things... for better or worse.
|
|
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.
|
