| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
