Big three
(Allegedly) only three big engine components left to implement:
- Map generator
- AI
- Finished car physics
Development focus will now be on getting these done.
Dependencies
Map generator
- Needs a representative set of textures processed and in the game data folders. Otherwise, it won't be possible to test all the different building styles, etc.
- Needs a finished design for the building & surface definition files and how they are to be interpreted/painted (e.g. road layouts)
- Then it's just a case of implementing the required algorithms and tweaking them
AI
- Covers peds walking and peds driving, peds acting in missions, etc.
- Therefore need the map generator complete, for it to be a proper test
- Also need the map generator complete so the ped/car spawn types can be read from the zonedefs
- For driving, will likely need finished physics simulations for the cars
- AI will also cover how peds interact with the different factions - so need enough data for a few factions (and the zone/faction definitions etc. etc.)
Car physics
- Needs art assets for at least one vehicle of each type
- Doesn't rely on map generator or AI, just need a simple test map
- Existing code may form a suitable base for the final code, or some extra research may be needed
TODO:
MUST-CODE: LONG: Next release todo:
- Tweaked car AI/physics to near-final state - cars should handle OK (handbrake turns!), AI should be able to stick to road without problems (detecting obstacles is less of a concern)
- MK 2.5 map generator
- Optimised map screen!
- Cranes? Can use CAR_FIXED to prevent regular physics (gravity, engine) being performed for cars held by the crane. Crane components could be regular ANIM objects. If the crane doesn't rotate, can be all controlled by mission scripts (providing commands are added to attach and detach cars from trailers, identify if a car is attached, etc.) But if cranes do rotate, will be harder to do it from mission scripts, because circular motion would require per-frame updates (Just "AFTER 1"?).
MUST-CODE: LONG: Optimise for 320x256 RiscPC!:
- Fix rendering of east/west faces of blocks that are close to the camera - something to do with the fastdiv stuff? Or the new per-layer coord caching?
- Look for more cases of vec16's being passed on the stack instead of by pointer
- Get rid of float maths in car_cone()!
- Optimise car_physics(): 50% of the time is spent in the movement code, is many times slower on RiscPC than Iyonix.
- Optimise peds_do(): 30% is spent in AI, the other 70% in movement?
- Plotter optimisation options: Get rid of cached rotated tiles and do cordinate conversion on the fly (Maybe just keep ones for 0 and 90 degrees), or reduce output colour depth (8bpp plotter - relying on 8bpp-to-8bpp translation palettes?). Need to find out how much time the loads are taking - hack the LDR instructions out of the tile plotter and see how fast the game runs. Could also look into batching up row plot commands, to see what the tradeoff is with the cache usage? Probably have to be careful not to introduce more memory usage, so is probably unworkable.
- Possible to get rid of the division in tile_row_plot? Just use divbuf to get 64/l and then multiply by ex-x before dividing by 64? Won't exactly give a worthwhile speed boost at the moment, though.
- If paletted UI sprites were supported, could change compass rendering to use palettised renderer and save the time needed to recolour the compass.
- Could also use palettised fonts, saving time and memory. Would need linear plotter code for that, as well as gp_font changes?
- Profile with MP3 music playing!
- Optimise tile plotting for dcache usage: Could try creating a list of all top surface tiles that are at the same height; when it becomes time to plot something that can't go in the list (side surface, vobj, etc.) the list is sorted by tile & palette ptr and then rendered. Alternative is to try different block painting order - create a linked list of blocks to paint, initially containing the 4 screen corner blocks. Then paint them in an order that (a) doesn't violate the outer-to-inner block painting order, and (b) always chooses the block that has the most similarity to the one just painted (in terms of textures). Probably easiest to optimise it for top surface dcache usage rather than side, since few blocks will have side surfaces. Can also try getting rid of the rotated cached tiles (add more tile plotter variants for plotting at the different rotations?)
- Optimised plotter argggh: Cache the tile plot order for each layer? As long as the camera stays above the same block, and the visible area stays the same, and the map hasn't been modified, the cache will be accurate. In order to cache the data, use an A* algorithm that weights each possibility around how much D-cache reuse there is (i.e. the 'length' of each path is how much data must be loaded into the cache). For each block in the layer, there are up to three nodes, representing the three visible sides; between the nodes are dependencies (side nodes require the top node to have been painted; top nodes require the side nodes of the neighbours to have been painted). There will be a max of 5 dependencies? (for the block right underneath the camera). Textureless tiles are counted as well in order to simplify dependency processing (but they have a render cost of 0). Each node has a prerequisite count; this is how many other tiles it's waiting on before it can be painted. When a node is painted, it looks through the list of tiles that are dependent on it and decreases the dependency count. If the count reaches zero, it could possibly add the tile to a per-texture 'ready to render' list, which is then used by the planner to decide what to render next (e.g. if it can't find anything ready which is in the d-cache it looks for the longest ready-to-render list and uses that). For the d-cache tracking, since the RiscPC's d-cache is 16k, and each tile is 4k (plus 512 byte texture), it will only make sense for us to track the 3 most recently plotted textures. Also need to make sure that we use the same cache replacement policy as the RiscPC (round-robin? LRU?). Although writing some code to plan like this could be quite easy, there's still no guarantee that it will be fast if it uses an A* approach, simply due to the large number of possibilities at some stages (particularly with empty tiles) - so rather than add one node at a time, it needs to empty an entire ready-to-render list at a time. This will greatly reduce the number of render order combinations that are being tracked. And due to the render selection method it may be possible to get rid of A* altogether and just go with the first route that's found - testing will be required. Potential data structure for tracking the ready states (may be useless): char array containing flags saying which neighbours need to have been rendered for a block to be rendered. Useless? Block ptr array for pointing to the blocks. Column pointer array to speed up column stuff? Emphasis on keeping memory size down to minimise dcache use of the planner algorithm. Can also remember the in-cache tiles between layers of the map, to guide d-cache usage of next layer (since not all layers will have vobjs to draw inbetween)
- 16 colour palettised tiles? Would just be 2K tile + 32 byte palette. Not sure how many tiles could be converted without significant loss of detail though, or how tricky it will be to get a 4bpp sprite format working in gnarlplot (just masquerade as 8bpp?).
- Why is the RiscPC getting so many internal errors after running the game? Or is the machine dieing?
- 8bpp mode - has the potential to save the 11msec/frame needed for MP3 playback.
MUST-CODE: LONG: Train track roadmap:
- Get the surfmap/heightmap stuff working so the track planner knows where it can and can't go
- Document generator now?
- Write todo list of generator bugs/hacks/etc. so MK 2 plans can begin
- Write train spawn code
- Ped as passenger integration - doesn't need to be done straight away, but need to decide how peds are going to queue up. Need similar thing for traffic lights. Just an ai_mode_go variant where the ped stops moving if he bumps into something?
- Do alternate entering-car anims - peds need to walk on, not slide in sideways. Might be easiest to do this as a fudge in code, by drawing the peds as vobjs rather than into the car sprite.
MUST-CODE: LONG: Traffic light roadmap:
- Presumably this will be done after generator has been fixed to not produce overlapping roads, so therefore there won't be any need for merging traffic light areas?
- Just need to identify intersections that need lights (any with more than two 4+ lane roads?), then add light controllers and map objects (as tiles?)
- Then write control logic - the blocks just outside the intersection will be converted between road and pavement by editing the map, in order to toggle the traffic lights on and off. Need to decide whether the incoming or the outgoing lanes are closed to traffic - would peds get run over by the exiting cars? Maybe check GTA 1?
???
Profit!