[rescue] Weird Silicon Graphics o2 graphics issues

[Nathan Raymond]

On Thu, 2 Oct 2003, Andrew Weiss wrote:

> <cue partial ignorance>
> What I fail to understand is why have a colorspace (a reserved one) at
> all.  The app wants a color out of 256 possible values... send it to
> the screen at that spot (pixel).  I don't get the notion of firing up
> one app that grabs all these colors and then another app cannot use
> them while it is in the background...or may even generate errors about
> not enough colors available.  It's not as if one app physically sucks
> all the color into a pot and nobody else can have any...they're on the
> same screen...or is this a memory limitation whereby you are stepping
> into the same spot in the frame buffer's memory which needs to be
> protected?
> </partial ignorance>

8-bit color means that each pixel has a value of 0-255 (hence the 8 bits
of memory per pixel).  For performance reasons, the number 200 (hex C8)
typically means the same thing no matter where it is in video memory, and
how it would be displayed depends on the palette.  To have C8 mean
something different depending on where it is on the screen requires
additional computational time, and considering that screens refresh at
60Hz (or 60 interlaced frames per second back in the old days), it would
be a big performance hit to have dynamic regional palettes.

Remember, RAM used to be expensive, so once upon a time even 256KB of
dedicated VRAM was exotic.  A 1152x870 screen in 8-bit took up 979KB of
frame buffer memory.  It was also costly to impliment 24-bit graphics with
good speed even back in the late '80s because on some processor
architectures (such as the 68040) if you didn't store 24-bit (3 byte) data
in one longword (4 bytes) then each 24-bit pixel read would need three
separate memory accesses rather than just one, so it was better to waste
VRAM storage space and increase hardware costs for the sake of speed.

With the entire screen just a matrix of numbers, the numbers don't mean
anything on their own.  They have look up values in a color palette.  In
the case of a 24-bit display, it's almost always a fixed palette where a
given number always means the same color value, which greatly simplifies
things.  But in the case of 8-bit and lower bit depth graphics (like 4 and
2-bit) a given number could mean a different color depending on the color
palette (lookup table).  If, as you propose, you were to have per-window
or per-pixel color values, even in a custom 8-bit range, you'd need to
dynamically alter the palette as the scanline swept the screen, because
the offscreen bitmap would still only be 8-bit, and you would need some
way to store and access what palette was being referenced at different
points on the screen.  In fact, some platforms did this, but always at a
CPU performance hit, and always with caveats.

For instance the Amiga 500:

http://www.obsoletecomputermuseum.org/amiga500/

"The other special mode was called Hold And Modify, or HAM for short. HAM
mode let you have all 4096 colors on the screen at once. It performed this
trick by creating a 16 color palette. A pixel could be one of those 16
colors, or it could copy two color values from the pixel to its left and
define the third color. For example, a pixel could copy the red and green
values from its neighbor to the left, and define its own blue value. This
let you have all 4096 colors, but limited which colors could be next to
each other. Plus, changing one pixel could potentially change the color of
every pixel to the right of it. Despite these limitations, HAM mode screen
could be gorgeous, for beyond what either IBM or Mac machines could do.
HAM mode was used mainly for still screens, but a few games actually
utilized it."

And the Apple IIgs:

http://www.old-computers.com/museum/computer.asp?c=71

"320x200 with 3200 colors: in this mode, the CPU is used to swap palettes
into and out of video memory such that a separate 16 color palette can be
used on each of the 200 scan lines for 3200 possible colors. This mode is
often used for viewing graphics... 640x200 with 16 dithered colors: in
this mode, the pixels in the graphic screen are grouped into even and odd
columns. The even columns can have a palette of 4 pure colors out of a of
4096 possible. The odd columns can have a second palette of 4 pure colors.
The GS dithers the adjacent colors for 4x4=16 dithered colors. This mode
is widely used in productivity programs and also in Apple's Finder for the
GS... Combinations and variations: the Apple IIGS has scan line
interrupts. Part of the screen can be in 640x200 mode and part of it can
be in 20x200 resolution. Such split modes are sometimes used in paint
programs, where the menu bar is in 640x200 while the graphic is in
320x200."

--
Nathan Raymond