Update todo

TODO.txt

@@ -1,17 +1,15 @@
+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                                           \ same wall texture
+  - concrete: normal                                           \ 
-  - accelerator: accelerates (adds some constant to speed?)    /
+  - accelerator: accelerates (adds some constant to speed?)     > same wall texture?
-  - dirt: a bit slippery (maybe also a bit slows down?)        \ same wall texture
-  - mud: slows down                                            /
-  - ice: extremely slippery (can barely turn)                  \ same wall texture?
   - maybe jumppad (big "fan")?                                 /
+  - dirt: a bit slippery (maybe also a bit slows down?)        \ 
+  - mud: slows down                                             > same wall texture?
+  - ice: extremely slippery (can barely turn)                  /
 - track size: 64x64x64
-- block materials:
-  - concrete, normal
-  - dirt, a bit slidy, decreases speed a bit?
-  - ice? super slidy (like in the old TM)
-  - accelerator, probably: auto-accelerates, plus increases accel.
-  - decelerator? decreases speed a lot?
 - 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
@@ -22,6 +20,8 @@
     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 :)
 - Architecture (modules):
   - map: loads map n stuff
   - racing engine (depends on map): handles physics of car with given inputs
@@ -32,21 +32,21 @@
   - ...?
 - 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 of simple procedural textures to save space! <-- SOUNDS NICE
-  - possibility to turn off textures completely
+  - possibility to turn off textures completely <-- MUST HAVE
   - how to map textures to blocks?
     - figured out nice procedural mapping in Blender :)
   - PROBABLY LIKE THIS:
     - background textures: 128x128 with image-specific 256 color palette,
-      pixel access shouldn't be as time critical here
+      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
-    - hmm or possibly 256x256 backgrounds with 16 color image specific palette
-      and dithering? check out how that would look
 - 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).
+  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.
+  be too slow. <-- OF COURSE
 - ====== Track/map format: list of map blocks. =======
   - one block record:
     - type: 5 bits?
@@ -69,37 +69,41 @@
     compress the stored maps.
   - binary
 - how to do accelerators?
-  - special material?
+  - special material? <-- YES
-  - maybe they could simply boost the car in its current direction?
+  - maybe they could simply boost the car in its current direction? YES
+  - just keeps accelerating car in its direction, ok?
 - 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)
+  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.
+    roll) -- not accurate but good enough. <-- YES
 - what color format to use? full RGB is bloat+overkill, 332 is too low for the
   textures used. Possibilities.
-  - 565
+  - 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?
+      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
 - 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
+    blinking <-- PROBABLY THIS
 - Start and finish blocks will be just the first/last checkpoint blocks (no need
-  for special start, finish and CP).
+  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?
 
 BUGS: