My spare time (at least the time I don't spend out) in the past months mostly went in polishing RRPGE further, and also exploring various basic algorithms and realizing them with libraries in the system. So both way around: for one, designing RRPGE itself, for an other, trying to use it. So some on what happened since.
A major concern after the initial release (in April) along working on various lesser problems (most particularly the input system) was how the graphics subsystem should be operating. The Accelerator was all right by itself, but it was very messy to utilize it properly working in parallel with the CPU. So a Graphics FIFO (something similar to Amiga's copper) was introduced along with weeding out many problems in other parts of the system. Just about the same time it dawned on me that the Graphics Display Generator itself may also work by an entirely different principle than before (just producing up to four independent layers). This principle is probably something unseen in real machines of the era, but likely possible. It gives sprites along with several other possibilities, however it is more demanding than the usual sprite systems (if it is just used for sprites).
Interestingly after going through all the size of the emulator binary went down with about 6 kilobytes (from 64 to 58 on 64 bits Linux, a healthy 10% decrease). Proves that the results of these works are even less complicated than what was there previously.
On the image above a simple mini intro is shown, which almost entirely works by what is offered by the new Graphics Display Generator, producing sprites. Depending on the configuration various amount of graphics elements may be shown on a line, here the limit is 15. Since there are no actual sprites, "multiplexing" is rather clean.
One of the first examples for RRPGE was the possibility of a rotozoomer, which was one of base the requirements for the Accelerator (which it fulfilled from the start). This is not just a simple-minded requirement: if it passes the rotozoomer test, the Accelerator is proved to be useful for both scaling and rotating (and also assisting simple texture blitting, although the memory bandwidth of this system is too low to utilize it well in the practice, and so it was not a primary goal).
I mostly do my tests in 640x400, 4bit (16 colours) since this is the most demanding graphics configuration of RRPGE. 320x200, 8bit (256 colours) is also possible, the Accelerator then performing at least two times faster (but in some operations, 4 times faster). Operating the Graphics Display Generator (sprites and such) is also half as much demanding. So if something works well in 640x400, it will definitely work all right with time to spare in good old 320x200.
Next things probably will be more tests with the Accelerator, maybe building an RPG game mock-up, exploring operating the graphics mostly by the Accelerator. Why an RPG game? Well, Cheetaan Legacy will be such a game, so why not!