| Age | Commit message (Collapse) | Author |
|---|
|
This module is here to stay
|
|
Blend is a more accurate word for what's being done.
Fading is something you can achieve with the blend mode, if you
use something like "blank" as one of the modules. But when you
have two modules generating content, it's not a fade, it's just a
blend.
It might make sense in the future to support a "fade" which
assumes a solid color for one module rather than having to use
the "blank" builtin which burns memory bandwidth on a blank
frame.
|
|
Just more largely mechanical changes transitioning ad-hoc nested
module handling over to til_module_setup_full().
|
|
|
|
Now you can seed the scene editing with a top-level serialized
scene in "as_arg" form, just like NEWSCENE.
The current scene being edited is shown in serialized form for
convenient copy & paste into an editor for manipulation, between
the []s both to also show what the default seed will be if you
just press enter. When using the copy & paste w/editor approach,
you'd just paste the tweaked form directly into the waiting
prompt before hitting <enter>.
Regardless of what happens at the initial EDITSCENE prompt, the
current implementation always goes through an interactive
visiting of all the settings. Simply pressing enter at those
individual settings will accept their current value from the
serialized seed, or a default if not present in the settings.
|
|
This doesn't need to be a distinct state since it's basically
just a banner for the start of the newscene process which never
recurs, it's not an interactive prompt or dialog of any kind...
|
|
Running something like:
'--module=checkers,size=64,fill_module=shapes,style=circle --defaults --go'
Would show some artifacts in the top portion of the filled cells
at certain phases of the spining shape. This was introduce by
the radcache, and it's caused by the overhanging tiles on the
perimeter and how their being clipped was carrying into the
radcache contents then used for all subsequent renders.
This commit just makes setting radcache.initialized conditional
on the incoming fragment being a full-frame fragment as a quick
fix. See comment for more info on what to do long-term.
|
|
There's potential for some of the per-cpu fill_module_contexts to
go unused for an entire frame. When this occurs, depending on
the fill_module in use, it can lead to their context's state
diverging.
To mitigate this possibility, add a tidying up pass in
checkers_finish_frame() where such straggler contexts are
identified and forced to render once into a cell-sized waste_fb
of off-screen memory.
This ensures all contexts see all frames/ticks that any
participated in, preserving their clone status across the board.
Prior to this you could see jittering in something like
'--module=checkers,fill_module=roto' as the roto contexts
diverged on the r/rr variables when some didn't get in on the
action of some frames.
See large TODO comment for why this approach is used instead of
something less wasteful of cpu time.
If this approach is kept, it might make sense to do the waste
rendering in parallel. Systems with large numbers of cores could
end up with many stragglers, depending on how many cells there
are vs. cpus. I don't have any such systems so it's difficult to
test any efforts in that vein.
|
|
In compositions where roto recurs in the same frame, it's
wasteful to keep rendering the fill_fb contents manifold for the
same tick. They shouldn't be varying anyways...
It'd be different if the fill_module rendered directly to the
output fragment in an overlay manner, but the current
roto implementation doesn't do that. It's just sampling fill_fb
like a tiled texture sampler would.
The performance hit here is easily observed by doing something
like:
--module='checkers,size=4,fill_module=roto\,fill_module\=moire' --video=mem --defaults --go
Before this change, FPS=1 on my i7 X230. After, FPS=~400.
|
|
Switch to til_module_setup_full() for handling the module setup
of the input {a,b}_module settings
|
|
Switch to til_module_setup_full() for handling the module setup
of the individual layer module settings as well as the texture.
Since compose served as the development mule for adding nested
settings, there was a lot of verbose comments that no longer
seemed necessary since much of the dust has settled.
The separate compose_layer_module_setup() and
compose_texture_module_setup() wrappers feel a bit like
copy-pasta too. I'm tempted to stop using these and just open
code the til_module_setup_full() calls, except they get performed
twice due to the split finalize, so it's probably still a net win
as-is.
|
|
Stupid bug in untested/unused exclusions handling
|
|
Switch to til_module_setup_full() for handling the module setup
of the individual tile module settings.
|
|
Missed one!
|
|
Switch to the generic til_module_setup_full() and rely on the
"none" builtin's NULL res_setup on finalize to indicate when no
fill_module is desired.
This gets rid of the need for a separate til_module_t* handle for
the fill_module, since til_setup_t.creator can be used for that,
and the NULL til_setup_t* to indicate no fill_module.
Basically discards some busy work style code, there's more
cleanups needed surrounding this stuff though.
More or less identical to the previous change to modules/checkers.
|
|
Switch to the generic til_module_setup_full() and rely on the
"none" builtin's NULL res_setup on finalize to indicate when no
fill_module is desired.
This gets rid of the need for a separate til_module_t* handle for
the fill_module, since til_setup_t.creator can be used for that,
and the NULL til_setup_t* to indicate no fill_module.
Basically discards some busy work style code, there's more
cleanups needed surrounding this stuff though.
|
|
This was done for rkt_scener already, this commit brings
interactive setup inline WRT :raw_value overrides on multiple
choice settings.
|
|
Basically everywhere the
TIL_MODULE_HERMETIC|TIL_MODULE_EXPERIMENTAL exclusions were being
applied needed TIL_MODULE_BUILTIN added.
Mostly this is to prevent randomizers from tripping over builtins
in the available modules lists they draw from.
Because builtins aren't visually interesting by themselves, and
in some cases don't currently even have a means of being
randomized properly like ref's path setting.
This wasn't needed previously since builtins were kept off the
modules list altogether. But since 1a6210be that changed and
they must be explicitly filtered by flag instead.
Note I deliberately left the rkt case with just a TODO comment.
It's not a randomizer situation, and it might be acceptable to
let rkt just show everything all the time in the module lists.
That whole situation there is for advanced users.
Also note that without this, rtv et al would easily trigger an
assert on NULL setup due to the "none" builtin. Since there's
still work to be done there in callers properly handling NULL
@res_setup on a successful finalize. But this commit mitigates
that by avoiding the builtins in the randomizers.
|
|
Missed this in the last round of moving things to the
new raw_value() setter/getter api
This snippet of copy-n-pasta the few setup front-ends continue to
have should really be factored out into a libtil helper
|
|
This will just quietly exit successfully if "none" is provided as
the root rendering module.
It's not really a case worth bothering with doing something more
about... the user did this pointless thing on purpose. Let's just
not crash.
While here I may have fixed a bug surrounding til_quiesce() not
being called on the teardown path.
|
|
Sometimes nested modules are optional, in those cases I've
usually been using the "none" module name to indicate this and
the ad-hoc setup stuff can easily bypass module setup on that.
This commit is a step towards having a "none" builtin that
provides a til_module_t.setup() which succeeds but only produces
a NULL res_setup when asked to finalize.
So if callers just handle a successful finalize case that writes
NULL at res_setup equivalent to "disabled", this all Just Works.
Currently that's not an expected thing, but future commits will
bring everything else on the same page.
For callers who want to require the module and not offer "none",
they can just put "none" in the explicit exclusions list passed
to til_module_setup_full().
|
|
Also move builtins to a separate listing while at it
For now this results in the builtins showing up in the modules
list alongside the actual rendering modules. Future work must
refine this UX, maybe by adding some metadata to the spec.values
for categorizing/prioritizing what's shown always vs. what's
present but hidden without asking to be shown hidden stuff or
whatever.
Just consolidating some junk and working towards every nested
module setup going through the same machinery, and always being
able to access the builtins.
|
|
This gets rid of the ad-hoc module lookups previously necessary
for finalizing the nested module setups. Now that the
til_estup_t.creator tracks the creating module, the
rkt_scene_module_setup() wrapper can take care of finalizing.
|
|
Particularly with nested modules it's annoying to have to stow
the module separate from the setup during the setup process.
If the baked setup included the module pointer in the
non-module-specific-setup part of the setup, then nested settings
could finalize using the generic module setup wrapper and just
rely on this til_setup_t.creator pointer to contain the
appropriate module. Which should enable tossing out a bunch of
copy-n-pasta surrounding nested modules setup.
Note this has to be a void* since til_setup_t is a generic thing
used equally by both the fb code and the module code. Hence why
this is called "creator" and not "module", as well as the void*
as opposed to til_module_t*.
Also if rototiller ever grows a sound backend, the setup
machinery will be reused there as well, and it'll be yet another
creator handle that isn't an til_fb_ops_t or a til_module_t.
It's assumed that the callers producing these setups won't be
trying to pass them to the wrong places i.e. a module setup
getting passed to an fb backend and vice versa.
I'm mildly annoyed about having to move the various til_module_t
blocks to above the module's foo_setup(), but it seemed like the
least annoying option. This may be revisited.
|
|
Most of the time in scener you want to add a compose, you
basically never want blank, so the :blank thing was kind of silly
from the perspective of what happens most often.
|
|
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.
|
