- track size: 64x64x64
- 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!
  - possibility to turn off textures completely
  - how to map textures to blocks?
    - figured out nice procedural mapping in Blender :)
- 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).
- Track model has to be preprocessed, unseen walls must be removed else would
  be too slow.
- ====== 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
- 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)
  - 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.
- what color format to use? full RGB is bloat+overkill, 332 is too low for the
  textures used. Possibilities.
  - 565
  - 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?
- Start and finish blocks will be just the first/last checkpoint blocks (no need
  for special start, finish and CP).
  - 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

BUGS:

DONE: