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

map.h

@@ -6,36 +6,61 @@
 /**
   The map (track) module for Licar.
 
-  Map format is binary and consists of following values:
+  Map coordinates/size:
+    - map size is 64x64x64 blocks
+    - [0,0,0] is is bottom-left-front-most
+    - x goes right, y goes up, z goes forward
+    - coordinate number is a single number obtained as x + 64 * y + 64 * 64 * z
 
-  - 76, 77 (for "LM", magic number)
-  - ASCII map name
-  - 10 (separator)
-  - ASCII comment
-  - 10 (separator)
-  - block values, each one in the format:
-    - 1 byte type: says the type of block. If the highest bit is 0, the block is
-      normal, otherwise it is a special block (e.g. a "command")
-    - 3 bytes: A, B, C, such that:
-      - A, B and lowest 2 bits of C form the block coordinate number (A being
-        the lowest part etc.), a sequential number going from 0,0,0 in +X
-        direction, then +Y and then +Z.
-      - bits C2 and C3 say the block material
-      - highest 4 bits of C (C4, C5, C6, C7) say the block's transform:
-        - first if C4 is set, the block is flipped in the X direction
-        - then the block is rotated around vertical axis by 0, 90, 180 or 270
-          degrees if C5C6 is 00, 01, 10 or 11.
-        - last if C7 is set, the block is flipped vertically
-  - 255 (terminator)
+  Map format is binary and consists of the following values:
+    - 76, 77 (for "LM", magic number)
+    - ASCII map name
+    - 10 (separator)
+    - ASCII comment
+    - 10 (separator)
+    - block values, each one in the format:
+      - 1 byte type: says the type of block. If the highest bit is 0, the block
+        is normal, otherwise it is a special block (e.g. a "command")
+      - 3 bytes: A, B, C, such that:
+        - A, B and lowest 2 bits of C form the block coordinate number (A being
+          the lowest part etc.)
+        - bits C2 and C3 say the block material
+        - highest 4 bits of C (C4, C5, C6, C7) say the block's transform:
+          - first if C4 is set, the block is flipped in the X direction
+          - then the block is rotated around vertical axis by 0, 90, 180 or 270
+            degrees if C5C6 is 00, 01, 10 or 11.
+          - last if C7 is set, the block is flipped vertically
+    - 255 (terminator)
+
+  In this format order of blocks matters, latter blocks will replace previous
+  blocks placed on the same coordinate. Internally the map will be preprocessed
+  to RAM when loaded so that thing like the magic number and special blocks are
+  removed and the remaining blocks will be sorted for fast block searching.
 */
 
-#define LCR_BLOCK_TRANSFORM_ROT_MASK 0x60
+#define LCR_BLOCK_TRANSFORM_ROT_MASK  0x60
 
-#define LCR_BLOCK_TRANSFORM_FLIP_H   0x10
-#define LCR_BLOCK_TRANSFORM_ROT_90   0x20
-#define LCR_BLOCK_TRANSFORM_ROT_180  0x40
-#define LCR_BLOCK_TRANSFORM_ROT_270  0x60
-#define LCR_BLOCK_TRANSFORM_FLIP_V   0x80
+#define LCR_BLOCK_TRANSFORM_FLIP_H    0x10
+#define LCR_BLOCK_TRANSFORM_ROT_90    0x20
+#define LCR_BLOCK_TRANSFORM_ROT_180   0x40
+#define LCR_BLOCK_TRANSFORM_ROT_270   0x60
+#define LCR_BLOCK_TRANSFORM_FLIP_V    0x80
+
+#define LCR_BLOCK_XYZ_TO_COORD(x,y,z) 
+
+#define LCR_MAP_MAGIC_NUMBER          'L', 'M'
+#define LCR_MAP_TERMINATOR            0xff
+#define LCR_MAP_BLOCK(t,x,y,z,r)      0 // TODO
+
+#define LCR_BLOCK_MATERIAL_CONCRETE   0x00
+
+#define LCR_MAP_COUNT                 1
+
+#define LCR_BLOCK_FULL          0x00 ///< completely filled block
+#define LCR_BLOCK_BOTTOM        0x01 ///< filled bottom half of block
+#define LCR_BLOCK_LEFT          0x02 ///< filled left half of block
+#define LCR_BLOCK_LEFT_FRONT    0x03 ///< filled left front quarter of block
+#define LCR_BLOCK_BOTTOM_LEFT   0x04 ///< filled bottom left quarter of block
 
 typedef struct
 {
@@ -43,4 +68,19 @@ typedef struct
   uint8_t coordMatTrans[3]; ///< coordinate, material and transform
 } LCR_MapBlock;
 
+static const uint8_t LCR_map0[] =
+{
+  LCR_MAP_MAGIC_NUMBER,
+  77, 48, 10    // map name: M0
+  10,           // map comment:
+
+  LCR_MAP_BLOCK( LCR_BLOCK_CUBE,  1,  2,  3, 0),
+  LCR_MAP_TERMINATOR
+};
+
+static const uint8_t *LCR_maps[LCR_MAP_COUNT] =
+{
+  LCR_map0
+};
+
 #endif // guard