Add todos
This commit is contained in:
parent
17f7f9d70a
commit
7e8c82fae3
4 changed files with 6386 additions and 26 deletions
20
TODO.txt
20
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
|
||||
|
|
50
map.h
50
map.h
|
@ -6,20 +6,24 @@
|
|||
/**
|
||||
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
|
||||
|
||||
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")
|
||||
- 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.
|
||||
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
|
||||
|
@ -27,6 +31,11 @@
|
|||
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
|
||||
|
@ -37,10 +46,41 @@
|
|||
#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
|
||||
{
|
||||
uint8_t type; ///< block type
|
||||
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
|
||||
|
|
2997
small3dlib.h
Normal file
2997
small3dlib.h
Normal file
File diff suppressed because it is too large
Load diff
3303
tinyphysicsengine.h
Normal file
3303
tinyphysicsengine.h
Normal file
File diff suppressed because it is too large
Load diff
Loading…
Reference in a new issue