[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] blit anomalies in pygame 1.8.1release (2)



Hello claudio,

claudio canepa wrote:
Opps, now really with the test files.
Two (unrelated) anomalies in pygame.Surface.blit(), bugs or what ?

Tests in windows XP + sp2
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32
pygame 1.8.1release ( installed from pygame-1.8.1release.win32-py2.4.msi )

1. The pygame documentation and help(pygame.Surface.blit) tells
Surface.blit(source, dest, area=None, special_flags = 0): return Rect

but
surf.blit(sf2,(0,0),special_flags = op)

crashes with traceback:
[...]
  File "F:\newcode\_minitest\pygame blit\eblit.py", line 23, in blend
    surf.blit(sf2,(0,0),special_flags = op) # crash
TypeError: blit() takes no keyword arguments

Replacing with:
surf.blit(sf2,(0,0),None,op)
there is no crash.

On the other side, dst1.blit(src1, (0,0)) is acceptable.

Looks like a bug or that the real signature is
Surface.blit(source, dest, *args ): return Rect ?


( eblit.py demoes this problem )

The documentation is vague on this point. The argument names are descriptive only in most cases. The actual arguments are strictly positional. While technically the argument signature for Surface.blit is (*args), this is also misleading as blit has only fixed aguments. Such documenting practices also show up in Python builtins:

>>> help(pow)

Help on built-in function pow in module __builtin__:

pow(...)
   pow(x, y[, z]) -> number

   With two arguments, equivalent to x**y.  With three arguments,
   equivalent to (x**y) % z, but may be more efficient (e.g. for longs).

>>> pow(y=2, x=8)
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
TypeError: pow() takes no keyword arguments


Keyword support in Pygame's C code is quit patchy. For instance only two Surface methods take keywords:

>>> import pygame
>>> s = pygame.Surface(depth=32, size=(10,10), flags=0)
>>> s.get_bounding_rect(min_alpha=128)
<rect(0, 0, 10, 10)>

pygame.mixer.play and the PixelArray methods also accept keywords. Maybe some day everything else will too.

2. When blitting (with no blend flags) an opaque pixel ( alpha channel at 255 ) over any other pixel, seems natural that the resulting color be the src color. (opaque is opaque, right ?). In most cases pygame is off by one, by example:
.   dst is filled with (x,0,0,128)
.   src is filled with (0,z,0,255)
. dst.blit(src,(0,0)) will be filled with ( 0, z-1, 0, 255)
( minusblit.py demoes this )


Thanks for bringing it to our attention. This was a known bug in Pygame 1.7 and was fixed previous to Pygame 1.8. Apparently the bug was reintroduced in an attempt to optimize the code. I will repair it.

--
Lenard Lindstrom
<len-l@xxxxxxxxx>