Add todos

TODO.txt

@@ -1,4 +1,14 @@
 - track size: 64x64x64
+- 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.
 - Architecture (modules):
   - map: loads map n stuff
   - racing engine (depends on map): handles physics of car with given inputs
@@ -39,6 +49,11 @@
     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?
+  - maybe they could simply boost the car in its current direction?
+- compile time option to choose how many maps to include (for platforms with
+  lower memory)
 - 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)
@@ -55,6 +70,11 @@
     in some format)
     - maybe just do both? pass to client pixel drawing function both a 565
       color and a simplified 1 byte color?
+- 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
 - 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