Re: [pygame] Pygame blitting 8-bit surfaces doesn't ignore palettes?

[Greg Ewing]

Brian Madden wrote:
I'm 
seeing that that when blitting, Pygame will use the source surface's 
palette to get the 24-bit entry for each pixel, then look for that 
24-bit value in the destination surface's palette, and then write the 
8-bit integer value from the destination surface's palette as the pixel 
value in the destination surface.


I'm just curious as to whether this is this a bug, or is my 
understanding of how Pygame works with 8-bit surfaces not correct?


This behaviour is probably more or less what one wants most of the
time, so I'd say the bug, if any, is in the docs. ("More or less"
because it would be less surprising to use the nearest colour from
the destination palette if there isn't an exact match.)

> I have multiple surfaces each with their own palettes, and if I
blit a pixel value of "1" then I want it to be "1" on my destination 
surface regardless of what any of the palettes are! :)


I haven't tried it, but if the docs are to be believed, you should
be able to get this effect by creating a subsurface referencing the
original source surface, setting its palette to be the same as the
destination palette, and then blitting from that.

You might also be able to do something with surfarrays, but I'm
not sure.

--
Greg

[pygame] Pygame blitting 8-bit surfaces doesn't ignore palettes?

[Brian Madden]

Hi. I'm working with 8-bit surfaces in Python 2.7 with Pygame 1.9.2pre.
Everything I've read says that if I blit an 8-bit surface to another 8-bit
surface, Pygame will ignore both palettes and only copy each pixel's 8-bit
integer value from the source surface to the destination surface.

My experience so far is that this is *not* what happens. Rather, I'm seeing
that that when blitting, Pygame will use the source surface's palette to
get the 24-bit entry for each pixel, then look for that 24-bit value in the
destination surface's palette, and then write the 8-bit integer value from
the destination surface's palette as the pixel value in the destination
surface. If there are no matching 24-bit palette entries for the palettes
for both surfaces, then the resulting pixel's integer value in the
destination surface is 0.

I'm just curious as to whether this is this a bug, or is my understanding
of how Pygame works with 8-bit surfaces not correct? (In my case I have
multiple surfaces each with their own palettes, and if I blit a pixel value
of "1" then I want it to be "1" on my destination surface regardless of
what any of the palettes are! :)

Thanks everyone!
Brian

-- 
*Brian Madden*
Mission Pinball (blog  | twitter
 | MPF software framework
 | sample games
)

[pygame] Difference between Pygame 1.9.2pre, 1.9.2a0, 1.9.2...

[Brian Madden]

Hi Everyone,

I'm relatively new to Pygame after switching our project over from Pyglet.
There are several new features in Pygame 1.9.2 which we'd like to use, but
I'm confused about the various packages and the state of 1.9.2. For
example, what's the difference between 1.9.2 "pre" and "a0"?

Also it seems that the 1.9.2a0 builds available for download are over 3
years old. I wonder if there's an estimate of when 1.9.2 might move beyond
the alpha stage?

Finally, one of the things I'm interested in is the freetype support, but
it seems that that isn't in the 1.9.2.a0 build?

Or should I just be building all these from source?

Our application currently runs on Python 2.6 & 2.7. I'm fine to make 2.7 a
requirement if we need it for Pygame 2.7. (We're also considering moving to
Python 3 for the unicode support, so if Pygame 1.9.2 is better on Python 3
then that might help us make that decision.)

Anyway I've spent several hours googling and reading through the list about
this but unfortunately it's left me more confused than ever. I'm spending
about 40 hours a week working on our project and I'm happy to help out with
Pygame testing as needed.

Thanks in advance!
Brian

-- 
*Brian Madden*
Mission Pinball (blog  | twitter
 | MPF software framework
 | sample games
)