RRPGE forum
RRPGE system development => Current status => Topic started by: Jubatian on June 18, 2014, 08:50:19 PM
-
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.
-
A fresh implementation went up right a few minutes ago, of course alongside the appropriate specification. No examples yet, probably many bugs, but basic tests show it is functional.
An even further step was accomplished. The original post referred to the specification 00.006.000, which never got fully implemented to the end. I changed the Graphics Display Generator, advancing to 00.007.000, and the current implementation reflects this.
What's new with this Graphics Display Generator?
Well, most importantly, a kind of sprite support actually made it's way in RRPGE. Truly the rigid layered construct was changed to something more flexible, a line by line real time renderer, which can collect it's sources from line oriented command lists (still referred to as display lists). It can use up all the cycles on the bus previously available for the layered concept to fetch sources for the line and combine them onto an internal line buffer.
It is still not a sprite system, however, since it is line based, that is every display line has it's own configuration. It is however a lot faster to fill in these line configurations than working on display data, so it may well provide for a sprite system for who needs this, and many other things for other types of graphics generation.
I guess the graphics components are mostly complete with these, but further testing will of course show how it fares.