summaryrefslogtreecommitdiff
path: root/src/til_args.h
AgeCommit message (Collapse)Author
2023-07-13til_args,*_fb: introduce --title= and wire up to til_fb_tVito Caputo
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.
2023-06-12til_args: introduce --print-module-contextsVito Caputo
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.
2023-01-11main,til_args: employ the stream, add --print-pipesVito Caputo
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.
2022-07-18til_args: add --seed= explicit PRNG seeding supportVito Caputo
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.
2022-05-25til: add --go to supported argsVito Caputo
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!".
2022-03-14til_args: introduce til_args_pruned_parse() variantVito Caputo
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.
2021-10-03args: move argument parsing/help output to libtilVito Caputo
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.
© All Rights Reserved