The next version of the RRPGE specification will introduce some quite radical changes.
I was experimenting for a while with the current system, especially with it's graphics capabilities, but also covering some other aspects. Based on these I got to get some considerably clearer image on what the system is capable to do, what makes it harder doing those, and what features are over-complicated or not quite necessary.
Based on these experiments I decided to radically trade system complexity to gain more useful properties. As of now the followings are visible:
- - The display generator will only have two layers instead of four. The graphics accelerator if used properly is mostly capable to do what four layers would do, while this cut greatly simplifies the display side in many aspects.
- - User side interrupt system will be removed. Further changes in the system make this unnecessary for most usual tasks, and it again simplifies the system considerably.
- + Graphics co-processor based on a FIFO concept. This can most importantly operate the Accelerator, enabling rendering running in parallel with the CPU's other tasks. This greatly increases the performance of both rendering and CPU based tasks, even balancing the execution costs better in emulators.
- + Line drawing mode for the Accelerator enabling creating various wireframe graphics.
- + Simple DMA peripherals for various memory copies, both within CPU RAM and across CPU and Video RAM.
- + Incrementing the CPU memory size from 2Mb to 4Mb. This memory size optionally enables using short (some minutes), low quality sampled audio for cheap music.
- Smaller changes in the Accelerator for easier use, needing less calculations and register writes to perform usual blits.
- Smaller changes in the Audio subsystem and the Mixer DMA, following the concepts applied on the graphics accelerator.
Roughly these are on the list currently making it's way into the specification. The CPU does not change, however the handling of peripherals except for the earlier finalized input system change radically, needing to rewrite most of the examples as well.
The normal usage scenarios of the graphics subsystem are getting clearer. The Accelerator is capable to perform quite well, enabling higher level double-buffered rendering contrary to the tile + sprite concepts some systems (game consoles) still used in the early 90's. I would except normally using a double buffered concept on a primary action field on the bottom layer, and using the top layer to produce a relatively static HUD for a game, this way not needing to re-render it in every pass. The Accelerator is also capable to perform well with page copying if needed, which may be useful for rendering on non-double buffered components (such as a mini-map on the HUD).
Other uses are of course also possible, such as a scrolling map with marking changes (soft sprites) for updating, or top layer sprites, but I am excepting the double-buffered concept to become the most used.
The release of this change set is still a bit away since although the specification might get finished very soon, I also need to update the emulator and the example set to go with it before letting it out.