=========== GENERAL ==============

- FPS logging for optim
- use 332 in SDL with potato?
- option to turn on simple 332 colors?
- c99 may impose limit 4095 chars on str literal, gives warning on internal
  data file, try to somehow hack around it (maybe just convert it to an array in
  the end?) Maybe this: make a standalone C file with the string in it that
  when compiled and run outputs the array.
- add indicator that menu can be scrolled down
- car deglitch idea: deglitch only if the middle joint collided this frame?
- some kinda easteregg in menu or smt
- culling is very slow now, it showed that distance bailout can accelerate it
  a lot, try to make a more accurate bailaout and see if it's faster (watch
  out for bugs due to false positives)
- improve the car unstucking? maybe we can just keep the position of the car
  and ONE wheel (other joint positions can be computed)
- some kind of special map block that would say where 3D triangles don't have
  to be drawn? could optimize rendering and map loading a lot
- maps to make:
  - there should be these maps:
    - compiled in:
      - standard maps, let's say 5?
      - additionally a few (5?) extremely simple maps, compile time option to
        only include these, for very weak devices with limited block/triangle
        count
    - bonus maps in the external file (also 5?)
  - map types:
    - purely falling map
    - traveling salesman kind of maze, with fans n shit
    - city map?
    - some kinda buggy bumpy downhill
    - map where car starts upside down
    - dirt map
    - ice map
    - boss map
    - text or picture from blocks?
    - chessboard from different materials
    - falling tube map?
    - grass hills as decoration?
    - something with multiple roads
    - RPG kinda map? could be in bonus maps
    - some speed map (mostly flat to prevent high speed bugs)
    - some (at least partially) interior map
    - something with multiple finishes
    - U-ramp to build speed and jump up to catch a CP (done)
    - jump through air ring with CP
- try to speed up the slow culling
- test:
  - long replay
  - replay stretching works
  - replay with input not occuring for more that LCR_SETTING_GHOST_STEP
- replay validation
- make the racing module usable by itself, e.g. to allow making tools for
  verifying replays etc., i.e. make the module measure time, count checkpoints
  etc.
- allow slowing down in air like in TM?
- compile time option to choose how many maps to include (for platforms with
  lower memory)
- at the end check error handling, make sure the game handles garbage data in
  resource file etc.

=========== BUGS =================

- immediately after starting the map countdown seems to be lower
- the pinch collision test seems to sometimes stop the car e.g. after falling
  from bigger height or when running into ramp at high speed (or not?) - FIX

=========== HANDLED ==============

- add ifdefs that change car color?
- sometimes getting a SLIGHTLY slower time counts as beating it (prolly
  conversion fail) (SEEMS FIXED NOW)
- make a small txt game manual
- maybe each map could have a target time embedded: when beaten, the map would
  be marked as such
- on tiny map 1 maybe add a few block below the first sharp ramp to prevent
  those nasty piercing bugs
- replays are bugged, seem to not steer
- make the U-ramp map taller due to new physics
- on 1st map the camera is obscured by the wall at the start, fix it somehow
  (not the best first impression) <-- shifted start pos.
- replay format should probably record game version
  - also there should probably be some version system that says version of
    physics vs version of everything else; replay could only record physics
    version (maybe just two or three chars?)
- player name (modifiable via resource file) <-- prolly not
- address the bug with driving on curved ramp diagonally, try DECREASING number
  of reshapes
- maybe remove setting string from menu (like music: 1) and use popups instead
  (have just music and show "on" or "off" in popup)
- add indication when CP is taken: in 1st man view it may be unclear if CP was
  taken or not otherwise
- popup messages? would be useful for several things: showing checkpoint times,
  showing changes in menu etc.
- allow stopping car rotation in air like in Trackmania
- countdown and finish text sometimes seem to jump horizontally somehow
- add argc/argv to gameInit? could be used to quickly start maps, verify
  replays etc. Options:
  -sN: sound (0/1)
  -mN: music (0/1)
  -cN: set camera
  -M:  load last map in resource files (good for making maps)
  -R:  load last replay in resource files (good for making TASes)
  -P:  load and play against last replay in resource files
- bug: background horizon position depends on resolution! fix
- option to disable crash sounds (and so code that detects crashes)
- drawing dithered transparent objects fills z-buffer in the transparent parts
  and then the geometry behind it isn't drawn <- PARTIALLY FIXED, LOOKS GOOD
