Alpha-Transparency/Alpha-Blending in DirectX && DirectDraw

Started by
27 comments, last by Tony Chamblee 23 years, 12 months ago

Once again, could somebody give more detailed examples about getting the RGB values of a pixel in 24-bit color mode?

*Tony Chamblee*

Nucleus Software
*Tony Chamblee*
Liquid Flame Software
Advertisement
in 24bit mode, that means there are 3 bytes of info per color per pixel... In other words, three bytes will be right next to each other, each one dedicated solely to r, g, and b values.

I'm not sure on the exact code, but get a pointer to memory.. (this was just ripped from 16-bit code... dunno if 24bit will work like this or not).

BYTE *lpmem;
DDSURFACEDESC2 ddsd;

memset(&ddsd, 0, sizeof(ddsd));
ddsd.dwSize = sizeof(ddsd);
lpdds->Lock(NULL, &ddsd, DDLOCK_WAIT / DDLOCK_SURFACEMEMORYPTR, NULL);

// set the memory pitch
*lpitch = ddsd.lPitch >> 1;

// return pointer to surface
lpmem = ((BYTE *)ddsd.lpSurface);
I'm not sure about the byte... but maybe..

then store the first byte of info from the pointer, into the red value, then the next into the green and the next into the blue, at least i think RGB is the order.
so...
red =? lpmem;
lpmem++;
green = lpmem;
lpmem++
blue = lpmem;

I have no idea if this works or not... but It's just what seems like would be logical.

If anybody has the time to try this, please post your results and what you had to modify. I'm interested in seeing if this way is possible.

Edited by - iwasbiggs on 4/15/00 2:05:07 AM
___________________________Freeware development:ruinedsoft.com
I don''t think that''s right either, I''ve tried the code and can''t seem to get it to turn out right...can anyone offer any information?

*Tony Chamblee*

Nucleus Software
*Tony Chamblee*
Liquid Flame Software
I''m kind of interested in this BLTFX thing [hardware-accelerated alpha blending]. I ran DDCAPS and found something rather strange. Under Driver Caps Alpha is unchecked. But under HEL Caps [emulation], it is checked!

I''m running Windows 2000 with a Voodoo 3 2000 and DirectX 7a run-time/SDK. Of course Win2k has all those fancy transparency affects [via GDI]. Could that have anything to do with this?

Now the other thing, is that in the SDK docs, it doesn''t sound like this functionality is supported at all [even if the appropriate hardware is present?]:

"The IDirectDrawSurface7::Blt method performs a bit block transfer (blit). This method does not support z-buffering or alpha blending (see alpha channel) during blit operations."

"All DDBLT_ALPHA flag values. Not currently implemented."

There is always the D3D textured quads method, and the write-your-own blitter method... but I''m kind of wondering about this method. Anyone have any experience with it?

Nathan.


Changing a grouped RGB color into 3 individual colors can be done like this:
(not optimized at all)

//You have your color value, which, if you are doing
//alpha blending, you would get from the source and dest
//surfaces.
int Color = RGB( 200, 100, 50 );

Red = (Color & 16711680) / 65280;
Green = (Color & 65280) / 255;
Blue = (Color & 255)

//Red is now equal to 200, Green to 100, and Blue to 50

Hope that helped...
-Derek
I''m still looking for more specific information on 24-bit code. Does 24-bit color mode mean each color is stored in 8 bits? If so, I know how to get the color values from that. But some of the color values always seem to get messed up in the process. It makes a transparent blit when I run my routine to alpha-blend, but the colors are distorted somewhat.

-Tony-

*Tony Chamblee*
Liquid Flame Software
I''m still looking for more specific information on 24-bit code. Does 24-bit color mode mean each color is stored in 8 bits? If so, I know how to get the color values from that. But some of the color values always seem to get messed up in the process. It makes a transparent blit when I run my routine to alpha-blend, but the colors are distorted somewhat.

-Tony-

Derek: the number 65280 is wrong, it should be 65536.
First let me explain a little about the pixel format. It is 24bit, that means 3x 8bit. 8 bit is a byte. So there are 3 bytes, one byte for each color index: Red, Green and Blue.
A byte goes from 0-255.
You can do these 2 things to get the Red, Green, And blue bytes from a locked surface:
-Declare a pointer as unsigned char *. Point it to the DDSURFACEDESC::lpSurface member. Now you can read the videomemory, byte by byte. Because it is 24 bits each color is 3x.
-Read the 24 bits color value and extract the Red, Green and Blue values out of it. Blue is 1x, Green is 256x and Red is 65536x.
Here are two functions to make things more clear:
1st solution:void ReadRGBPixel(unsigned short x,unsigned short y,unsigned char &r,unsigned char &g,unsigned char &b){   unsigned char *screen;   screen=DDESC.lpSurface;   r=screen[y*yres*3+x*3];   g=screen[y*yres*3+x*3+1];   b=screen[y*yres*3+x*3+2];};2nd solution:void long2rgb(unsigned long rgbpixel,unsigned char &r,unsigned char &g,unsigned char &b){   r=rgbpixel>>16;   g=rgbpixel%65536>>8;   b=rgbpixel%256;}; 


Edited by - bosjoh on 4/23/00 3:06:38 PM
Tony, for really indepth info on bitmaps (and practically any other file format for that matter) go to www.wotsit.org -- it's one of the best resources for programmers on the net, if you really like getting into the nuts and bolts of things. Good luck, and happy coding



while( strcmp(reply,flame) )    followThread(); 


random-nomad

Edited by - random-nomad on 4/23/00 5:54:58 PM

This topic is closed to new replies.

Advertisement