Update todo

This commit is contained in:
Miloslav Ciz 2023-08-27 14:34:23 +02:00
parent ea7aa5a409
commit ae8331eb11

View file

@ -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: