Looks good. Up to date binaries for 32 and 64 bit Windows are at
<http://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame>. There is one test
error and one Python 3.3 specific test failure. The examples seem work OK.
======================================================================
ERROR: SurfaceTypeTest.test_image_convert_bug_131
----------------------------------------------------------------------
Traceback (most recent call last):
File "X:\Python33\lib\site-packages\pygame\tests\surface_test.py",
line 678, in test_image_convert_bug_131
self.assertEqual(repr(im2.convert(32)), '<Surface(469x137x32 SW)>')
pygame.error: Empty destination palette
======================================================================
FAIL: FontTypeTest.test_metrics
----------------------------------------------------------------------
Traceback (most recent call last):
File "X:\Python33\lib\site-packages\pygame\tests\font_test.py", line
275, in test_metrics
self.assert_(len(bm) == 1 and bm[0] is None)
AssertionError: None
----------------------------------------------------------------------
Ran 665 tests in 57.157s
FAILED (failures=1, errors=1)
Christoph
On 6/19/2013 11:52 AM, Lenard Lindstrom wrote:
Hi,
I've been wanting to add new buffer protocol support to Pygame for
awhile now. It includes a release mechanism which is needed for
unlocking a surface when a buffer view is no longer needed. Previously,
the surface lock could only be released when its BufferProxy view was
garbage collected. It relied on the prompt object reclamation possible
with CPython's reference counting memory management. It is unworkable
with garbage collection based interpreters, such as PyPy. With the
introduction of Python 3.3, the new buffer protocol finally became
stable, and usable. Hopefully the new protocol will let Pygame interact
more cleanly with other Python packages.
The array interface --
http://http://docs.scipy.org/doc/numpy/reference/arrays.interface.html
-- remains for legacy reasons: Python 2.5 lacks new buffer support. I
find no reason to deprecate it, but also no need to maintain it beyond
bug fixes.
Since I only make 32bit builds on an Intel based machine, the code badly
needs testing in 64bit mode and with big-endian processors. So any help
in this area is appreciated. For anyone maintaining an existing Pygame
build, a complete rebuild from the config.py stage is necessary. The
code changes basically affect anything using NumPy.
Thanks, and enjoy,
Lenard Lindstrom
On 13-06-19 01:04 AM, René Dudfield wrote:
Hellos,
Lenard made some new buffer improvements to pygame. If anyone has
time to test it with their apps that would be cool. Just installing
it from source, and seeing if your app still works ok. Especially if
you use any of the buffer related code directly.
https://bitbucket.org/pygame/pygame/
