Hi, I have tested werlin on many computers, but just recently a friend of mine downloaded the newest demo and sent me a really bizarre screenshot.

Wierd Screen Shot (http://www.bantamcity.com/images/ColorProblem.jpg)

Has anyone ever seen this before? Could it be driver/DX issues or something with my code? I'm not sure what it could be. Any help would be appreciated. Anyone that wants to download the demo and compare to this would be of great help.

Thanks

I've seen many games where the color could end up reversed like that after tabbing out and back in... Don't have specific references off the top of my head, though.

Does your game run in 16-bit color? Is it possible that you are not checking for 5-5-5 vs. 5-6-5 color and therefore not properly converting your graphics when you load them into video memory on a few cards? (I can't remember which is the oddball...555 or 565)
-Scorpio

This is actually one of my first thoughts. I was compensating for 5.5.5 (the oddball), but I was thinking that I did not do it correctly, so i commented out the correction code (which should make everything seem greener on 5.5.5 video cards) and my friend had the same results (meaning his card is actually 5.6.5). I still think the issue may be related to this somehow... more testing will need to be done. Any other experiences with this?

Ok I just verified on his sytem... here's the weird part: I checked the pixel bit depth via dwRGBBitCount and it returns 16 (meaning 5.6.5 16 bit mode) but when I force it into mode 15 (5.5.5 16 bit mode) it everything but the alpha blending (uses a seperate filter) looks fine. ?!?!?:confused: :confused: How am I supposed to work with that?

Actually, the dwRGBBitCount field will report 16 bits to say that you are in 16bit color mode. It doesn't tell you 555 vs 565.

To check for that, you need to look at:

ddpfPixelFormat.dwRBitMask
ddpfPixelFormat.dwGBitMask
ddpfPixelFormat.dwBBitMask

These are the bit masks that tell you which color component goes in which bits. So, in theory, your code code support 444 if a video card required it.

My guess is your friend's card really does use 555 and that there is a related problem with your alpha routines.

Hope this helps,
-Scorpio

Indeed. When I was developing my ddraw drivers I discovered that in particular Matrox cards report themselves as full 16 bit but in fact almost always initialize to a 5:5:5 format. That said however, inspecting your buggy image doesn't really look like the tell-tale signs of a 5:5:5 card trying to render 5:6:5 images. The usual result in that situation is for blues to be unaffected while greens appear brighter/cyclic and for reds to look pretty much totally bizarre mixes of greens and reds. But in that image the role of the reds and blues appear to be reversed (reds look fairly normal while tiles with a lot of blue in them turrn shades of yellow)... and that confuses me since there shouldn't be any BGR-ordered 16 bit video modes.

What I'd recommend is to create a basic test image with a few rectangles filled with a couple shades of each color component and maybe a couple shades of yellow/teal/purple too. Something so you can get a clear picture of what each color value becomes when displayed on your friend's video card. Using that should allow you to figure out what's going on in a few minutes.

- Air

Why reinvent the wheel (and suffer under all kinds of weird bugs like this) when you can just use SDL (http://www.libsdl.org)?

Originally posted by Scorpio
Actually, the dwRGBBitCount field will report 16 bits to say that you are in 16bit color mode. It doesn't tell you 555 vs 565.

To check for that, you need to look at:

ddpfPixelFormat.dwRBitMask
ddpfPixelFormat.dwGBitMask
ddpfPixelFormat.dwBBitMask

These are the bit masks that tell you which color component goes in which bits. So, in theory, your code code support 444 if a video card required it.

My guess is your friend's card really does use 555 and that there is a related problem with your alpha routines.

Hope this helps,
-Scorpio

Wow, I had no idea I was using the wrong flag all this time. I just used the bit mask flags like you said and it works like a charm. Thanks!!