Hi René,The blit bug is with _numericsurfarray.c, the old surfarray module, so has been around for awhile. It somehow found its way into _numpysurfarray.py as well. I have only tried it with 3d arrays so far. It doesn't just ignore the destination surface's alpha, it resets it.
I found the bug while fixing a NumPy specific bug. After looking at blit_array in _numpysurfarray.py I figured it was easier to just reuse the C version for Numeric. I wrote a new extension module where blit_array is a generic array function that uses the array interface. Other than setting alpha to zero it appears to work. I will give it a good workout with the unit tests before committing it, of course. It's not too difficult to adapt Numeric code for the array interface, so maybe array_colorkey can go their as well.
As for 24bit surfaces in general I've noticed the BLEND_ options for blit and fill don't work correctly. I will add some unit tests to expose the problem.
Lenard. René Dudfield wrote:
I don't think it should be 0. That means it's not visible, and contradicts the convention as you say. I'm not sure if it has always been like that, or if it changed with the 1.8 changes to surfarray? ps. I think there might be a bug with 24bit numpy arrays with surfarray in general? I think I came across a bug the other day... but not sure. If I find the code where I thought it was happening, I'll turn it into a test. cu, On Tue, Jan 20, 2009 at 9:49 AM, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:Hi, I've been looking at bug 24 at http://pygame.motherhamster.org/bugzilla regarding blit_array and I found something unusual. When blitting to a 32 bit SRCALPHA surface the alpha is set 0. This contradicts the convention of a default alpha of 255. So what do I do? I can leave it that way for both Numeric and NumPy arrays, change it for NumPy only or change it for both array types. I'm inclined to change it for NumPy only. Is there any reason alpha should be zero? Lenard -- Lenard Lindstrom <len-l@xxxxxxxxx>
-- Lenard Lindstrom <len-l@xxxxxxxxx>