Message-ID: From: Shawn Hargreaves 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) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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.