8bpp surface blitting looses colors

Issue #32 resolved
René Dudfield created an issue

== 3TATUK, 2009-04-25 01:59:13 -0700

{{{ The attached code will produce ten 64x64 blocks of color, the first nine being: white, white/black, red, orange, yellow, green, blue, indigo, and violet the white comes from the background screen being filled with white, so the first and second blocks are really: transparent and transparent/black

the first two color entries in the palette are both black, but index 0 is used as the color key.

When blitting image1 (the transparent/black) one to special_image surface.. basically, all pixel values of '\x01' are converted to '\x00' because it does an index lookup or some type of bug.

Basically the desired results are the last block to look just like the second (transparent/black) block via a blit() copy. I know this can easily be done with non-8bpp screen/surfaces, but I 8bpp still exists and should work properly. (My project requires it specifically, also)

You can see what is happening to the pixel data by writing the following two objects out to files and viewing with a hex editor (like i said all '\x01' become '\x00' (when they should be identical, in my opinion):

pygame.image.tostring( image1 ) pygame.image.tostring( special_image) }}}

== 3TATUK, 2009-04-25 01:59:50 -0700

{{{ Created attachment 21 colors lost }}}

Attachments: [[http://www.pygame.org/old_bug_attachments/21/example.py| example.py]]

== 3TATUK, 2009-04-25 02:45:35 -0700

{{{ my second attachment shows something someone figured out to make it work, although it's very hackish and a workaround.. not really making any sense and i can't understand what's happening but take a look }}}

== 3TATUK, 2009-04-25 02:46:22 -0700

{{{ Created attachment 22 hackish workaround }}}

Attachments: [[http://www.pygame.org/old_bug_attachments/22/example2.py| example2.py]]

== Thorbrian, 2009-04-26 12:21:47 -0700

{{{ Honestly, I don't understand what you are trying to achieve with this example.

However, it looks like the core of the issue here is that you have duplicate color entries in your palette, and you don't like that pygame is picking to represent colors that match that duplicate entry in your destination pixels as the first entry in the palette.

That behavior is not a bug - it's perfectly appropriate for a palette-based system. If you have duplicate color entries in your palette, you've made it impossible to practically distinguish one entry from the next, and you have to expect stuff like this to happen. I'm closing this as not a bug.

My recommendation would be to make every color entry in your palette distinct. }}}

Comments (0)

  1. Log in to comment