summaryrefslogtreecommitdiff
path: root/src/til_module_context.h
AgeCommit message (Collapse)Author
2023-01-10*: introduce paths for module contextsVito Caputo
There needs to be a way to address module context instances by name externally, in a manner complementary to settings and taps. This commit adds a string-based path to til_module_context_t, and modifies til_module_create_context() to accept a parent path which is then concatenated with the name of the module to produce the module instance's new path. The name separator used in the paths is '/' just like filesystem paths, but these paths have no relationship to filesystems or files. The root module context creation in rototiller's main simply passes "" as the parent path, resulting in a "/" root as one would expect. There are some obvious complications introduced here however: - checkers in particular creates a context per cpu, simply using the same seed and setup to try make the contexts identical at the same ticks value. With this commit I'm simply passing the incoming path as the parent for creating those contexts, but it's unclear to me if that will work OK. With an eye towards taps deriving their parent path from the context path, I guess these taps would all get the same parent and hash to the same value despite being duplicated. Maybe it Just Works, but one thing is clear - there won't be any way to address the per-cpu taps as-is. Maybe that's desirable though, there's probably not much use in trying to control the taps at the CPU granularity. - when the recursive settings stuff lands, it should bring along the ability to explicitly name settings blocks. Those names should override the module name in constructing the path. I've noted as such in the code. - these paths probably need to be hashed @ initialization time so there needs to be a hash function added to til, and a hash value accompanying the name in the module context. It'd be dumb to keep recomputing the hash when these paths get used for hash table lookups multiple times per frame... there's probably more I'm forgetting right now, but this seems like a good first step. fixup root path
2022-06-10til: add ticks to til_module_context_tVito Caputo
Also wire this up to the til_module_context_new() helper and all its callers. This is in preparation for modules doing more correct delta-T derived animation.
2022-05-29til: introduce til_module_context_tVito Caputo
Preparatory commit for embedding a til type in the module contexts, similar to til_setup_t for the module setups. This will provide a convenient way to embed seed and n_cpus in every module context, without having to implement that yourself. But it also makes it so modules with no need for a context can continue not implementing those methods, without obstructing libtil from transparently doing it anyways with a bare til_module_context_t. This is kind of important as the current architecture made it difficult to do things like create contexts with explicit n_cpus, like in composite/meta modules which are already threaded and wish to run embedded modules with n_cpus=1. With this addition, n_cpus could be specified at context create time, and it will always become remembered in the til_module_context_t regardless of what the module implements. That way it can definitely be carried into the prepare/render methods, with no opportunity for disconnect between what was passed to context create and what goes to the render methods. Nothing is functionally changed in this commit alone, subsequent commits will actually make use of it and realize what I've said above.
© All Rights Reserved