todo.txt

(Code base-wide todos only, smaller stuff should go into the relevant .ts file.)

BIG REFACTORS / DEBT:
[ ] redo RenderableConstruct as struct
[ ] Mesh/RawMesh and asset data
  Right now Mesh/RawMesh/GameMesh is a very strange split and definitely doesn't
  capture well what different data different assets have/need.
  [ ] compute{Grass,Ocean,Std}VertsData has a lot of duplication

[x] System ordering and phases
  Now that we have dependencies DAG we need to make sure our physics, networking, rendering, gameplay stuff happens in the right order.
[-] Multi-game seperation
  Right now we have a bunch of duplicate "ship", "player", "enemy", "cannon" code thats different for the different games. This should be unified or seperated out more cleanly. Long term of course engine and game need to be more seperate.
    [ ] unify ships and sails to all use uv pos and dir
[ ] EM seperation
  right now EM is sort of a dumping ground for all global registration and book keeping, this can probably be seperate into multiple different registrers
[ ] components-as-columns & cache perf
  Right now our ECS (probably) doesn't actually give us the cache hit rate perf we should be able to get by storing components in columns nicely.
[ ] Re-enable smoothing and fix perf (disabled for LD51)
[ ] Re-enable timestep stuff and fix perf and clarify (disabled for LD51)
[ ] Re-enable multiple shadow casters
[ ] Unify shader code snippets like getShadowVis
[x] Switch to actual deferred rendering; right now we do way to much in first fragment

BIG FEATURES:
[ ] Multiplayer reconnect
[ ] GPU-driven rendering options via indirect draw
[ ] GPU-based mesh generation (grass, particles, etc)
  Perhaps inspired by Returnal folks.
[ ] Flexible particle system
[ ] Basic textures on meshes
[ ] Skeletal animation
[ ] Sound and music player for 3d party sound
[ ] TS static tools for refactor and perf

QUALITY-OF-LIFE:
[x] EM usability
  [x] rename 'ensureComponentOn', 'registerSystem', 'registerInit'. These are used a ton and 
[x] Typed registries pattern
  Like how Assets and renderer{.stdPool, .grassPool, .oceanPool} provide nice typing, we should be able to figure out the right pattern so that we can have
  nice typed registries of resources that are perhaps also game specific. Also we
  don't want e.g. "cube game" to need load assets for ocean and fang ship just b/c we want the Assets typed registry.
[ ] All "createXX" -> "mkXX" ?
[ ] All "std-" and "xp-" into "pipe-" or something?

PERF STRATEGY:
[ ] Rust WASM proof-of-concept
[ ] Understand each per-frame allocation site:
  [ ] js arrays and objects
  [ ] typed arrays/buffers (sprig-matrix but also serialize buffers etc)
  [ ] closures (functions created in inner loops?)
  [ ] other hidden allocs?
[ ] Get JS heap to flatline in dev tools
[ ] Understand L2 cache hit rate
[ ] View assembly thats actually run by Chrome for some inner loop work
[ ] Understand GPU utilization and cache hit rates
[ ] Understand GPU memory usage
[ ] Perf testing sandboxes and regression tests
[ ] Understand chrome object perf cliffs e.g. demotion out of fast int / SMI
[ ] custom build-time tools for whole program optimization and analysis including:
  [ ] tree shaking / program slicing
  [ ] inlining vector operations
  [ ] inline single-reference things
  [ ] change pass-by-ptr to pass-by-value for some vecs?
    e.g. if we know some vector isn't read latter, we can pass its components to a fn instead of the vec
[ ] visualize where all our data is in memory

STANDALONE PROJECTS FOR A (HYPOTHETICAL) NEW DEV:
[ ] Scene ray-tracer (for "ground truth" referencing)
[ ] sound effect maker
[ ] music maker
[ ] 3d sterio music playing
[ ] particle system