| Age | Commit message (Collapse) | Author |
|---|
|
This is an early implementation of something resembling an audio
backend for rototiller/libtil.
The assumption for now is that everything will use signed 16-bit
native-endian stereo output @ 44.1khz.
|
|
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.
|
|
Some rudimentary instrumentation for monitoring the active module
contexts alongside the pipes
You probably want to redirect stderr to a file when using
--print-pipes and/or --print-module-contexts...
e.g.
```
rototiller --defaults --go --print-pipes --print-module-contexts 2>/dev/null
```
or, if you still want to monitor FPS or log_channels=on in rtv,
2>/file/to/tail then tail -F /file/to/tail in another terminal.
|
|
This is a rudimentary integration of the new til_stream_t into
rototiller. If the stream is going to continue living in
til_fb_fragment_t, the fragmenters and other nested frame
scenarios likely need to be updated to copy the stream through to
make the pipes available to the nested renders.
--print-pipes dumps the values found at the pipes' driver taps
to stdout on every frame.
Right now there's no way to externally write these values, but
with --print-pipes you can already see where things are going and
it's a nice visibility tool for tapped variables in modules.
Only stars and plato tap variables presently, but that will
improve.
|
|
This enables reproducible yet pseudo-randomized visuals, at least
for the fully procedural modules.
The modules that are more simulation-y like sparkler and swarm
will still have runtime variations since they are dependent on
how much the simulation can run and there's been a lot of
sloppiness surrounding delta-t correctness and such.
But still, in a general sense, you'll find more or less similar
results even when doing randomized things like
module=rtv,channels=compose using the same seed value.
For the moment it only accepts a hexadecimal value, the leading
0x is optional.
e.g. these are all valid:
--seed=0xdeadbeef
--seed=0xdEAdBeFf
--seed=0x (produces 0)
--seed=0xff
--seed=deadbeef
--seed=ff
--seed= (produces 0)
--seed=0 (produces 0)
when you exceed the natural word size of an unsigned int on your
host architecture, an overflow error will be returned.
there are remaining issues to be fixed surrounding PRNG
reproducibility, in that things like til_module_randomize_setup()
doesn't currently accept a seed value. However it doesn't even
use rand_r() currently, but when it invokes desc->random() the
module's random() implementation should be able to use rand_r()
and needs to be fed the seed. So that all still needs wiring up
to propagate the root seed down everywhere it may be relevant.
|
|
Forgot to add this when adding --go
|
|
In rototiller this disables the automatic displaying of settings
actually used when they differ from what was explicitly specified
as args. Which also disables the waiting to press a key.
This should also get used by glimmer to automatically start
rendering without just putting up the configured settings panel
and waiting for a click on "go!".
|
|
I don't think rototiller is an appropriate place for being so
uncooperative, if someone gets the case wrong anywhere just make
it work. We should avoid making different things so subtly
different that case alone is the distinction anyways, so I don't
see this creating any future namespace collision problems.
|
|
When integrating libtil into higher order application/gui
toolkits, it's desirable to passthru any unhandled arguments to
the toolkit's initializer.
The specific impetus for adding this is glimmer, which uses
gtk/glib where g_application_run() wants an argv but won't know
what to do with the libtil-recognized args.
|
|
This is totally opt-in for libtil callers, but is a step
towards enabling uniform cli invocations across frontends.
The help side of this is particularly janky, but since what's
appropriate there is directly related to the args parsing it
seems appropriate to bring along. The janky part is the
implicit output formatting assumptions being made, as-is it
doesn't really lend itself well to being augmented into broader
frontend help output. Alas, this is rototiller playground, so
let's just go easy and assume frontends will largely spit out
whatever this provides - or completely replace it if appropriate.
|
