jskitty / rusty-sandbox

A lightweight sandbox sim written in Rust.

🌿 INFJ-T

A British developer dedicated to full-time FOSS work in critical cryptographic applications, privacy tech, games, engines and other fun tech bits.

PGP Block

---

Portfolio

⛓ Blockchain & Cryptocurrency ⛓

My PIVX Wallet (JS) - Secure, private & non-custodial wallet for PIVX. - Web Client
Node Bitcoin Miner (JS) - Functional, hackable & educational multi-threaded Bitcoin miner.
Bitcoin RPC (JS) - A reliable, dependency-free Bitcoin RPC interface. - NPM
Checkpoint-rs (RS) - A simple Bitcoin-based blockchain checkpointing program.
ZENZO Forge (JS) - A high-perf parallelised L2 designed for on-chain games.
Concord (JS) - A blockchain implementation inspired by Naivecoin.

---

🎮 Games & Game Engines 🎮

Rusty Sandbox (Rust) - A lightweight & customisable 2D Sandbox Engine. - Play
Voxel Engine (JS) - A modular 3D Voxel Engine with fluids and world-gen. - Play

---

✨ Miscellaneous ✨

Wallpape.rs (Rust) - A simple, tiny GUI Wallpaper manager for Linux DEs.

rusty-sandbox's Issues

Occasional crashes when resizing window

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). 💤

Engine loop scales worse than expected

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:

• 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.