From: Marcus Sundberg <e94_msu@e.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Fri, 07 Aug 1998 10:51:06 +0200

Re: ggiGetPixelFormat and proposed new DirectBuffer scheme

Andrew Apted wrote:
> 
> Marcus writes:
> 
> >  Anyway I suggest we add
> >  #define GGI_BYTEREV16(x) ((x) = (x)<<8 | (x)>>8)
> >  #define GGI_BYTEREV32(x) ((x) = ((x)<<24 | (x)>>24) | \
> >                       (((x)<<8 & 0xff<<16) | ((x)>>8 & 0xff<<8))
> 
> I would rather they were just:
> 
>   #define GGI_BYTEREV16(x) ((x)<<8 | (x)>>8)
>   #define GGI_BYTEREV32(x) (((x)<<24 | (x)>>24) | \
>                         (((x)<<8 & 0xff<<16) | ((x)>>8 & 0xff<<8))
> 
> without the '='.  Proggies can always do "blah = GGI_BYTEREV(blah)"
> (and a good compiler should still be able to optimize that case, even if
> we make them ASM inlines).

Good point. Actually the reason I added the '=' in the first place was
to make gcc -S produce something out of my testing-code. ;-)

Btw, someone that knows what these instructions:
ror ax, 8
ror eax, 16
ror ax, 8
does exactly should try to write C-code for GGI_BYTEREV32(x) that will
be compiled into those three instructions.
If it's possible gcc should hopefully be able to compile it into the
equivalent on other processors that we don't have assembly inlines
for.

> >  > Taking all this into account, the subschemes would now be :
> >  >
> >  >     #define GT_SUBSCHEME_STANDARD         (0x80 << GT_SUBSCHEME_SHIFT)
> >  >
> >  >     #define GT_SUBSCHEME_REVERSE_ENDIAN   (0x01 << GT_SUBSCHEME_SHIFT)
> >  >     #define GT_SUBSCHEME_HIGHBIT_RIGHT    (0x02 << GT_SUBSCHEME_SHIFT)
> >  >     #define GT_SUBSCHEME_PACKED_GETPUT    (0x04 << GT_SUBSCHEME_SHIFT)
> >  >
> >  > when GT_SUBSCHEME_STANDARD is not set, then the mode is something
> >  > unusual and encoding pixels and get/put buffers is not possible.
> >  > (and 0 is GT_AUTO of course).
> >
> >  get/put buffers are always possible (as long as the display has
> >  the notion of pixels at all ;) but you have to use
> >  ggiMapColor/ggiUnmapPixel to encode/decode them if
> >  GT_SUBSCHEME_STANDARD isn't set. Maybe that's what you meant?
> 
> Yeah, the *encoding* of the buffers has to go through
> ggiMapColor/ggiUnmapPixel when GT_SUBSCHEME_STANDARD is not set.
> 
> (It probably will be set 99.99% of the time, but it will come in handy
> for anything really unusual.  HAM6 comes to mind).

Argh! Why did you have to mention HAM here? ;-)
For HAM it will actually not be possible to use MapColor/UnmapPixel
at all, because the color a HAM pixel represents is based on adjacent
pixels to the left of it as well as the pixel itself, IIRC.
But PackPixels/UnpackPixels should be possible, with the limitation
that the first pixel in the array is assumed to be the leftmost pixel
in a horizontal scanline... But considering how common HAM is these
days I wouldn't worry too much about this.

Ok, it seems we have most things straightened out now.
I know Andy had some comments on my original posting, and it
seems he left for the US before he got my reply to them.

I definitely don't want to go behind his back while he's away,
but as he will be gone for four weeks I do think it's better
that we implement and debug what we have agreed on know,
than just sitting and doing nothing to libggi for a month.
Then when Andy gets back we can discuss it and change the things
he disagrees with.

Anyway I've already started implementing this in my local CVS
tree, and I hope to commit something that at least partly
works tonight or tomorrow, so that more people can help in
fixing the targets.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |      E-Mail: e94_msu@e.kth.se