Author Topic: Version 00.008.000 up: Parallel execution and Sprites  (Read 4687 times)


  • Global Moderator
  • Newbie
  • *****
  • Posts: 36
    • View Profile
    • Jubatian's blog
Version 00.008.000 up: Parallel execution and Sprites
« on: July 04, 2014, 09:36:10 AM »
Finally binaries for the newest version were packaged and posted on the main site.

Compared to the old package these contain quite radical changes, mainly on the ground how the graphics components work. The shortest summary of these would be parallel execution and sprite support.

The parallel execution refers to the Graphics Accelerator. It was there even in the first versions, and operated in parallel with the CPU, however this was quite limited. Now using a new component (Graphics FIFO) it is possible to queue many operations for the Accelerator, so the CPU no longer needs to wait for it while generating graphics. The Accelerator also underwent some changes to be more useful for it's common tasks.

Sprites were introduced as a redesign of the Graphics Display Generator, moving away from the layered concept. There are no true sprite support, however, only a line based command list support, which can combine a line from several sources, arbitrarily positioned on the line. This can be easily used to realize hardware sprites, and also other things.

In overall this part of RRPGE went more complex, but meanwhile the actual code sizes for the emulator decreased, since the overall changes removed some features which were not quite necessary, but were quite complicated.

As of now the provided binaries might be quite unstable, needing more testing, which I will do in the next weeks while designing some generic graphics libraries. There are less working examples since I am obsoleting those which related the old concepts (This is the layerkey example using the layered Display Generator, and the sprite example showing a way to render with the old graphics concepts. Their display could be reproduced, but the intentions underneath are obsolete).

The Block Blitter part of the Graphics Accelerator might still be simplified somewhat: I might remove pixel-precise source definition from it which is quite complex to realize. This was originally introduced to support precise clipping, which became not so critical with the new Graphics Display Generator, by which clipping problems may be covered up using proper display arrangement. In the original layered concept only precise clipping could realize certain types of graphics work flows which were necessary by the original overall concepts.