- starting test replay two twice in a row breaks it
- ghosts: if the replay for the ghost is too long (too many samples for the
  preallocated array), we can subdivide the sample resolution (i.e. "stretch"
  the samples) to cover the whole replay (ofc for the price of worse quality).
- force chunk reload upon map restart so that there's no blinking at start
- ghost visible distance -- maybe even car should have this (watching rep with
  free camera)? maybe generalize setCar/GhostVisibility to
  setCarGhostVisibilityDistance where 0 means make invisible?
- add time slow down setting
- the horizon on background seems too low? maybe add setting to shift it a bit?
- replay format
- why does the ghost stop in front of the finish?
- prevent time overflow! stop incrementing level frame once it's at maximum
- car shadow? probably would have to be done as screen space effect with
  z-buffer (shadow as 3D model would require collision detection and would make
  renderer depend on physics engine). Maybe like this:
  - project some point below the car to screen
  - fill a dithered oval around this point, but only as long as the point's
    Z coord is close to the value in Z-buffer
  ^ PROBABLY NOT, tried it and looked weird
- music?
  - probably just make one long track, literally OGG or something, then make
    that be played by the frontend just ALL the time (maybe with the option in
    menu to just turn music off) -- simple frontends can just ignore music
- sound engine: probably all SFX will be procedurally generated, ok?
- make a simple rendering setting:
  - will exclude images and only draw solid colors, let's say only 16, so that
    memory usage is reduced, CPU rendering is relieved, executable is smaller
    AND frontend doesn't have to use RGB565 (it can basically choose any mode).
- drifting: passing some upper threshold on steering force should reduce
  steering friction until reaching some some lower threshold again probably
- was able to take a CP without it changing color to gray, try to reproduce
- Environments: just different textures for a cube inside which the tarck is,
  the cube won't have the top side, texture can have transparency (sky see
  through) <-- NO
  - UPDATE: tho rasterization of the big cube could take whole screen: too slow.
    Maybe just have a model + texture for each env? (still could allow transp).
  - OR: environment could just be a sky texture (or just sky color?) plus a
    floor texture? pretty KISS. SKY DOESN'T HAVE TO BE SPHERICALLY MAPPED, it
    can simply rotate horizontally and shift vertically (camera will never
    roll) -- not accurate but good enough. <-- YES
- asset system:
  - assets are to be loaded from one BIG string consisting of substrings, each
    substring adds a map, replay, setting etc.
  - part of the substring will be hardcoded (default maps)
  - optionally a frontend can extend this from a file
  - details:
    - strings separated by '#'
    - each string has format:
      - magic number:
        - map: LM
        - replay: LR
        - record time: LT
      - name
      - ';'
      - string content
        - map: see map.h
        - replay:
          - map name
          - map hash
          - data: frame, input state
        - record time: decimal time in ms
- maybe allow some more air control, like slowing down with brakes, like in TM
- map actually in ASCII format? how will humans edit it?
- racing update step should return events that happened, e.g.:
  - CP taken
  - crash (to play sound)
  - finish
  - etc.
- rework the code for special blocks, we have to literally remember the last
  block, not the pointer, now it won't work e.g. if wanting to repeat an
  empty block
- How to visually represent checkpoints (and finish)?
  - Could be kind of an arrow made of single tri above the block?
    (try how it looks in Blender)
  - Probably just a literal block (or pyramid) DRAWN WITH DITHERING and/or
    blinking <-- PROBABLY THIS
- EFFICINT MAP DRAWING:
  - map will be subdivided into subblocks (probably 16x16x16 or 8x8x8), only
    nearest subblocks (and possibly only those in viewing direction will be
    drawn)
  - HERE IS THE BEAUTY: when building the map 3D model from map format, order
    the triangle indices so that they are grouped by blocks in the index array,
    i.e. if we draw first N triangles we actually draw the fist subblock, if
    we draw the next N triangles we draw the second subblocks etc. Then just
    create a function to draw Nth subblock and use this to only draw the
    subblocks we want to draw.
  - THIS??? Draw further blocks in a simplified way, e.g. just splatting literal
    squares with constant color? See how it looks :)
- background sky rendering efficiently:
  - first draw the solid color top and bottom
  - then render the 3D scene
  - then iterate over the strip that should have the sky texture and only draw
    to pixels where depth buffer was not overwritten (this step can be left out
    in case we have depth buffer or sky turned off)
- maybe change sticker to fan? could me more fun: TEST and see
- camera behavior? what if car is riding upside down (on magnet) etc? <- looks cool now
- allow car to be flipped upside down on start? with start block transform
- track size: 64x64x64
- sky images could be just composed of 4x4 normal images? then we only need
  one type of image
