157 lines
8.1 KiB
Text
157 lines
8.1 KiB
Text
=========== GENERAL ==============
|
|
|
|
- allow stopping car rotation in air like in Trackmania
|
|
- maybe allow some more air control, like slowing down with brakes, like in TM
|
|
- sound engine: probably all SFX will be procedurally generated, ok?
|
|
- music?
|
|
- probably just make one long track, literally OGG or something, then make
|
|
that be played by the frontend just ALL the time (maybe with the option in
|
|
menu to just turn music off) -- simple frontends can just ignore music
|
|
- allow car to be flipped upside down on start? with start block transform
|
|
- map actually in ASCII format? how will humans edit it?
|
|
- make a simple rendering setting:
|
|
- will exclude images and only draw solid colors, let's say only 16, so that
|
|
memory usage is reduced, CPU rendering is relieved, executable is smaller
|
|
AND frontend doesn't have to use RGB565 (it can basically choose any mode).
|
|
- camera behavior? what if car is riding upside down (on magnet) etc?
|
|
- 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) <-- 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. <-- YES
|
|
- 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 <-- PROBABLY THIS
|
|
- replay format
|
|
|
|
=========== BUGS =================
|
|
|
|
- drawing dithered transparent objects fills z-buffer in the transparent parts
|
|
and then the geometry behind it isn't drawn <- PARTIALLY FIXED NOW
|
|
|
|
=========== HANDLED ==============
|
|
|
|
- drifting: passing some upper threshold on steering force should reduce
|
|
steering friction until reaching some some lower threshold again probably
|
|
- 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.
|
|
- THIS??? Draw further blocks in a simplified way, e.g. just splatting literal
|
|
squares with constant color? See how it looks :)
|
|
- background sky rendering efficiently:
|
|
- first draw the solid color top and bottom
|
|
- then render the 3D scene
|
|
- then iterate over the strip that should have the sky texture and only draw
|
|
to pixels where depth buffer was not overwritten (this step can be left out
|
|
in case we have depth buffer or sky turned off)
|
|
- maybe change sticker to fan? could me more fun: TEST and see
|
|
- track size: 64x64x64
|
|
- sky images could be just composed of 4x4 normal images? then we only need
|
|
one type of image
|
|
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 \
|
|
- accelerator: accelerates (adds some constant to speed?) > same wall texture?
|
|
- maybe jumppad (big "fan")? /
|
|
- dirt: a bit slippery (maybe also a bit slows down?) \
|
|
- magnet: pulls car downwards (allows riding on ceiling etc.) > same wall texture?
|
|
- ice: extremely slippery (can barely turn) /
|
|
- 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.
|
|
- 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 :) <-- DONE
|
|
- PROBABLY LIKE THIS:
|
|
- background textures: 128x128 with image-specific 256 color palette,
|
|
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
|
|
- 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). <-- 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. <-- OF COURSE
|
|
- Removing unseen triangles:
|
|
- make a routine that does the cleaning, call it several times during the
|
|
model construction (waiting till the very end could run out of memory
|
|
with too many vertices/triangles, also processing so many of them could
|
|
even make it slower), it will work like this:
|
|
- go through all triangles, mark each covered or not (we can't remove
|
|
them right away, they need to stay to see if they cover other tris)
|
|
- for each triangle go through all again, mark the checked tri covered if:
|
|
- the other tri has the same vertices (trivial case), OR
|
|
- non-trivial case (consider e.g. two covering quads but split
|
|
differently) not so easy, maybe good enough: if the tris share two
|
|
vertices AND they're in the same plane (EZ to check for axis aligned)
|
|
AND the other tri has a neighbor tri that has the non-shared vertex?
|
|
- remove all marked tris AND vertices that become unused
|
|
- ====== 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
|
|
- how to do accelerators?
|
|
- special material? <-- YES
|
|
- maybe they could simply boost the car in its current direction? YES
|
|
- just keeps accelerating car in its direction, ok?
|
|
- what color format to use? full RGB is bloat+overkill, 332 is too low for the
|
|
textures used. Possibilities.
|
|
- 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? <-- KINDA? There could be an option
|
|
to just get simplified texture color in the 565 value that's normally
|
|
normal color
|
|
- Start and finish blocks will be just the first/last checkpoint blocks (no need
|
|
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?
|