From: Andrew Apted <ajapted@netspace.net.au>
  To  : ggi-develop@eskimo.com
  Date: Fri, 17 Jul 1998 14:40:31 +1000

Re: New ggi_graphtype

Marcus writes:

>  > I think we should stick to the subscheme idea.  The values of subscheme
>  > can be arbitrary -- so long as they differentiate different modes at the
>  > same scheme + depth.  This way, graphtype == pixel format ==
>  > ggi_plb_common_setup == get/put buffer format.  Multible problems
>  > solved in one fell swoop.
>  
>  But I think ggi_plb_common_setup should go away too!

I don't :-).  
I mean the new graphtype (at least in my model) replaces it.

>  Now that we've agreed that the core libggi should
>  only support the RGB colormodel there are no "common"
>  or "uncommon" modes. There are only:
>  a) modes that can be described with red/gree/blue mask and byterev,

Yep.

>  b) modes that are indexed,

Yep.

>  c) and then there're modes that can't be described at all

Yep.  In other words, you could call them "uncommon" :-)

Also:
   d) text modes

   e) greyscale modes (although we can dead-easy emulate these using
      indexed modes).

>  Just having arbitrary values sucks, not just because
>  we'll have a lot of unneccesary switchstatements everywhere,
>  but because it will be a PITA to add new modes (unless ofcourse
>  we predefine all the hundreds of possible subschemes).
>  It would require a central "subscheme-authority" which obviously
>  wont do any good...

I'm not proposing that we define subschemes values as stand-alone
entities.  What I am proposing is to define *pixel formats* by filling
in the subscheme with different values.  Like this :

        pixel format         scheme    subscheme  access  depth

        sp1a8lbl             GT_CLUT          1      8      1
        sp1a8hbl             GT_CLUT          2      8      1
        
        sp2a8lpl             GT_CLUT          1      8      2
        sp2a8hpl             GT_CLUT          2      8      2
        
        sp4a8lnl             GT_CLUT          1      8      4
        sp4a8hnl             GT_CLUT          2      8      4
        
        sp8a8i8              GT_CLUT          1      8      8

        sp8a8k8              GT_GREYSCALE     1      8      8

        sp16a16r5g5b5A1      GT_TRUECOLOR     1     16     15
        sp16a16r5g5b5A1rev   GT_TRUECOLOR     2     16     15
        sp16a16b5g5r5A1      GT_TRUECOLOR     3     16     15
        sp16a16b5g5r5A1rev   GT_TRUECOLOR     4     16     15

        sp16a16r5g6b5        GT_TRUECOLOR     1     16     16
        sp16a16r5g6b5rev     GT_TRUECOLOR     2     16     16
        sp16a16b5g6r5        GT_TRUECOLOR     3     16     16
        sp16a16b5g6r5rev     GT_TRUECOLOR     4     16     16

        sp24a8b8g8r8         GT_TRUECOLOR     1     24     24
        sp24a8r8g8b8         GT_TRUECOLOR     2     24     24

        sp32a32b8g8r8A8      GT_TRUECOLOR     1     32     24
        sp32a32b8g8r8A8rev   GT_TRUECOLOR     2     32     24
        sp32a32r8g8b8A8      GT_TRUECOLOR     3     32     24
        sp32a32r8g8b8A8rev   GT_TRUECOLOR     4     32     24

        sp4a16t8             GT_TEXT          1     16      4
        sp4a16t8rev          GT_TEXT          2     16      4
        sp8a32t8             GT_TEXT          1     32      8
        sp8a32t8rev          GT_TEXT          2     32      8
	
[The central authority is just the header file where we define those
 values (like ggi/keyboard.h is the central authority for key values)].

>  To me the problem is having a bunch of switch-statements
>  with no real meaning. 

The whole graphtype has meaning (as above), and we switch on that
(whenever we have to).  I'm not suggesting we switch on the subscheme
values alone.

>  DirectBuffer should also use a red/gree/blue mask.

It does, look closer.  It's the array of pixelattributedescs (pad) at
the end of ggi_pixellinearbuffer.  Mmmmmm, that sure is a fun one to
decode... :-)

>  > >     The new members in ggi_mode would then be:
>  > >     ggi_pixel red_mask,
>  > >     ggi_pixel green_mask,
>  > >     ggi_pixel blue_mask,

Here's a nice idea I had earlier today: when scheme == GT_TRUECOLOR and
subscheme != GT_SUB_UNCOMMON, programs are allowed to use ggiMapColor()
to get the masks.  Something like this:

    red_mask   = ggiMapColor(vis, {0xffff, 0x0, 0x0});
    green_mask = ggiMapColor(vis, {0x0, 0xffff, 0x0});
    blue_mask  = ggiMapColor(vis, {0x0, 0x0, 0xffff});

That way, no extra API is needed at all.

>  > On modes < 8, "reverse bitorder" is the different between sp1a8lbl
>  > (low bit left) and sp1a8hbl (high bit left), for example.
>  
>  But there is no "left" or "right", except the physical layout on
>  the ramchip, and that will change as you rotate your computer. ;-)

Think screen image.  sp1a8lbl has the left-most pixel in bit #0 of each
byte, sp1a8hbl has the left-most pixel in bit #7 of each byte.  I could
draw a diagram if you like :->>.

Cheers,
_____________________________________________  ____
                                               \  /
  Andrew Apted   <andrew@ggi-project.org>       \/