| Age | Commit message (Collapse) | Author |
|---|
|
I'm probably going to borrow some of these for headless text
rendering in vwm/vmon, just doing some paperwork first.
|
|
This doesn't seem to make any impact on performance, but it's
awkward to be modifying the supplied coordinate as if it's a
result... the coordinate input should be left alone, and should
be able to get reused across din calls so only the varying
members need to get updated across calls.
|
|
These are being assigned to ints to index the grid and will
become rounded down through truncation anyways.
This little change brings a ~20% FPS boost in modules/swab on
an i7 x230.
|
|
din() just samples the din_t which will always just be a
read-only operation, so constify this. It might even help the
compiler generate faster code for din-heavy inner loops like
modules/swab uses.
|
|
din() is a hot path for modules/swab in particular. Barring any
substantial changes to swab, which would probably make sense in
the long-term, there's some low-hanging fruit in libs/din.
Here smootherstep() has been made less general for a little perf
boost. The way din uses smootherstep() doesn't need these
bounds checks, nor does it need the caller-supplied edge values.
Also the asserts() have been disabled in the hot path as they
were mostly there for catching programmer errors and swab is
already done.
On my i7 x230 this takes swab from 44fps->54fps, so worthwhile,
but swab is still painfully slow here. It's largely just a
libs/din abuse module that was made to test libs/din, but turned
out to look interesting enough to keep.
|
|
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.
|
|
More preparatory work for adding an .IT file playback module
|
|
Preparatory commit for implementing an .IT file playback module
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
This commit makes ops_sin stateful by tracking last_ticks_ms and its
theta angle.
Unfortunately that necessitates serializing ops_sin on the output
path, currently done using a mutex.
See larger comment in ops_sin.c for why this is all necessary.
|
|
I thought the build was already using -Wall but that seems to not
be the case, maybe got lost somewhere along the line or messed up
in configure.ac
After forcing a build with -Wall -Werror, these showed up.
Fixed up in the obvious way, nothing too scary.
|
|
sig_t collides with some signals-related system header on macos.
Just prefix it under the sig namespace.. leaving sig_ops alone
for now, but maybe they'll become sig_sig_ops in the future too.
Note nothing in master actually uses libs/sig currently, but I
have an experimental branch with a dusty module using it.
|
|
Upstream merged my TCP_NODELAY PR, so let's get it in rototiller.
Note I'm blindly setting USE_NODELAY now, but it might actually
break the build for win32 - still need to test that.
|
|
Preparatory commit for experimenting with a GNU Rocket
integration for controlling the stream pipes on a timeline.
Since rocket doesn't support things like arbitrary strings, it's
not a natural fit for rototiller where the obvious thing would be
to describe scene compositions as settings strings as if you were
invoking rototiller.
But a temporary hack might be to just tell a rocket module
up-front all the scenes as settings strings you provide to its
setup. Those get assigned numeric identifiers, then rocket
tracks can control when they come on/off numerically. It just
requires describing all the scenes up front rather than in the
pattern editor which is less than ideal.
Being able to experiment with this half-ass solution may prove
useful anyways, and shouldn't be too much work.
|
|
Nothing uses libs/sig yet, but this will probably become an issue
once that changes.
|
|
also update call sites in modules/{meta2d,swab} accordingly
|
|
|
|
Just adds TIL_FB_DRAW_FLAG_TEXTURABLE so callers can granularly
inhibit texturing if desired.
|
|
This just slows things down, and now that the code is mature
enough to never trigger these asserts just get rid of them.
|
|
short-circuit by directly returning bound when exceeded
|
|
dotgradient() is very hot and needs this result when indexing
din->grid[]. Since it doesn't change for a given din instance,
just cache the result @ din_new().
|
|
Originally it seemed sensible to make these units of bytes, for
flexibility reasons.
But it's advantageous for everything to be able to assume pixels
are always 4-byte/32-bit aligned. Having the stride/pitch be in
bytes of units made it theoretically possible to produce
unaligned rows of pixels, which would break that assumption.
I don't think anything was ever actually producing such things,
and I've added some asserts to the {sdl,drm}_fb.c page
acquisition code to go fatal on such pages.
This change required going through all the modules and get rid of
their uint32_t vs. void* dances and other such 1-byte vs. 4-byte
scaling arithmetic.
Code is simpler now, and probably faster in some cases. And now
allows future work to just assume things cna always occur 4-bytes
at a time without concern for unaligned accesses.
|
|
Originally the thinking was that rototiller modules would become
dlopen()ed shared objects, and that it would make sense to let
them be licensed differently.
At this time only some modules I have written were gplv3, Phil's
modules are all gplv2, and I'm not inclined to pivot towards a
dlopen model.
So this commit drops the license field from til_module_t,
relicenses my v3 code to v2, and adds a gplv2 LICENSE file to the
source root dir. As of now rototiller+libtil and all its modules
are simply gplv2, and anything linking in libtil must use a gplv2
compatible license - the expectation is that you just use gplv2.
|
|
Largely mechanical rename of librototiller -> libtil, but
introducing a til_ prefix to all librototiller (now libtil)
functions and types where a rototiller prefix was absent.
This is just a step towards a more libized librototiller, and til
is just a nicer to type/read prefix than rototiller_.
|
|
This is a first approximation of separating the core modules and
threaded rendering from the cli-centric rototiller program and
its sdl+drm video backends.
Unfortunately this seemed to require switching over to libtool
archives (.la) to permit consolidating the per-lib and
per-module .a files into the librototiller.a and linking just
with librototiller.a to depend on the aggregate of
libs+modules+librototiller-glue in a simple fashion.
If an alternative to .la comes up I will switch over to it,
using libtool really slows down the build process.
Those are implementation/build system details though. What's
important in these changes is establishing something resembling a
librototiller API boundary, enabling creating alternative
frontends which vendor this tree as a submodule and link just to
librototiller.{la,a} for all the modules+threaded rendering of
them, while providing their own fb_ops_t for outputting into, and
their own settings applicators for driving the modules setup.
|
|
- switch puddle_sample() to 0..1 coordinates to avoid
some pointless extra arithmetic on every pixel
- avoid redundant ->w multiplies in puddle_sample()
- avoid multiplies in inner loops of drizzle_render_fragment()
by accumulating coordinates w/addition instead
I noticed full-screen 'compose' was struggling to keep a full
frame rate on my laptop when testing with the new 'plato' layer.
valgrind profiles showed drizzle as the big hog, mostly the
puddle_sample() function. These changes help but it's still not
great, getting much better will likely become invasive and
crufty. It would be nice to cache the vertical lerp results and
reuse them across puddle_sample() calls when valid, that might be
a useful TODO.
The runner-up is spiro, prolly some low-hanging fruit there as
well, I haven't looked yet.
|
|
Added a triangle wave
|
|
This builds minimally upon the existing sine wave code,
just use the sign to drive the signal high or low.
Wikipedia shows a third state for 0 values, but that's for a -1..+1
signal. I'm producing all 0-1 signals as it's more convenient for
this application, but it seems like it would be awkward to return
.5f for the 0 case. So 0 is being treated as just another positive
value; high.
|
|
Provides improved ergonomics when using the bulitin ops, and much
appreciated arity and type checking.
|
|
Added some rudimentary refcounting so sig_t's can be readily shared
by multiple sig_t's.
|
|
Seems broken, fix it correctly later.
|
|
off by one order of magnitude
|
|
map 0-1 inputs to their inverse 1-0
|
|
Rename inv->neg, preparation for a new sig_ops_inv for inverting
0..1 to 1..0
|
|
Included a little hack to defend against divide by zero, seems
reasonable given the intended use cases.
|
|
|
|
This is a specialized version of sig_ops_scale which assumes a
min..max range of -1..+1
nvidia register combiners docs describe this operation as "expand
normal", and they have several variants, but I don't want to go
too crazy here right now. Plain expand it is.
|
|
This assumes the input value is always 0-1, but may be used to produce
values in any signed range, mapped linearly to the input.
|
|
aka negation
|
|
The whole idea was to produce values 0-1, except of course
sig_ops_{mult,const} where one could deliberately get out of
these bounds.
Everything else should stay within 0-1 as it makes everything
much more composable.
|
|
Supply two sig_t *'s: a, b
|
|
Supply three sig_t *'s: value, min, max
|
|
Added a simple test exercising pow and round
|
|
The flexible array of void *'s would just align to a pointer,
which may not be safe for all members of whatever gets shoved in
here.
In an effort to make it more robust, make it an array of a junk
drawer union of types.
|
|
Comment was vestigial from ops_mult.c which ops_lerp.c was derived
from.
|
|
(Ab)uses rand_r by feeding ticks_ms as seedp for pseudo-random
numbers deterministically derived from ticks_ms.
|
