diff --git a/TODO.txt b/TODO.txt index c522cab..f645828 100644 --- a/TODO.txt +++ b/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 - - accelerator: accelerates (adds some constant to speed?) / - - 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? + - concrete: normal \ + - accelerator: accelerates (adds some constant to speed?) > 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 to turn off textures completely + - possibility of simple procedural textures to save space! <-- SOUNDS NICE + - 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? - - maybe they could simply boost the car in its current direction? + - special material? <-- YES + - 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: