delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/01/18/17:14:33

Message-ID: <F77915E7F086D31197F4009027CC81C91CC67C@probe-2.as-london.acclaim.com>
From: Shawn Hargreaves <SHargreaves AT acclaimstudios DOT co DOT uk>
To: djgpp AT delorie DOT com
Subject: Re: Calculating transparent pixels in Allegro
Date: Tue, 18 Jan 2000 17:30:33 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id MAA01857
Reply-To: djgpp AT delorie DOT com

Jarkko Kähkönen writes:
> And I have a program, which calc transparency of about 16 000 
> pixels in one frame.:)

This is a slow operation. I'm afraid there is no trivial solution
to make it faster: you are trying to do a lot of work there, and it
will take time!

I would suggest using Allegro translucency functions, though 
(set_trans_blender(), set_drawing_mode(DRAW_MODE_TRANS, ...), etc)
at least to compare with the performance of your own versions:
the Allegro code uses a few quite non-obvious speedup tricks, eg.
the parallel interpolations in colblend.c (eg. the _blender_trans16
function).

> If I use getpixel, getr16, getg16 and getb16 and some other 
> functions to get transparent color between two colors, it is too 
> slow. I use 640x480/16bit mode.

Step 1: make sure you are doing these calculations on a memory bitmap
rather than directly to the screen. Reading images from video memory
is very slow on most hardware.

Step 2: don't use getpixel() in time-critical code. See the "direct
access to video memory" section in the docs for info about how to
access bitmap contents more efficiently.

Step 3: split up the color values yourself rather than using the 
getr()/getg() functions. But be careful! I wouldn't normally suggest
doing this (those routines aren't _all_ that slow, and doing it 
yourself is a great way to shoot yourself in the foot if you get it
wrong :-) but where speed is absolutely critical, it's worth avoiding
the overhead of having the check the shift variables to find out the
current pixel format. Allegro requires that 15 bit modes always use
a 5.5.5 color layout, and 16 bit always be 5.6.5, but it's possible
that the colors could be in either RGB or BGR order depending on
your hardware. Fortunately this doesn't affect interpolation code,
though, as long as you design it carefully, as you can do the 
interpolation regardless of pixel orientation as long as you make sure
that both your inputs are in the same layout, no matter whether that
is RGB or BGR.

Step 4: if you split the bits of a 15 or 16 bit pixel to different
locations within a 32 bit value, you can linearly interpolate all
three of the RGB values with a single multiply, and then pack the
result back into the original format with just a few bit twiddles.
Likewise 24 bit interpolation can be done with just two 32 bit
multiplies. See the Allegro colblend.c file for an example
(that code is by Cloud Wu and Burton Radons. I didn't come up with
it myself :-)


	Shawn Hargreaves.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019