From:	Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Ideas for truecolor Allegro
Date:	Sat, 22 Mar 1997 13:54:41 +0000
Organization:	None
Distribution:	world
Message-ID:	<NwJA7NAhS+MzEw2p@talula.demon.co.uk>
NNTP-Posting-Host:	talula.demon.co.uk
MIME-Version:	1.0
Lines:	73
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

My apologies for this relatively off-topic posting: it was the only way
I could think of to contact a large number of Allegro users. Please
reply to me privately rather than to the newsgroup.

Anyway. In the near future, Allegro is going to start learning about
truecolor video modes, and there are several design issues that need to
be decided before I start writing code. I've decided how I think it
should be done, but I thought it would be a good idea to see if anyone
violently disagrees with how I want to do things, or has any better idea
to suggest...

Which modes to support? Currently I'm thinking of 15 bit (5.5.5 RGB and
BGR), 16 bit (5.6.5 RGB and BGR), and 32 bit (8.8.8 RGB and BGR). The
VESA standard allows many other layouts for the RGB values, which will
be supported by everything but the translucency and gouraud shading
routines (for those I have to write custom code for every pixel format,
so I need to limit it to a few known combinations). I'm not aware of any
cards that use formats other than those six: please let me know if there
is any such hardware!

I'm also not planning on including support for packed pixel 24 bit
modes, because writing routines to deal with misaligned pixels is a huge
pain, and would be very slow in any case. If this prospect fills you
with horror, mail me and I _might_ reconsider (or I might just tell you
to go implement it yourself :-)

How to handle combinations of various color depths? As a general rule
people ought not to mix 8, 16, and 32 bit images, as converting from one
to the other is quite an expensive operation. But if they do, how much
of it should be handled automatically? My feeling is that you should be
able to blit from any image onto any other image, but that functions
like draw_sprite() and stretch_blit() should require both bitmaps to be
in the same format. Is this reasonable?

The biggest question is how to mark transparent pixels for the masked
sprite drawing routines. I can see various possibilities:

- Use color zero as with the 256 color code. IMHO a bad idea, since 
  there would then be no way to draw true black pixels in a masked 
  sprite.

- Use an off-black shade, eg. 1.1.1. Also not great, as such colors are 
  prone to rounding errors during conversion between 15/16/24 bit 
  formats, and a lot of image manipulation programs are liable to dither 
  them into something else.

- Use a 'useless' color like bright pink (maximum red and blue, zero 
  green). This would prevent the color from being used in masked 
  sprites, but who needs to draw pink anyway? :-)

- Let the user define the marker color. This would be slower, as the 
  tests would have to use a variable rather than an immediate value in 
  the comparison...

- Use the spare bits of the 15 and 32 bit pixel formats as markers. This 
  would allow the full range of colors to be used in the image, but 
  there is no way to draw such pixels in most paint programs, and it 
  wouldn't work for 16 bit modes. Also, the VESA standard requires that 
  these spare bits must be set to zero (and I have a feeling that some 
  hardware does actually use them to enable special features), so the 
  drawing code would have to mask off these values after testing them, 
  which would be a significant performance hit.

My feeling is that bright pink is the best option: it's not an important
color, can be easily drawn in any pain program, and if you really want
some pink on your screen you can always use one of the non-masking
drawing routines. Does this meet with general approval, or does anyone
have any better ideas?


--
Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
Beauty is a French phonetic corruption of a short cloth neck ornament.

- Raw text -