<commit_before>Oh damn, the root node shouldn't be the world: it should be the screen. That
way you can absolutely position things relative to the screen (by adding them
to the screen node), as well as the world.

No nevermind, just have things that ignore camera by percentages (including
zero).

fr -- faster raster
jenniferseinefr -- seine bindings to fr

Postprocess / after filters should run in this order:

* component
* children

If you want something to run AFTER all children, you can stick it in the before
filter. But if you want something to run in between render / postprocess, if
you don't stay consistent with ordering you're screwed.


Engine should have dependency injection on the looping and running functions.
Provide realtime-tuned defaults if none are specified.


Might want Component containers that call all the methods on components, and
that themselves are components that can be added to a SceneNode or engine. E.g.
if you have a series of powerups, you might want those to just be in a single
controller component, and have that component call different components
depending on its state.

NO: unnecessary. Just have an interface that owns a component. The exported
component provides the hooks; the main object controls the state. Components
are hooks.


Rather than having the runner know about SceneNodes, the engine, etc, the
runner should just know about components. Additionally, there is a walker
function that collects all the components from the given tree.

Hmmm, dunno. Does that mean components can't take x, y, z coordinates as args
to their update methods? Once you've lost the tree structure you lose the
coords, or have to store them which makes for garbage.


Move geometry, rendering out to an abstracted non-scene-graph-based library.
Just a simple thing that can set up a canvas context, draw a bitmap, draw
shapes for rendering. For geometry, simple thing that can check collisions
between points, rects, circles. Maybe even a pure-functional collision
resolution library?

Once you have the functional geometry and rendering lib, build your components
on top of that.


All updates to position in physics module should be *async*. Not for some
imagined speed boost: for simplification. The state of the world should never
change: you just figure out what the next state should be.

Could be done by overriding a filter in a component. Also async doesn't mean
callbacks necessarily: you could just push things that need to get removed into
a buffer, and then remove them all at once in the filter.

On second or third thought, this is sort of silly. Really there should just be
one interface/object that controls all of physics and does a single update
step, with exportable physics components that get added to the engine and the
game components.


Cool idea: decorators. Two ways to do it:

1. Decorator class that can instantiate components. You pass Component objects
   to it.
2. Decorator class, instantiates components -- but instead of passing Component
   objects to it, you make the Component class have a `decorate` method, and
   you can pass decorators into it.<commit_msg>Physics notes.<commit_after>Oh damn, the root node shouldn't be the world: it should be the screen. That
way you can absolutely position things relative to the screen (by adding them
to the screen node), as well as the world.

No nevermind, just have things that ignore camera by percentages (including
zero).

fr -- faster raster
jenniferseinefr -- seine bindings to fr

Postprocess / after filters should run in this order:

* component
* children

If you want something to run AFTER all children, you can stick it in the before
filter. But if you want something to run in between render / postprocess, if
you don't stay consistent with ordering you're screwed.


Engine should have dependency injection on the looping and running functions.
Provide realtime-tuned defaults if none are specified.


Might want Component containers that call all the methods on components, and
that themselves are components that can be added to a SceneNode or engine. E.g.
if you have a series of powerups, you might want those to just be in a single
controller component, and have that component call different components
depending on its state.

NO: unnecessary. Just have an interface that owns a component. The exported
component provides the hooks; the main object controls the state. Components
are hooks.


Rather than having the runner know about SceneNodes, the engine, etc, the
runner should just know about components. Additionally, there is a walker
function that collects all the components from the given tree.

Hmmm, dunno. Does that mean components can't take x, y, z coordinates as args
to their update methods? Once you've lost the tree structure you lose the
coords, or have to store them which makes for garbage.


Move geometry, rendering out to an abstracted non-scene-graph-based library.
Just a simple thing that can set up a canvas context, draw a bitmap, draw
shapes for rendering. For geometry, simple thing that can check collisions
between points, rects, circles. Maybe even a pure-functional collision
resolution library?

Once you have the functional geometry and rendering lib, build your components
on top of that.


All updates to position in physics module should be *async*. Not for some
imagined speed boost: for simplification. The state of the world should never
change: you just figure out what the next state should be.

Could be done by overriding a filter in a component. Also async doesn't mean
callbacks necessarily: you could just push things that need to get removed into
a buffer, and then remove them all at once in the filter.

On second or third thought, this is sort of silly. Really there should just be
one interface/object that controls all of physics and does a single update
step, with exportable physics components that get added to the engine and the
game components.


Cool idea: decorators. Two ways to do it:

1. Decorator class that can instantiate components. You pass Component objects
   to it.
2. Decorator class, instantiates components -- but instead of passing Component
   objects to it, you make the Component class have a `decorate` method, and
   you can pass decorators into it.


Collision, physics engine should separate hitboxes from location. The (x,y) of
a hitbox is the offset from the node's location, not the absolute location
itself. Collision runs on computed properties. Physics component needs to take
two data structures: a location (x, y), and a hitbox (x, y, width, height).
{'fraction_non_alphanumeric': 0.03628909808685089, 'fraction_numerical': 0.0006073489219556636, 'mean_word_length': 4.320678513731825, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6751302', 'n_tokens_mistral': 1600, 'n_tokens_neox': 1536, 'n_words': 1053}