The engine loop (consisting of both Physics and Rendering) is a fair bit slower than I'd expect with the hardware it runs on, often fully maxing out a CPU core with a decent simulation; I suspect there's a lot of optimisations that could be done to help with this, such as better re-sim protection (perhaps only track 'changed state' particles rather than ALL rendered particles?).

We could also potentially implement a system to 'deactivate' buried particles, since if a particle is surrounded below (y + 1) or either side (x +/-) then it cannot possibly move, yet is still included within full physics computation.

And lastly, which is most effective but highly challenging; we could potentially think about multi-threading the engine, but due to it's high reliance on a singular state (how would we be able to simulate two particles at once on two separate threads without a 'desync' in physics determinism?) this may be fairly hard to do.

Live Task List:

• [x] Optimise the re-sim protection by only tracking particle state changes.
• [ ] 'Deactivate' still particles (i.e; unable to move) from the physics loop.
• [ ] Introduce multi-threading in some form.

The sandbox is intended to scale 'on-demand' to how the user shapes their window: adding X/Y coords when the screen exceeds the world space, however, when particles sometimes spill into 'newly-generated' screen space, there can be out-of-bounds panics.

Likely an issue with the on-demand screen space generation, and likely very easy to fix. (when I'm not dead sleepy). :zzz: