I'm currently using GetPixel to read a piece of the screen (actually, the background of a button) so it can be used for alpha-blending. GetPixel returns a COLORREF (DWORD)... but I suppose it would fail if the screen res were set to 16, 15, or 8. What would be a better way of capturing the screen bits, using GDI? I'd rather not use DirectX, to keep the app as backwardly compatible as possible. -------------- I've tried this sequence...

CreateCompatibleDC             // Create the compatible DC
CreateCompatibleBitmap         // Create a DDB
SelectObject                   // Select the DDB into the compatible DC
BitBlt                         // BitBlt the original DC to the compatible
GetBitmapBits                  // Get the bits from the DDB

...but there was no Bitmap selected into the original DC when the button's background was drawn. Should there be? Or is there a still better way (using GDI)? Thank you for your help and suggestions, and Greetings Chad

my_life:          nop          jmp my_life

GetPixel will do any necessary conversions. You'll get back a valid COLORREF regardless of the color depth of the screen.

I don't understand what you're asking in the second half of you post. That's the right sequence to blt to a local bitmap.

Quote:Original post by Anon Mike
GetPixel will do any necessary conversions. You'll get back a valid COLORREF regardless of the color depth of the screen.

I don't understand what you're asking in the second half of you post. That's the right sequence to blt to a local bitmap.

Good to know. MSDN does say "GetPixel" may not be supported by all devices, and then it goes on about checking "GetDeviceCaps" ... but the docs on GetDeviceCaps don't say anything about GetPixel.

The second part was a different approach to getting the screen bits.

If a DDB is selected into a Device Context before drawing a button, would that DDB contain the screen bits?

Thanks for your reply... & ++rate.


Chad

my_life:          nop          jmp my_life

Not necessarily, no. The representation of a compatible bitmap is up to the device, mostly. Color depth, type of device, and the alignment of the planets (i.e. developer whims) may all contribute to the format of a DDB. Since a device context is only guaranteed to be compatible with a particular device, it may not be compatible with the screen at all. So it isn't guaranteed that an arbitrary DC will hold screen-compatible device bitmaps, in general.

A device independent bitmap (DIB), however, should hold what you want. There's a family of API calls for mucking around with DIBs, and converting them from device-compatible bitmaps. Most notably, GetDIBits. GetDIBits will probably be a hair more efficient than batch operations with GetPixel if you're working with more than a handful of pixels.

Quote:Original post by ApochPiQ
Not necessarily, no. The representation of a compatible bitmap is up to the device, mostly. Color depth, type of device, and the alignment of the planets (i.e. developer whims) may all contribute to the format of a DDB. Since a device context is only guaranteed to be compatible with a particular device, it may not be compatible with the screen at all. So it isn't guaranteed that an arbitrary DC will hold screen-compatible device bitmaps, in general.

A device independent bitmap (DIB), however, should hold what you want. There's a family of API calls for mucking around with DIBs, and converting them from device-compatible bitmaps. Most notably, GetDIBits. GetDIBits will probably be a hair more efficient than batch operations with GetPixel if you're working with more than a handful of pixels.

Thank you for that thorough explanation...

And this looks like it answers questions about "GetPixel"
Google

Apparently, then, GetPixel always works on display devices...

And it really is just a handful of pixels... 256 at a time (16x16)


Chad

my_life:          nop          jmp my_life