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
<[EMAIL PROTECTED]>
