Bitmap headaches

Doesn''t look like a big-endian small-endian problem but what I suggest is to have your function print out to a file, the color value (hex is quite helpful in these cases) of a single pixel for every line down to the bottom and compare. It may even be that the png loading utility is not working right so many factors to consider. Good luck!

The most annoying thing about it is that the code and graphic works just fine on two of my computers. The third computer is my "minimum system requirements" computer. It''s a PII-300 with 64Mb RAM and a 1Mb video card. It''s that computer that generated the "incorrect" version of the graphic using the same code that my other two computers used to properly generate the graphic.

I checked to make sure that all of the systems were using 16-bit 5.6.5 pixel formats just in case. Is there anything else on the hardware level that I could try looking into to try and track down the difference in how the two images are being drawn?

-b-

I would double check for 565-mode, more older cards will have 555. The effect you''ve got there looks exactly like cut off bits.

Why not try and simply support both; you''ll save yourself a lot of headaches.

Yeah, I already check for 565 mode. I rewrote the PNG blitting code last night to do my own conversion from 24/32 bits to 16-bit 5.6.5 mode. I can verify that the values being copied to my DDSURFACE are correct, but when the surface gets blitted to the screen it still turns up the same results.

Does anyone out there have a log_file function for printing out the color values in a DDSURFACE per chance that I could use. Everytime I try and read information out of my DDSURFACE and log it to a file the program hangs.

-b-