SCI/FreeSCI/Graphics
The graphics subsystem
Original document by Christoph Reichenbach
Introduction
Up until version 0.3.0, FreeSCI used a graphics subsystem which used per-pixel operations on three 320x200 8 bit buffers. This concept, while being simple to implement for driver writers, proved to have several disadvantages:
- Non-native memory layout: Using a fixed 8bpp visual buffer meant that, for each update, all graphics would have to be translated to the graphics driver's native format, unless it already was running in 8bpp.
- No use of accellerated drawing functions: Many of the targetted graphics drivers supported hardware-accelerated drawing of rectangles or lines; this could not be taken advantage of, due to the per-pixel access.
- Scalability moved to the drivers: Each driver would have to take care of magnifying the resulting picture by itself (if it wanted to support it at all), since the base buffer was at a fixed size.
- Manual graphics buffer access: This was in fact used in many places, making it hard to keep track of modifications, which, in turn, would have inhibited attempts to track modifications of the visual buffer. However, without those, either each drawing operation would have enforce an update, causing flickering in the general case, or the full screen would have to be re-drawn each time (which was what actually was done), resulting in major performance penalites, especially for remote displays.
Combined with some cases of code rot, these problems suggested a re-write of the complete graphics subsystem, and a more modular re-design in preparation for supporting later revisions of SCI (and, possibly, related engines such as AGI).
This documentation section will describe the architecture and functionality of the new graphics subsystem, which has been in operation since FreeSCI 0.3.1. I will start by giving a general overview of the various components involved and how they interact, and then give a more detailed description of each of those components in sequence.