Programming RRPGE all the way

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.

RRPGE mini intro
RRPGE mini intro
A mini intro for RRPGE

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.

RRPGE rotozoomer
RRPGE rotozoomer
Rotozoomer in RRPGE

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!

Referred artworks

  • RRPGE mini intro
  • RRPGE rotozoomer

External links


No comments so far. Be the first to comment!

Make a comment


  1. Please be polite (Leave all your trolls in their respective caves).
  2. If #1 fails, don't feed 'em. They bite.
  3. No links allowed. It won't pass. Neither chains. Use '(dot)' notation.
  4. Spam reeks.
  5. Text is (some day will be) formatted with Markdown.
  6. Your mail address is only visible to me: I understand you also don't like #4.
  7. The mail address you provide is also used to fetch your Gravatar.
  8. Danger! High voltage! Right between your "Post Comment" button and ground.
  9. Still want to comment? Go ahead! :)