HBITMAP Alpha

[AltPluzF4]

I'm trying to compare images, but the alpha is making the comparison fail (even if the rgb are correct)

	BITMAP large;
	GetObject(hScreen, sizeof(BITMAP), &large);
	int lBps = large.bmBitsPixel / 8;
	int lSize = large.bmHeight * large.bmWidth * lBps;
	BYTE *lBytes = new BYTE[lSize];
	GetBitmapBits(hScreen, lSize, lBytes);

Is what I'm using to get the bytes of the image.
I've been able to solve this by a cheap little hack:

	for (int z = 3; z < lSize-4; z+=4)
		lBytes[z] = 0;

However, I'm curious... what would be the best way to do this? I'm getting the HBITMAP via CreateCompatabileBitmap and BitBlt'ing the image to it with SRCCOPY.

Again, my problem has been solved by the simple for loop, and everything works fine. I'm just curious if there's a better method.

Thanks for any input.

[VladimirF]

... I'm just curious if there's a better method.

Better than what? You didn't show HOW you compare these images.

[AltPluzF4]

I was asking if there was a better way to remove the alpha from the image.

As far as comparing, I am using memcmp, while the loaded image is always 00 on the alpha of each pixel.

[VladimirF]

I was asking if there was a better way to remove the alpha from the image.

Got you. Sorry for misunderstanding.
Since 32-bit processors are oriented to work with 32-bit values (not bytes), it might be better to use int in your loop:

for(int* p = (int*)lBytes, int i = 0; i < lSize/4; ++i, ++p)
	*p &= 0x00ffffff;

(or something like that).

[VladimirF]

If you didn’t take my advise yet – don’t.
I have violated my own rule of not compiting with modern compilers in optimization.
Here is a Release (optimized for speed) build’s disassembly:

int main()
{
	size_t lSize = 100000000;
	unsigned char* lBytes = (unsigned char*)malloc(lSize);
00401000  push        5F5E100h 
00401005  call        dword ptr [__imp__malloc (4020A0h)] 
0040100B  add         esp,4 
	size_t i = 0;
0040100E  add         eax,3 
00401011  mov         ecx,17D7840h 
	for(int* p = (int*)lBytes; i < lSize/4; ++i, ++p)
		*p &= 0x00ffffff;
00401016  mov         byte ptr [eax],0 
00401019  add         eax,4 
0040101C  sub         ecx,1 
0040101F  jne         main+16h (401016h) 
	return 0;
00401021  xor         eax,eax 
}
00401023  ret

As you can see, the compiler turned my “clever” code into what you had at the beginning…
Well, that wasn’t as big a surprise as that there was no difference in the compiled code even when I enabled Streaming SIMD Extensions (/arch:SSE) or Streaming SIMD Extensions 2 (/arch:SSE2).
I was really hopping to see some interesting generated code