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 <p DOT dixon AT ic DOT ac DOT uk> 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

- Raw text -