Pipe dreams
Pipe dreams - to be implemented once engine is complete!
8bpp support
Goal: Improve support for older machines (pre-Risc PC, or just pre-StrongARM?) by adding option for 8bpp screen output (and 8bpp sound?). This will reduce memory footprint and increase rendering speed.
Execution: Simplest method of getting 8bpp output would be via a screen postfilter, that would convert a 16bpp screen buffer to 8bpp. However this would only make things slower and use more memory; so a more advanced technique is needed:
- All 16bpp sprites are converted to 8bpp upon loading; masked images use palette index 0 or 255 for transparency, as this is near enough to black/white to not be noticeable. Will require development of extra sprite plotters to handle rendering of these (as part of gnarlplot?)
- Ped and car sprites (i.e. those which are cached) will still be stored in memory as 8bpp. But instead of caching them to a 16bpp image they will be cached to 8bpp with colour 0/255 used for transparency, as above. This will also require extra plotters to be written.
- Any other screen access (fades, etc.) will need rewriting to operate correctly in 8bpp
8bit sound: Simply need to write new buffer fill code that downsamples 16bit buffers to 8bit. Maybe also downsample sound (8bit, 11khz?) when loading, to reduce memory footprint.
Pre-OS 3.5: Current versions of GCC can be told to produce compatible code, but to get proper performance on non-old hardware this would most likely involve using a second binary. Also, would need to check whether clib stubs are compatible (and check source code for any 3.5+ SWIs, etc.)
Linux support
Goal: Play DeathDawn on my Zaurus!
Execution: ARM Linux would be the primary target, as existing ARM code in WOUM/gnarlplot should migrate without problems. I/O would most likely be performed using SDL. File access would need rewriting, to perform RO -> Linux path conversion. All data files (i.e. sprites) would need converting via ddconvert to raw data format, to ensure there's no need for OS_SpriteOp calls (or appropriate SWIs equivalents can be written as needed) Also need to make sure all calls to clock()/time() will work properly with different resolution timers!
DS support
Goal: Play DeathDawn on my DS!
Execution: Major rewrite of code would be needed to support streaming of data from ROM (unless FAT filesystem is assumed, in which case can treat as streaming from disc). Map generator may need to be cut; map data may not even fit in RAM, and may need to be streamed as well; car and ped sprites can be cached in RAM as usual; tiles and other sprites will need to be cached per-frame in order to get good rendering speed. Renderer can be rewritten to use DS's hardware acceleration; one screen pure 3D, other screen for map, pager, score, etc. Low screen resolution may be a problem, may need to tweak camera and/or decrease texture sizes. But the good news is that existing ARM code in WOUM/gnarlplot should work. File access would need rewriting, to perform RO -> Linux(?) path conversion. All data files (i.e. sprites) would need converting via ddconvert to raw data format, to ensure there's no need for OS_SpriteOp calls (or appropriate SWIs equivalents can be written as needed). Save files will also need streamlining - won't be enough space to do a full map dump.
Network play
Goal: Kill people over the internet!
Execution: Can use Iyonix & RPC for development. Somewhat peer-to-peer rather than client-server; i.e. if two players are far apart, their machine will have control over their player and any nearby cars & peds. If they get close enough for their spheres of influence to intersect, control of peds/cars will be handed over to an arbitrary machine (whichever one is running fastest? slowest? random?) Thus each ped/car/object will need an extra field indicating which machine ID is in control of it, and will have a 'network item ID' with which all machines can identify that object.
Alternative: Strict client-server via dedicated server. Server runs the mission script, is updated with client details every frame, sends updates to clients every frame; if clients are far apart they are in control of their own ped & local peds/cars; as clients get close to one another, the server will take control of all objects within range, to clients are on equal footing. Would be tricky to develop without cross-platform server or 3rd RO machine. (Or windoed operation?)
WIMP play
Goal: Play in WIMP, for no good reason (except network play development, or extra debugging?)
Execution: Rewrite main game loop to operate during idle poll events. Screen output goes to a sprite which is then rendered to the game window (DMA?). Sound would need rewriting to operate independently of core code; i.e. move into a module. Moving sound into module would also provide extra crash protection.
Full cross-platform
Goal: i.e. like the ARM Linux one, but not limited to ARM.
Execution: Rewrite the appropriate bits of DeathDawn/WOUM/GnarlPlot to use C equivalents of code if not running on ARM platform. Use SDL for I/O. Rewrite file access to be more agnostic of host OS. More plugin-y renderer system, to support hardware rendering where possible? (DS, OpenGL, etc.) A quick check suggests this won't be too hard to pull off; and then ARM code can be introduced again a bit at a time to provide ARM Linux/DS support.
Lighting
Goal: Make it look spiffy like GTA 2!
Execution: Would be much trickier than day/night cycle. Only real way would be via lightmaps applied to each surface; there may be just enough regs spare to support this in the tile plot code, but entity plotting would be near impossible (unless entities use uniform lighting based around their center point; but it may still be tricky to apply this without resorting to caching images).
Alternative lighting: Build a Z buffer for the screen, light everything as a post-process. Or possibly build a 'light buffer'; i.e. when rendering tiles the light buffer is written to, but entities don't cause it to be written to (since 99% of entities will be on the ground and thus lit the same amount as the ground itself). Then, once all map objects have been rendered, the light buffer is applied as a fullscreen lightmap. Unfortunately this won't work well with fullbright lights (unless these are rendered afterwards, or force the lightmap to full brightness at that location; would require modification of car plotting though (unless the car is plotted into the light map?))
(Realtime) shadows: Shadows for vehicles is easy; just render an alpha'd image over the screen before rendering the objects for that height. Buildings would be trickier; maybe by adjusting the lightmaps for tiles next to buildings? i.e. place special flags in the tiles next to buildings for what side the building is on, then build shadow map appropriately, in 1 block radius ala GTA 1 shadowing.
Seamless map
Goal: No loading screens!
Execution: Rewrite map generator to run in the background during gameplay. Will require all art resources to be held in memory (or just an index in memory, and actual content streamed from disc as necessary?). Depending on the player's location, the map generator will focus on building the map in a certain direction (north/south/east/west/etc.). Once the player reaches the level boundary, the map and all objects are shifted to the side and the new area is filled in. Will require more advanced stack/block tracking (to allow unused stacks/blocks to be pruned), more advanced map generator (if roads, buildings, geography, etc. is to join up properly), and possibility of generating only some areas of a city at once (full fractal generator?)
Hi-res textures
Goal: Double the texture resolution. It looks like the Iyonix can handle it, and other cross-platform ports will undoubtedly be able to do it too.
Execution: Not much code needs to be changed to support this; texture resolution can easily be introduced as a #define. However some features which rely on '1 pixel being 1/64th' (such as specification of coordinates in cardefs) will need adjusting - so maybe make that code operate at a fixed 1/64th scale, but the texture can be scaled independently? (as worked out by the #define value etc.)
Of course, this will mean redrawing everything (Except for bits which can be rebuilt - e.g. Drawfile cars)
Full 3D
Goal: Play in full 3D, ala GTA 3
Execution: Yeah, right!
BBC version
Goal: Proper hardcore!
Execution: Mode 6 grahpics (1bpp, 320x200, 8K RAM). Low-res (16x16? 32x32?) tiles. Simple tile plotter, to take into account simple memory bus? Or may need to be very complex, to take into account odd pixel ordering? Don't changes in memory page result in delays? Sprite rotation would be very tricky, masked sprites also (1bpp leaves no room for a transparent colour!) Would need to develop various tech demos first - rotating sprites, tile plotting, etc. Getting scaling to work would also be tricky - maybe fix view at a specific zoom level? But what about ramps, different height buildings, etc.? Alternative is to go with fixed viewpoint, ala grandtheftendo. Could also use pre-rotated car/ped images, etc. City represenentation would also be tricky - how to fit a reasonable size map into a tiny area of memory? Fractal generator thingy that caches small blocks? Would probably need severe limitations on map structure if to fit inside 32K of RAM.
TODO:
DOCS: LONG: Plan out roadmaps for the other pipedreams? some share similar features/requirements
???
Profit!