| Age | Commit message (Collapse) | Author |
|---|
|
rkt_setup() and rkt_scener_update() had distinct implementations
for scene module setup. This consolidates that where trivial to
both use the new til_module_setup_full() with appropriate
parameters, wrapped up in rkt_scene_module_setup().
The finalizing phase is still ad-hoc which is mildly annoying,
but if finalizing just passed into rkt_scene_module_setup() there
wouldn't be the til_module_t onhand for sticking in rkt_scene_t.
So the code to extract and lookup the module from the settings
would still be needed anyways, as the whole til setup_func api
isn't limited to modules so the baked til_setup_t doesn't come
back with a til_module_t hanging in there. Maybe in the future
this gets changed a bit, there could for instance be a void* in
til_setup_t where something usage-specific goes, like the
relevant module in the case of a module's setup. Something to
consider for the future.
Consolidating these in the pre-finalize phase at least ensures
consistent behavior in initial rkt::scenes setup vs. scener
editing/new scenes.
|
|
When creating nested setting instances, just pass down the full
raw value so if there's any prefix on the value it can be
realized as a prefix for the first entry in the nested instance.
|
|
The application of overrides was still done via ad-hoc value
manipulation. This changes to use til_setting_set_raw_value() in
the obvious manner.
|
|
Trivial refactor s/til_setting_spec_check/til_setting_check_spec/
so it operates on a til_setting_t as opposed to the bare value.
With the containing til_setting_t onhand it can be responsible
for bypassing the check when til_setting_t.nocheck is set.
Adjusted callers in setup_interactively() and rkt_scener_update()
accordingly.
|
|
It's relatively acceptable to use this hammer for the other
errors like ENOMEM especially when this isn't some enterprise-y
service that must endure overload conditions gracefully.
But the setup_finalize() step is rather likely to find invalid
settings, especially now that til_setting_t.nocheck with the ':'
prefix is a thing.
This commit doesn't try resume the setup at the invalid setting
(yet, that will require further til_module_t.setup() method
work), but it at least doesn't rudely disconnect. The user just
gets dumped back to the SCENES state main prompt.
|
|
The existing code assumed til_module_t.name was equivalent to the
name setting's value. That's no longer a safe assumption, and if
the module was made possible via something like nocheck, that
needs to be preserved in the randomized setup.
So this gets the name out of the setting instead, using the new
raw value getter.
|
|
This makes RKT_SCENER_FSM_SEND_NEWSCENE_SETUP* handle ':'
prefixed values correctly, now using the new
til_setting_[sg]et_raw_value() API instead of directly messing
with til_setting_t.value.
It should now be possible to specify anything as a value
regardless of what's in the list for multiple choice settings.
Which does create opportunity for serious breakages... there will
definitely be crashes if you do silly things. Some
til_module_t.setup() methods have historically assumed the
spec_check would police the values reaching them. Those will
have to be made more robust now that this is getting wired up.
|
|
Now whenever a setting value/preferred input is derived from a
setting, it'll want to get the raw value to preserve any prefix.
|
|
The filter bypass was kind of a hack and resulted in unfiltered
module lists in rkt_scener edits.
Now that there's an explicit syntax for bypassing checks, the
user can just do that to access what's filtered. So get back to
appropriately consistent filtered results.
|
|
Since blank is a builtin, at least for now it requires explicit
override since the builtins aren't added to the modules values
list and filtering is going to be always applied shortly.
|
|
This adds a setting value syntax for bypassing checks; ':' prefix
e.g.
--module=:experimental_module
Would result in the value experimental_module added, and no
verification performed of its presence in the module setting's
values list.
Two new til_settings api functions are introduced as well for
setting and getting the raw values including any prefix syntax:
til_setting_get_raw_value()
til_setting_set_raw_value()
these are needed because the til_setting_t.value member will
continue to point at the "cooked" form of the value with the
prefix stripped out, so the general cases of needing the value
won't have to worry about the presence of prefixes. They have
the til_setting_t.nocheck member to see if the setting was a
nocheck-prefixed value.
The nocheck prefix is preserved across serialization as well. So
using a serialized form to seed a derivative settings instance
won't spuriously start failing checks because the ':' prefixes
are gone where they were necessary. They'll be kept wherever
they were previously.
There will probably be some more random fixes needed here and
there where code is directly manipulating til_setting_t.value and
must now go through the "raw" getter/setter api.
|
|
The "tiller" base (base being a Rocket concept) was always a bit
spurious. Maybe "til" would make more sense, but "rkt" is more
contextually specific.
I think when I originally picked "tiller" I was prioritizing
picking something unlikely to collide with another directory
name. But the way Rocket is naming the directory in the
filesystem it gets suffixed with an _ anyways.
|
|
The "compose,compose,compose,compose" default was never intended
to be permanent, but gave a set of scenes to test the Rocket
integrations like scene selection and scene-specific tracks
without any additional effort.
Now that there's scener for easily adding/editing scenes, and
things are just generally more mature, I think it makes sense to
just go back to something minimal here.
I'd really rather just have it be "", but that's not handled well
presently. There isn't really a way to start with an empty
scenes set for rkt. Which is awkward, but "blank" is close.
It'd just be nice to start with an altogether blank slate rather
than having to always edit the default first scene when starting
anew...
|
|
Now that the "scener" interface seems to be semi usable and
capable of editing... things are looking more complete in the
sense that there's no huge gaping holes and a lot of the dust has
settled.
It's also looking pretty good for this sticking around long-term,
so I'm removing the experimental flag making this more
discoverable and visible in general.
There's still work to be done surrounding GNU Rocket the library,
like getting it using non-blocking connects, and there's a need
for forgetting tracks which the protocol doesn't support
currently. But it'd be silly to wait on getting those things
upstream before making rkt more visible.
|
|
Playing with libs/sig in 2D, this isn't really an interesting
module by itself in terms of visual output. But it might have
utility as a diagnostic thing if libs/sig becomes a more used
thing.
At the very least, for now, it's useful for observing affects of
and iterating on libs/sig development. So I'm merging this, just
gated behind TIL_MODULE_EXPERIMENTAL so it's not in rtv rotation
or presented as something in the usual modules list.
|
|
This augments the NEWSCENE_SETUP state to also handle editing
existing settings, which is slightly different but actually
overlaps with the already implemented invalid input stuff.
There's still work to do, and the UX is kind of awkward at best.
But this takes us from having no ability to edit existing scenes,
to being able to actually make edits interactively while it's all
live... with a modicum of interactive guidance via the setup
machinery.
It basically behaves just like creating a new scene, except
instead of the <enter>-accepted "preferred" values, you accept
the existing relevant setting. So as-is, when editing, you have
no shortcut for getting back the "preferred" value for a given
setting. That's been replaced with the existing value for that
setting.
You also get seemingly spurious redundant queries for module
names in things like compose::layers, but they're really not the
same since the first time you get asked it's actually the full
settings string you're getting an opportunity to specify
wholesale, but can accept to seed the layer's settings as-is,
which you will then be given an opportunity to edit piecemeal.
It's that subsequent piecemeal editing of the individual settings
within the nested instance that can feel like a spurious
duplication, especialy when a given layer has just a bare-value
module name and no subsequent settings.. like "plasma". You'd be
asked if you want "plasma" for the layers/[N], then asked if you
want "plasma" _again_ for the layers/[N]/[0] since the module
name is an unnamed setting at position 0 within the layers/[N]
instance.
It was tempting to try streamline that a bit, but there's
actually utility in having an opportunity to paste in a full
settings string for the layers/[N] if you have a serialized scene
onhand you want to dump in there. Then after that, you can juts
smash enter as much as necessary to accept what you pasted in
without editing those in the piecemeal phase. Or, if there was
actually something in what you pasted you did want to change,
change it during that piecemeal phase.
I think it at least kind of works.
|
|
There's an outstanding issue surrounding the need for context
clones, and I'd just like to write something down somewhere
before it falls off my radar. Presently it's just checkers that
exercises this need, so it makes sense to put it here for now,
until I get around to actually taking action on the issue.
|
|
Mechanical change switching til_fragmenter_slice_per_cpu() users
over to til_fragmenter_slice_per_cpu_x16(), except sparkler where
it's quite detrimental to performance.
|
|
This restores the original til_fragmenter_slice_per_cpu() while
adding an explicit x16 variant for what
til_fragmenter_slice_per_cpu() had become.
The impetus for this is realizing the x16 multiplier is terrible
for sparkler's crappy threading, and it really need strictly
n_cpus slices for the threading to be beneficial.
So I'm just getting rid of the hidden x16 in favor of making it
explicit in an _x16 variant.
Subsequent commit will pivot all the non-sparkler callers to
til_fragmenter_slice_per_cpu_x16().
|
|
Better spearate the generic error line from surrounding text with
an extra newline
|
|
This was a bit of an aspirational misnomer, editing scenes isn't
actually implemented yet. What the EDITSCENE state currently
implements is the per-scene dialog+prompt, which originally was
going to just be the scene editing flow but became more of a
"view a specified scene's details" with a prompt of its own.
Nothing functionally changes, just mechanical internal renames.
|
|
Preparatory commit for rkt_scener scenes editing, which will be
replacing the current scene's settings instance with a newly
constructed one. This enables simply duplicating the existing
scene setting's positional label, which will be identical in the
replacement.
|
|
Most of the time if there are undescribed settings in the
settings hierarchy, they're just noise in the serialized as_arg
form.
So change til_settings_as_arg() to always skip undsecribed
entries, and introduce til_settings_as_arg_unfiltered() for any
use cases that actually want everything included. The unfiltered
variant may just go the way of the dodo if nothing ever makes use
of it.
|
|
Since "ref" renders using arbitrary foreign contexts, it must
explicitly limit their rendering concurrency to its own.
|
|
With the introduction of discoverable on-stream contexts, with
the intention of modules finding them at runtime for nested
rendering, relying exclusively on limiting n_cpus @
til_module_create_context() is no longer adequate.
When the nested rendering makes use of a context created
elsewhere, it can't make any assumptions about what its n_cpus
is, nor should it be attempting to change that value for its use.
So this variant just adds a max_cpus parameter for setting an
upper bound to whatever is found in the context's n_cpus.
The impetus for this is to fix the ref builtin, which you can
currently trick into deadlock by performing a nested threaded
render within a threaded render. What the ref module should be
doing is propagating its own context's n_cpus down as the upper
bound, via this new render variant.
|
|
This is leftover from development when it used a fmt string in
combination with the key, before the desc path was getting
properly appended.
|
|
With the addition of the "radcache" in b6362c, the need for a
faster approximate atan2f() is largely eliminated.
And there seems to be a bug in the implementation as-is taken
from https://mazzo.li/posts/vectorized-atan2.html
You can see the bug as vertical line artifact around the center
where the X coordinate would be 0. Rather than debug what's
wrong with this approximation's implementation surrounding its
quadrant adjustments, let's just resume using atan2f() and let
the cache keep things quick.
|
|
When introducing the **fragment_ptr model in 5a0776f, the
rototiller_thread() introduced a local place to put the pointer
to point at when rendering.
But this pointer then ends up outliving the thread on shutdown
within any queued frames until quiescent. Fixed in the obvious
way by sticking it in rototiller_t instead.
|
|
On Linux I don't notice a significant affect on anything letting
rkt try connect every frame when offline but in creative mode.
On Windows however, Dan reported significant latencies in the
Scener prompt responsiveness and visible slowdowns in this
condition.
I suspect the WIN32 Rocket library's sync_tcp_connect() code is
the real problem here. But for now I can ameliorate things a bit
by just hammering on that code path less when unconnected.
|
|
This is only relevant to creative mode. Stops RocketEditor from
continuing playback endlessly until user intervention beyond the
current end of the demo.
|
|
Prepartory commit for pausing playback upon entering 99999 scene
It needs to trigger only on the edge of entering the scene to
permit RocketEditor to unpause playback even if still in scene
99999, if that's what the user is trying to do. It'd be annoying
to have it just keep asserting a paused state until the scene idx
leaves 99999...
But this also enables triggering anything on scene change edges,
for future stuff.
|
|
- strip off the leading /path/to/rkt/module prefix
- separate taps from their scene context path with ':' vs. '/'
RocketEditor doesn't currently support recursive grouping, so
this is as good as it gets.
Note this commit will break the existing tracks for alphazed, so
you'll have to use a newer .zip for track data if building your
rototiller from source. Or build from a prior commit.
|
|
Preparatory commit for rewriting track paths a bit to better
group things in RocketEditor. I'll need access to
rkt_context_t.til_module_context_t.setup->path for prefix
matching purposes..
|
|
This makes it possible to tiled+rotate the output of another
module in the same manner checkers::fill_module fills cells with
module output.
The default stays "none" for the classic roto with the
psychedelic color cycling. When !"none" the color cycling
doesn't get applied currently. It might be interesting to try
support that in the future though.
|
|
During rkt_scener development this append was at one time needed,
as there was no retained reference to the scenes_settings for
deriving paths from.
Now that the path is derived from the actual scenes setting
instance it's just resulting in a double trailing /scenes in the
"/module/rkt/scenes/scenes:" heading
Purely cosmetic fix
|
|
For meta-demo use cases like alphazed is experimenting with, it's
desirable to change the window title from "rototiller" to
"alphazed" or whatever if in windowed mode.
This adds a way to do that in the obvious fashion...
--title="alphazed" etc.
|
|
|
|
The tap->ptr indirection must always be updated even when we're
the driver on a fresh pipe created by us.
This bug only triggers when the caller's tap was already
on-stream, without being the driver, and the driving tap/context
has since exited the stream, untapping itself which removed the
associated pipes - even the ones it didn't own but was driving.
In that scenario when pipe is created by the previously
non-driving tap on its first update since the driver exited, its
tap->ptr still points at the stale driver. This manifested as a
UAF bug in that case.
The fix is a simple matter of always updating tap->ptr to reflect
the driving tap.
This also fixes the real bug causing 468c78e3 to crash, such that
the syncronous gc performed there shouldn't really be necessary
to prevent crashing. It was the awkward overlapping existence of
contexts at the same path which produced the triggering lifecycle
pattern WRT driving taps at that path.
|
|
Pressing '=' at either prompts now makes scener's current scene
the current Rocket scene.
While you could already do this manually by just looking at the
scenes list for the one with the '*' in the Rocket column while
either watching a production and pressing <enter> repeatedly to
keep refreshing the scenes list... that's cumbersome and
annoying, now just use this shortcut.
Since this just copies Rocket's scene to the Scener scene index,
it needed to properly handle scene 99999... hence the previous
commits.
|
|
While there's no actual context for 99999, it's a state we need
to represent visibly somehow.. so just make it appear like an
epilogue scene off the end.
I've included the Rocket/Scener/Pinned status columns
consistently as well so you at least still get a visible
indication when you've done something like pinned 99999 somehow
(not that this is possible presently, but with future changes
there will be more ways to copy the Rocket idx into Scener's idx)
|
|
rkt_scener needs to know this value so define it in rkt.h and
switch over all the existing 99999 instances.
|
|
Until channel context paths are distinct it's buggy to let the
contexts linger while constructing the next channel's contexts.
Originally when the gc was added here the intention was to
support stuff like the "ref" module and get the channels settings
wired up immediately with more focus on rtv's details in this
area. Supporting stuff like contexts backing some layers
persisting across channels, while the others were swapped out,
seemed potentially interesting (and it still is).
But the rkt stuff became prioritized as rtv is more like a fuzzer
than anything despite being the default module. And rkt related
activities will continue for now, so let's just get rtv less
likely to crash.
A reliable repro for triggering an ASAN UAF bug without this
commit is:
--seed=0x64af3b05
'--module=rtv,duration=1,context_duration=1,channels=compose,caption_duration=2,snow_duration=0,snow_module=none,log_channels=on'
'--video=sdl,fullscreen=off,size=640x480'
A few channels in blinds will UAF while updating taps stored in a
freed context, because the previous channel has a blinds in the
same layer as the newly setup channel, putting the contexts at
exactly the same paths on-stream. There's probably another bug
in here that I need to dig into, but coexisting contexts at the
same path on-stream was never the intention. The syncronous
immediate gc ensures nothing remains of the previous channel
before constructing the new one at the same path.
|
|
The channel module name was being used as the settings instance
name, which is redundant to the entries[0] "value as label"
behavior with the module name also @ entries[0].
The resulting paths resembled:
/module/rtv/compose/compose/layers/[N]/...
/module/rtv/compose/compose/texture/...
Now they are:
/module/rtv/channel/compose/layers/[N]/...
/module/rtv/channel/compose/texture/...
There's still work to be done in this area of rtv. It's unclear
if even a static "/module/rtv/channel" is correct, or if it
should show the subscript of the channels[] entry currently being
used when that becomes a proper nested settings situation, i.e.
/module/rtv/channels/[0]/compose/layers/[N]/...
...
/module/rtv/channels/[1]/spiro
...
/module/rtv/channels/[2]/roto
...
for a "channels=compose,spiro,roto" kind of hypothetical
another option which might make sense is to have the channel path
more like an auto-increment identifier so the channel contexts
have unique paths and don't collide on the stream. This could be
important for scenarios utilizing the "ref" module and trying to
reuse parts of the context from one channel to the next. When
the paths collide things tend to break in weird ways presently.
this area needs more thought
|
|
Due to how meta-modules reference other modules from within their
context, they pin the related refcounts until their gc is
performed.
So repeat the gc passess until nothing gets freed, to gc those
recursive references immediately.
Fortunately this isn't intended to be done at perf-sensitive
times...
|
|
til_stream_register_module_contexts() reuses the container when
c->n_contexts is sufficiently large, and deliberately leaves
c->n_contexts as-is to potentially accomodate a larger set in the
future. The excess was NULLified in prepping for reuse so it
should be fine, just add a blurb about it so it doesn't look like
an oversight.
|
|
Silly and unnecessarily racy to do this in render_fragment now
that blinds is threaded
|
|
This is a first stab at threading blinds, while here I got rid of
the reliance on _checked() put_pixel for clipping.
This could be better, things like using a block put/copy instead
of put_pixel would be a huge advantage for blinds due to its
naturally contiguous blocks per-blind.
While this module when non-threaded wasn't especially slow, any
module leaving cores idle is depriving other potentially threaded
modules of utilizing them for the duration of the non-threaded
render. So now that rototiller is being used for compositions
and increasingly becoming something of a meta-demo, it's become
important to make everything as threaded as possible.
|
|
Especially since taps are established on first use, it's
desirable to get them online immediately so they show in things
like --print-pipes and modules::rkt/RocketEditor and not
spuriously once the context becomes actively rendered...
This kind of thing will be done for all modules eventually
|
|
computing the angle for every pixel coordinate from the origin is
costly, even with the approximate method added by c690303.
An easy speedup is to only do this once for a given frame
dimensions, and cache those results. In the form of a 32-bit
float, it's equivalent to caching a full page of pixel data.
This is slightly complicated by needing to be an effectively
global cache and the potential for multiple shapes contexts
rendering concurrently when part of a composition.
I think this particular situation highlights a need for something
equivalent generalized on-stream where modules can register
discoverable caches of costly to compute information, having a
high probability of being useful to others.
In this particular case it was alphazed's use of shapes in two
layers that made it an obvious win, even without any other
modules needing atan2() per-pixel with a centered origin.
With this commit:
Configured settings as flags:
--seed=0x64adabae '--module=compose,layers=blank\,shapes\\\,type\\\=pinwheel\\\,scale\\\=.9\\\,pinch\\\=.25\\\,pinch_spin\\\=.1\\\,pinches\\\=7\\\,points\\\=19\\\,spin\\\=.01\,shapes\\\,type\\\=pinwheel\\\,scale\\\=.9\\\,pinch\\\=1\\\,pinch_spin\\\=-.25\\\,pinches\\\=8\\\,points\\\=5\\\,spin\\\=0,texture=moire\,centers\=3' '--video=mem,size=1366x768'
FPS: 73
FPS: 74
FPS: 73
Without:
Configured settings as flags:
--seed=0x64adb857 '--module=compose,layers=blank\,shapes\\\,type\\\=pinwheel\\\,scale\\\=.9\\\,pinch\\\=.25\\\,pinch_spin\\\=.1\\\,pinches\\\=7\\\,points\\\=19\\\,spin\\\=.01\,shapes\\\,type\\\=pinwheel\\\,scale\\\=.9\\\,pinch\\\=1\\\,pinch_spin\\\=-.25\\\,pinches\\\=8\\\,points\\\=5\\\,spin\\\=0,texture=moire\,centers\=3' '--video=mem,size=1366x768'
FPS: 55
FPS: 54
FPS: 54
So it's significant, and in alphazed there's also a transition
from one scene with two full-screen shapes layers into a
checkered scene with shapes as the fill_module. Further
amplifying the payoff.. infact whenever shapes is used for a
fill_module in checkers, there's n_cpus shapes contexts created
because checkers is threaded. All of those would be benefitting
from the cache.
|
|
What this really should have is a general memset32()
implementation, but for now it's a small improvement at least for
clearing since that's known to be a 0-pixel case where memset()
is applicable.
memset() isn't usable for actual RGBA pixels since it operates
strictly on bytes. There's some hacks for using memmove() to get
closer where you store the first four bytes, then memove the
start of the buffer to the remaining, doubling the size of the
move each time for log(n) calls to memmove. Maybe that makes
sense as a stop-gap for the general case, it needs
implementing+benchmarking first.
This commit is dead simple though and an obvious little FPS gain
for clearing.
|