TOTAL SIZE OF TEXTURES:
  - 64 x 64 x 2 = 8192, 6 x floor + 2 x wall + 1 x car = 8 * 8192 = 73728
  - (128 x 128 x 1) x 3 background = 49152
  - total = 122880
- OK so materials (final?):
  - concrete: normal                                           \ 
  - accelerator: accelerates (adds some constant to speed?)     > same wall texture?
  - maybe jumppad (big "fan")?                                 /
  - dirt: a bit slippery (maybe also a bit slows down?)        \ 
  - magnet: pulls car downwards (allows riding on ceiling etc.) > same wall texture?
  - ice: extremely slippery (can barely turn)                  /
- Architecture (modules):
  - map: loads map n stuff
  - racing engine (depends on map): handles physics of car with given inputs
  - rendering engine (depends on map): hanles rendering of the map
  - game (depends on all): joins it all together
  - settings, constants etc.
  - individual frontends
  - ...?
- Textures: size? format? They will likely take a lot of mem, weak computers
  will have to do without them.
  - possibility of simple procedural textures to save space! <-- SOUNDS NICE
  - possibility to turn off textures completely <-- MUST HAVE
  - how to map textures to blocks?
    - figured out nice procedural mapping in Blender :) <-- DONE
  - PROBABLY LIKE THIS:
    - background textures: 128x128 with image-specific 256 color palette,
      pixel access shouldn't be as time critical here (128x128/256 looks better
      than 256x256/16/dithering, tried in Blender)
    - other textures 64x64 with direct 565 values stored
- Rendering: two pass: 1st pass renders the scaled down background (possibly not
  rendering floor, can be just pure green for "grass") to prevent overflows,
  second pass renders the tracks (or the nearest part of it). <-- POSSIBLY NOT
  CAUSE BACKGROUND WON'T BE A 3D MODEL
- Track model has to be preprocessed, unseen walls must be removed else would
  be too slow. <-- OF COURSE
  - Removing unseen triangles:
    - make a routine that does the cleaning, call it several times during the
      model construction (waiting till the very end could run out of memory
      with too many vertices/triangles, also processing so many of them could
      even make it slower), it will work like this:
      - go through all triangles, mark each covered or not (we can't remove
        them right away, they need to stay to see if they cover other tris)
      - for each triangle go through all again, mark the checked tri covered if:
        - the other tri has the same vertices (trivial case), OR
        - non-trivial case (consider e.g. two covering quads but split
          differently) not so easy, maybe good enough: if the tris share two
          vertices AND they're in the same plane (EZ to check for axis aligned)
          AND the other tri has a neighbor tri that has the non-shared vertex?
      - remove all marked tris AND vertices that become unused
- ====== Track/map format: list of map blocks. =======
  - one block record:
    - type: 5 bits?
    - transform: 4 bits (16 possibilities):
      - top up:
        - non-mirrored:
          - none
          - rotate 90 around vertical
          - rotate 180 around vertical
          - rotatae 270 around vertical
        - mirrored:
          - same 
      - top down:
        - same
    - material: 3 bits
    - coords: 18 bits
  - MAKE SPECIAL KINDS OF BLOCKS that will just e.g. copy the previously
    specified block 5 times forward, make cube of it etc. These special blocks
    will be preprocessed out to normal blocks when the map is loaded. This will
    compress the stored maps.
  - binary
- how to do accelerators?
  - special material? <-- YES
  - maybe they could simply boost the car in its current direction? YES
  - just keeps accelerating car in its direction, ok?
- what color format to use? full RGB is bloat+overkill, 332 is too low for the
  textures used. Possibilities.
  - 565 <-- YES
  - leave choice of colors to frontend (but textures still have to be stored
    in some format)
    - maybe just do both? pass to client pixel drawing function both a 565
      color and a simplified 1 byte color? <-- KINDA? There could be an option
      to just get simplified texture color in the 565 value that's normally
      normal color
- Start and finish blocks will be just the first/last checkpoint blocks (no need
  for special start, finish and CP). <-- NO
  - Or maybe not, we would need to somehow mark these with extra vars, plus we
    dont need to save space for block types really.
  - Maybe there could be no finish, the player would just have to take all the
    checkpoints? <--- THO probably not, would rule out "there and back" maps
  - THIS?: CP and FINISH will just be a special block, that's it?
