Open jonathanhogg opened 5 months ago
Ways that engine
is currently used by renderers:
physics
uses .target_fps
and .state
controller.driver
uses .state
and .counter
, plus calls .has_next_page()
, .next_page()
, .has_previous_page()
and .previous_page()
controller.push2
uses .counter
window
uses .state
and calls .next_page()
and .previous_page()
Engine's .state
is in the Context
already and .target_fps
is in the names dictionary. Adding the counter into the context sounds reasonable. The page stuff probably needs abstracting into a better concept of actions (or events?) that would make it easier for controllers to trigger things.
There is probably also an argument for having BeatCounter
become part of flitter.model
.
Following on from an idea in #38 of putting references into
Context
so that@context_func
s can access them, what if theContext
was also passed into renderers instead of the current mish-mash of engine, node, references and global names?Other than possibly just being neater, another key advantage of doing this would be allowing renderers to update the
warnings
anderrors
sets. At the moment, there's no good way for renderers to log problems that wouldn't spam the console on each frame, so they tend to just eat errors and forget about them.