TODO

:::::::::::::::::::::::::::
:: robotrider TO-DO list ::
:::::::::::::::::::::::::::


NEXT
- Modify the room generation algorithm so it uses the clusters as the voxels in the algorithm, generating rooms for a chunk of clusters at a time (superclusters).
  Doing this at all the scale levels up to universe-sized would be a way to generate cluster connectivity for the whole universe, where 'empty' clusters would have no rooms at all, and 'full' clusters would be connected.
- Sample the isosurface for every cluster in the exterior of each room/hall created, with a different resolution depending on distance
- Create a little 'mesh LOD' system that keeps a cache of dynamic mesh LODs that are resampled when necessary according to distance
- Generate several of these 'superclusters' and connect neighbouring
- Decent RNG and determinism

  SIDE PROJECTS (for when you're tired of the above)
- Actually separate the engine components into a separate project so it's possible to start doing very different ideas with it while keeping a coherent engine for all of them.
- Use it for fast game-jam type game ideas.
- My very own unsensible soccer.
- Start creating music-synchronized music visualizations, using the ideas about expanding your typical 'lo-fi' semi-animated videos, as well as other more classic "demoscene-like" ideas.
  Investigate whether to use a library or take the chance to learn about how to analyze a music stream to detect beats, signatures, phrases and moods. (something that will also be used for the game!)
- Start a new project that uses the engine to restart the old idea of project 0nirika, using independent scriptable layers animated by tracks to composite visualizations (which could be demos, or..


WORLDGEN
- Space Volumes partitioning using BSP at various scale levels
- Procedural generation of some kind of infinite pipe-like world structure
- Unify all mesh pools and put them behind a ticket mutex so they can be shared by threads. In general, think about how to minimize synchronization between workers and the main thread.

INPUT
- Rotating the camera with the mouse looks jittery (probably has to do with not using the frame delta time)
- Disable Windows key while fullscreen (https://caseymuratori.com/blog_0006)

EDITOR
- Hot reloading doesn't seem to work here? (was testing editor camera params)
- Entity selection mode and showing debug data about them
- Orbiting camera around selected entity (with progressive zoom)
- A nice way to get nicely distributed debug colors https://martin.ankerl.com/2009/12/09/how-to-create-random-colors-programmatically/
- ImGui theme https://github.com/ocornut/imgui/issues/1607#issuecomment-372554344

GRAPHICS
- Frustum culling
- Decent chasing camera + avoiding geometry (https://www.braynzarsoft.net/viewtutorial/q16390-31-sliding-camera-collision-detection)
- Start working on surfaces & lighting
- Edge detection shader
  From reddit: "If you have a deferred renderer and it can write triangle IDs to a texture, then you can render a wireframe
  by just doing a simple edge detect on the triangle ID texture. Google for "edge detection" and/or "Sobel filter" for details.
  The nice things about this are that (a) you get hidden surface removal for free; and (b) it's a fixed cost to render, no matter how much geometry you have."
  (http://williamchyr.com/2014/03/development-update-edge-detection/)

AUDIO
- Win32: switch WASAPI to callback mode to reduce buffer size and improve latency.
  This implies creating a separate dedicated thread that just blits audio to the output.
  The buffer strategy wouldn't change, the game would check how much space is available and
  would produce the appropriate amount of frames, and the blitter thread would simply blit said
  amount to the device.
  Refs:
  https://msdn.microsoft.com/en-us/library/windows/desktop/dd370875(v=vs.85).aspx
  https://msdn.microsoft.com/en-us/library/windows/desktop/dd370844(v=vs.85).aspx
  https://github.com/pauldotknopf/WindowsSDK7-Samples/blob/master/multimedia/audio/RenderExclusiveEventDriven/WASAPIRenderer.cpp

ASSETS
- Add a global Handle concept.
  A Handle is about locating resources at runtime, hence it's a glorified pointer. For a 64-bit Handle this could be something like:
  · 8 bit for the system allocator where the resource was allocated
  · 8 bit for various flags
  · 16 bit for a generation number
  · 32 bit for the allocator-dependent "index"
  This is of course only valid at runtime.
  For persistence, we could have a 2-way association between asset ids and Handles. We could simply exchange asset ids for allocator index when going to/coming from disk.

ENGINE
- Use the concept from https://github.com/antirez/sds to create a new CString class (btw start using class for these 'handled' datatypes?), but do it a bit better (and in C+)
  Add a pointer to that and an 'owned' flag to our read-only string so that:
  · Memory ownership is explicit
  · Null-termination and interoperability with C apis is handled better
- Add a separate arena per thread so we don't have to keep thinking where to put per-thread work memory
- Separate physics & input thread running at a high framerate? (investigate)
- Switch Fletcher to MurmurHash (https://github.com/aappleby/smhasher/wiki)
- Implement a decent hashtable with probing and think of a resizing strategy
  Before substituting the one we have, improve it by having a preallocated array for the chained entries next to the main one, as mentioned in
  https://softwareengineering.stackexchange.com/a/361966, and also the comments in https://stackoverflow.com/a/23821940/2151254
  For the new one, use Robin Hood strategy (https://www.sebastiansylvan.com/post/robin-hood-hashing-should-be-your-default-hash-table-implementation/
  & https://www.sebastiansylvan.com/post/more-on-robin-hood-hashing-2/).
  Then put them both through some kind of benchmark and compare (maybe have a way to switch between them at compile time with a template or something).

DEBUGGING
- Make sure out-of-frame counters are handled and shown correctly so we can properly profile multithreaded code
- Hot reloading seems to be broken for ImGui elements
- Memory stats for arenas and pools
- Profiler (have a look at the ImGui plot libraries as a starting point for the UI) (https://github.com/epezent/implot)
  (Also have a look at how iprof - in Google Drive - handles hierarchical & callstack info, and tips to minimize overhead)
  (One cool trick, f.e., is to just gather an rdtsc timestamp for each zone, and then in the frame tick/update, do a ratio of a single
  QPC wall clock and an rdtsc delta for the whole frame, and scale all zones by that to get wall clocks for them much faster).
  (It also seems to detect high variations of the QPC/cycles ratio to signal changes in processor clock, 'turbos' etc., would be cool
  to display that ratio somewhere too).
- Live editable 'switches' data file (reloadable asset) that can overwrite generic game & platform variables (similar to what Blow did for Sokoban)
- Command completion & history navigation in the console
- Really dump game state to disk (asynchronously) and study how hard it would be to make it loadable across evolving game state revisions (this would need a proper serialization system)
- Add a command line switch & ingame command to load a recorded input block from disk

TESTING
- Basic data types
- Math library
- All multithreaded code! (queues, etc.)

MISC
- Switch all indices in all loops and all data types operators to signed integers, as they're faster (Chandler dixit)
  (https://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/)