diff --git a/TODO.txt b/TODO.txt index ee0b4db..99fbafc 100644 --- a/TODO.txt +++ b/TODO.txt @@ -1,3 +1,4 @@ +- track size: 64x64x64 - Architecture (modules): - map: loads map n stuff - racing engine (depends on map): handles physics of car with given inputs @@ -8,13 +9,36 @@ - ...? - 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 format: just a list of (x,y,z,transform,block_type) elements. - - text or bin? +- ====== 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) @@ -24,11 +48,20 @@ 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. -- How to render sky? Spherical mapping? Just constant color? - 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: diff --git a/game.h b/game.h new file mode 100644 index 0000000..305d37b --- /dev/null +++ b/game.h @@ -0,0 +1,6 @@ +#ifndef _LCR_GAME_H +#define _LCR_GAME_H + +#include "map.h" + +#endif // guard diff --git a/main.c b/main.c new file mode 100644 index 0000000..247e0ae --- /dev/null +++ b/main.c @@ -0,0 +1,9 @@ +#include + +#include "game.h" + +int main(void) +{ + puts("aaa"); + return 1; +} diff --git a/map.h b/map.h new file mode 100644 index 0000000..e3a12c5 --- /dev/null +++ b/map.h @@ -0,0 +1,46 @@ +#ifndef _LCR_MAP +#define _LCR_MAP + +#include + +/** + The map (track) module for Licar. + + Map format is binary and consists of 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.), 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) +*/ + +#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 + +typedef struct +{ + uint8_t type; ///< block type + uint8_t coordMatTrans[3]; ///< coordinate, material and transform +} LCR_MapBlock; + +#endif // guard diff --git a/settings.h b/settings.h new file mode 100644 index 0000000..028ca41 --- /dev/null +++ b/settings.h @@ -0,0 +1,10 @@ +#ifndef _LCR_SETTINGS_H +#define _LCR_SETTINGS_H + +#ifndef LCR_SETTING_MAP_MAX_SIZE + /** Maximum number of blocks a map can consist of, decreasing will save RAM + but also rule out loading bigger maps. */ + #define LCR_SETTING_MAP_MAX_SIZE 256 +#endif + +#endif // guard