From: Shawn Hargreaves 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: 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.