From: mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Amigas are cool
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Mon, 27 Jul 1992 18:10:37 GMT

In <1992Jul27.140838.8012@news.iastate.edu> barrett@iastate.edu (Marc N Barrett) writes:
>   Besides, Inuition and graphics.library are limited to 8-bits for many of
>the same reasons that old MS-DOS and MAC programs will not run in a 32-bit 
>environment.  Many of the calls in graphics.library are to routines like 
>Write8Pixel and Read8Pixel; these routines use bytes, and not long-words, and
>cannot be adapted easily to graphics systems with more than 8 bitplanes.  About
>the only thing that Commodore can do is to add new routines like Write32Pixel
>and Read32Pixel that new programs can use, though this will not help old programs
>that use the old routines.  

OS2.0 introduced WritePixelArray8,WritePixelLine,ReadPixelArray8
and ReadPixelLine8 functions which work on 8bit vectors.
The vector elements are interpreted as _pen_ numbers which happen
to be useful on paletted displays. However, on a true or direct color
display you won't use 2**24 different pens which are mapped 1:1.
You'd rather use a software colormap that translates your smaller
pen numbers into the actual color used on the screen.

The generic WritePixel, ReadPixel and SetRast functions accept 32bit
quantities (although they currently only interpret the lower 8 bits).

Other routines use pen numbers selected with the different SetXPen
routines and which are 32bit quantities. Missing is the function that
sets the outline pen. This is currently a macro and thus is limited
to writing an 8bit quantity.

Some functions accept a binary mask to select bitplanes. Currently
only 8bit of the parameter are interpreted but the value is a
32bit quantity.

The functions to set palette values will need an update if the
depth of the palette entries changes from 12bits. Although they
get passed 32bit quantities you would like to extend the RGB
numbers to the fractional part. The LoadRGB4 routine has the same
problem since it asks for a 16bit palette entry.

Difficulties encountered so far:  the outline pen and finer resolution
for the color palette.

The largest problem when dealing with >8 bits per pixel is however
the Bitmap structure. You could simple extend the structure for
more plane pointers. But unfortunately this structure is embedded
in the screen structure and must be replaced by some more abstract
description of a bitmap.
This is also a requirement for bitmaps that aren't directly accessible
by the processor.
Programs that need to handle bitmaps with a depth > 8 would need to use
new functions to allocate opaque bitmap objects.

Intuition has no functions that are related to bitmap depth, but it uses
a private data structure to hold images. The PlanePick and PlaneOnOff
parameters in the structure limit depth to 8bit.
However, OS2.0 already introduced opaque Image objects which aren't limited
to any raw data description and thus can handle the second problem
(of having noaccessible graphics memory) as well. However, using the
old Image model doesn't harm anything.

Conclusion: there are a few cases where the graphics.library has architectural
8bit limitations and really nothing in intuition.library. This shows that
you, Marc, did try to sell us nonsense.

BTW, the limitation of the old Mac Quickdraw has been more dramatic.
And the 32bit environment missing in MS-DOS has, of course, nothing
to do with graphics, neither have the 32bit-clean apps on the Mac have
anything to do with 32bit Quickdraw except for the fact that a 32bit-clean
OS (System 7) was introduced at about the same time as 32bit Quickdraw.
However, you can use 32bit Quickdraw without being 32bit-clean which means
that you can handle an address space larger than 16 Megabytes.

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."