From: mert0407 AT sable DOT ox DOT ac DOT uk (George Foot) Newsgroups: comp.os.msdos.djgpp Subject: Re: Ideas for truecolor Allegro Date: Mon, 24 Mar 1997 22:28:20 GMT Organization: Oxford University Lines: 31 Message-ID: <3336fd83.1361114@news.easynet.co.uk> References: <1 DOT 5 DOT 4 DOT 16 DOT 19970324013129 DOT 1c6f2da4 AT mailhost DOT sm DOT ic DOT ac DOT uk> NNTP-Posting-Host: foot.easynet.co.uk To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp On Mon, 24 Mar 1997 01:32:11 GMT, Paul Dixon

wrote: >As to the comment about having to clear out these bits before passing to the >video hardware, surely if the transparency bit is set you WONT be passing >the colour to the video hardware anyway - so zeroing is not an issue! It is; Allegro's basic blitting routine (blit) doesn't support transparency. The transparency-capable version is draw_sprite. I think Shawn's point was that the blit routine is slightly faster at present, since it just copies strings of bytes to the video memory without conversion, but if he uses transparency bits these would need stripping, slowing down the process. I don't think this is really a problem, though; a simple solution would be to add a field to the BITMAP struct which states whether the bitmap contains any transparent areas. On blitting, if this is zero, call a simpler routine which copies the colours to video memory verbatim; if not, call a different routine which strips out the transparency bits first. In drawsprite, of course, the transparency bits must be read anyway to decide whether or not to draw the pixel. >if needed support 16 bit but with reduced support for transparency features. I think this extra field in the BITMAP struct could allow for this in any bitmap, no matter how many colours, without a significant loss in performance. Translucency will be really simple in high colour modes :) -- George Foot