   Testing for colors in a surface
  So, I've got a surface loaded into memory from a .PNG file.  I've used copyrects to copy it to the back buffer and display it on screen, so I know that it's loading correctly.  Now, I want to compare individual pixels on the surface against a D3DCOLOR, using this function:bool compareColors(BYTE* ourBuffer, int cursor, D3DCOLOR ourColor) {BYTE blueComp, greenComp, redComp, alphaComp;blueComp = (BYTE) ourColor &  0x000000FF;greenComp = (BYTE) ourColor & 0x0000FF00;redComp = (BYTE) ourColor &   0x00FF0000;alphaComp = (BYTE) ourColor & 0xFF000000;BYTE compareto = *(ourBuffer+cursor);// compare Blue componentif((compareto & blueComp) == blueComp) {compareto = *(ourBuffer+cursor+1);// compare Green componentif((compareto & greenComp) == greenComp) {compareto = *(ourBuffer+cursor+2);// compare Red componentif((compareto & redComp) == redComp) {compareto = *(ourBuffer+cursor+3);// compare Alpha componentif((compareto & alphaComp) == alphaComp) {return true;}}}}return false;}The surface is always D3DFMT_A8R8G8B8.  I'm using DirectX 8.1, if that makes a difference.cursor is meant to represent the position within the BYTE* buffer where the first of the 4 bytes that make up the pixel I want to test are.  As of right now, it doesn't work.  I thought I had it working earlier when I bit-shifted the D3DCOLOR 8, 16, and 24 bytes to the right instead of trying to separate the D3DCOLOR its component bytes, but that turned out to erroneously return "true" in some cases.This may be a question better suited for the Beginner forum, as it's entirely possible that I'm making an elementary C++ programming error here.  It's been a while since I did any serious C++ coding, and I'm probably pretty rusty.  And, there might be an easier way to do this that I don't know about.   
  I don't see why you need to compare each color component separately. Why not cast to D3DCOLOR then compare that?bool compareColors(BYTE* ourBuffer, int cursor, D3DCOLOR ourColor) {D3DCOLOR compareto = (D3DCOLOR *)(ourBuffer + cursor);if(ourColor == compareto)return true;return false;};  Hmm... I had to change the first line toD3DCOLOR compareto = (D3DCOLOR) *(ourBuffer + cursor); to stop the compiler throwing an error about type conversion, but it still always returns false.Maybe trying to force a conversion to BYTE isn't working the way I expected?  I've tried bit-shifting the results of my AND operations like so:blueComp = (BYTE) ((ourColor &  0x000000FF) << 24);greenComp = (BYTE) ((ourColor & 0x0000FF00) << 16);redComp = (BYTE) ((ourColor &   0x00FF0000) << 8);alphaComp = (BYTE)(ourColor &   0xFF000000);and it hasn't worked.  I'm using VC++2008 Express as my IDE, if that makes a difference.[Edited by - Ludicrous Gibs on September 1, 2008 2:33:50 PM];Quote:Original post by Ludicrous GibsMaybe trying to force a conversion to BYTE isn't working the way I expected?  I've tried bit-shifting the results of my AND operations like so:blueComp = (BYTE) ((ourColor &  0x000000FF) << 24);greenComp = (BYTE) ((ourColor & 0x0000FF00) << 16);redComp = (BYTE) ((ourColor &   0x00FF0000) << 8);alphaComp = (BYTE)(ourColor &   0xFF000000);and it hasn't worked.That looks marginally better than your first attempt, but still wrong [smile]Bits move in the direction of the << or >> arrows. blueComp = (BYTE) ((ourColor &  0x000000FF) << 24)Will first grab the low 2 bytes from the colour, which is correct. It will then shift them 3 bytes towards the MSB, and then you'll cast it to an 8bit quantity which, by definition, is now 0.The idea is correct, but flip them around - 0x00FF0000 should be >> 16 for example.Also, step through your code using the debugger. Pull up the Windows Calculator and set it to scientific with digit grouping. You can then flick it between decimal/binary/hex representations and work through an example.Load up an all red image. Step through it and check that the incoming pixel is 0x000000FF (endianess could mess you up, is it 0xFF000000 maybe??). Manually perform all your bitwise operators. Ensure that your on-paper calculations match the state of your program. Put a breakpoint after decoding and verify that redComp = 255 which blueComp = greenComp = alphaComp = 0 (or possibly alphaComp = 255).I first wrote this sort of code about 10 years ago and have no idea how many 1000's of times I've done it since then. I still get "off by one" errors and occasionally mess up my endianess or my bitwise operators. Going back to first principles and stepping through the code has always revealed the solution very quickly for me. Challenge your own assumption and appreciate that you can't always solve this with static code analysis.hthJack   ;  I tried doing as you said, and it works now.  Thanks!Although, I probably could've just used the D3DCOLOR_ARGB() macro with the various buffer positions as arguments, and compared the result to the passed-in color instead.  Hooray for overthinking!Actually, I was overthinking another problem, that being the comparisons in the if statements. I should've been using a straight equality check to begin with.   ANDing the two operands and then doing an equality check like I did worked great... as long as one of the operands wasn't 0 or 255, which they frequently were.   ;Quote:Original post by Ludicrous GibsI tried doing as you said, and it works now.  Thanks!Although, I probably could've just used the D3DCOLOR_ARGB() macro with the various buffer positions as arguments, and compared the result to the passed-in color instead.  Hooray for overthinking!Actually, I was overthinking another problem, that being the comparisons in the if statements. I should've been using a straight equality check to begin with.   ANDing the two operands and then doing an equality check like I did worked great... as long as one of the operands wasn't 0 or 255, which they frequently were.I know you found a solution but I would like to comment about the logical 'and' you were using. If you used 'xor' and compared the result to zero that would determine if they are equal or not. :)   