Licar/TODO.txt

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

- replay validation
- add time slow down setting
- the horizon on background seems too low? maybe add setting to shift it a bit?
- add argc/argv to gameInit? could be used to quickly start maps, verify
  replays etc.
- maybe each map could have a target time embedded: when beaten, the map would
  be marked as such
- player name (modifiable via resource file)
- popup messages? would be useful for several things: showing checkpoint times,
  showing changes in menu etc.
- 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 =================

- drawing dithered transparent objects fills z-buffer in the transparent parts
  and then the geometry behind it isn't drawn <- PARTIALLY FIXED NOW

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

- allow stopping car rotation in air like in Trackmania
- replay format
- 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?