2023-08-23 22:02:05 +02:00
|
|
|
- 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?
|
|
|
|
- maybe jumppad (big "fan")? /
|
2023-07-21 21:17:49 +02:00
|
|
|
- track size: 64x64x64
|
2023-08-26 09:04:43 +02:00
|
|
|
- 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?
|
2023-07-23 16:51:09 +02:00
|
|
|
- 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.
|
2023-07-13 10:53:33 +02:00
|
|
|
- Architecture (modules):
|
|
|
|
- map: loads map n stuff
|
|
|
|
- racing engine (depends on map): handles physics of car with given inputs
|
|
|
|
- rendering engine (depends on map): hanles rendering of the map
|
|
|
|
- game (depends on all): joins it all together
|
|
|
|
- settings, constants etc.
|
|
|
|
- individual frontends
|
|
|
|
- ...?
|
|
|
|
- Textures: size? format? They will likely take a lot of mem, weak computers
|
|
|
|
will have to do without them.
|
2023-07-21 21:17:49 +02:00
|
|
|
- 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 :)
|
2023-08-08 16:17:51 +02:00
|
|
|
- PROBABLY LIKE THIS:
|
|
|
|
- background textures: 128x128 with image-specific 256 color palette,
|
|
|
|
pixel access shouldn't be as time critical here
|
|
|
|
- other textures 64x64 with direct 565 values stored
|
2023-08-26 09:04:43 +02:00
|
|
|
- hmm or possibly 256x256 backgrounds with 16 color image specific palette
|
|
|
|
and dithering? check out how that would look
|
2023-07-08 21:37:47 +02:00
|
|
|
- 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).
|
2023-07-13 10:53:33 +02:00
|
|
|
- Track model has to be preprocessed, unseen walls must be removed else would
|
|
|
|
be too slow.
|
2023-07-21 21:17:49 +02:00
|
|
|
- ====== 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
|
2023-07-23 16:51:09 +02:00
|
|
|
- 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)
|
2023-07-13 10:53:33 +02:00
|
|
|
- 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)
|
|
|
|
- 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.
|
|
|
|
- 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)
|
2023-07-21 21:17:49 +02:00
|
|
|
- maybe just do both? pass to client pixel drawing function both a 565
|
|
|
|
color and a simplified 1 byte color?
|
2023-07-23 16:51:09 +02:00
|
|
|
- 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
|
2023-07-08 21:37:47 +02:00
|
|
|
- Start and finish blocks will be just the first/last checkpoint blocks (no need
|
|
|
|
for special start, finish and CP).
|
2023-07-21 21:17:49 +02:00
|
|
|
- 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:
|