Re: [pygame] pygame on pypy usable
Pretty cool, sir. Thank you. :) On 3/19/2018 2:19 AM, René Dudfield wrote: Hi, TLDR; I'm at the pypy sprint, and working through the remaining pygame-on-pypy-cpyext issues. https://youtu.be/WN1slc5O8os Surprisingly to me... it's already usable. That is pygame (same one that runs on cpython), works on pypy through its C extension API. pypy has good support for the CPython API (through a recompile) now. There was an issue with events stopping keyboard/mouse/etc from working. Lots of details in this issue describing the changes needed, so I hope other extensions encountering this will find it useful. https://github.com/pygame/pygame/issues/419 But now that's fixed, every pygame app I tried on it has worked. Why is this exciting? This is exciting to me because: * pure python code being fast on pypy(after warmup), also mixed with the fast bits in C/asm. * cpyext is getting faster in pypy. There is already work and discussion towards it being faster than CPython. * maintaining one pygame code base is easier than maintaining several (pygame cffi/ctypes/cython, ...). * with one code base it should be fast on both pygame, and pypy(in time). Here's our old pal solarwolf from early 2000s running on pypy. https://youtu.be/WN1slc5O8os Still lots of work to do (especially around PixelArray buffers and such). Then of course, there is the issue of binary wheels, so that `*pip install pygame*` works without needing to compile things from source. How is the speed? (when do we use this tool? Is it fast enough?) If your code is already quite well optimized, and not spending much time in python, you can't expect to see an improvement. However, if you are pushing boundaries in your python code, you can expect very good increases. Some examples where you can expect it to be faster: * if profiling and a pygame function (like blit) isn't at the top of the slow bits. * collision detection (if you aren't using fancy algorithms). * a pure python ray caster. * writing a music synthesizer in python python. Where it can be slower. * if you are going into C code for a lot of small operations. Like when using rect. For me, I'm interested mostly in this for a physics art project which was really slow, and also for a software music synth written in pure python. Even more interesting is running pypy as a separate process for these tasks, and run the gui process with CPython. ciao,
[pygame] pygame on pypy usable
Hi, TLDR; I'm at the pypy sprint, and working through the remaining pygame-on-pypy-cpyext issues. https://youtu.be/WN1slc5O8os Surprisingly to me... it's already usable. That is pygame (same one that runs on cpython), works on pypy through its C extension API. pypy has good support for the CPython API (through a recompile) now. There was an issue with events stopping keyboard/mouse/etc from working. Lots of details in this issue describing the changes needed, so I hope other extensions encountering this will find it useful. https://github.com/pygame/pygame/issues/419 But now that's fixed, every pygame app I tried on it has worked. Why is this exciting? This is exciting to me because: - pure python code being fast on pypy(after warmup), also mixed with the fast bits in C/asm. - cpyext is getting faster in pypy. There is already work and discussion towards it being faster than CPython. - maintaining one pygame code base is easier than maintaining several (pygame cffi/ctypes/cython, ...). - with one code base it should be fast on both pygame, and pypy(in time). Here's our old pal solarwolf from early 2000s running on pypy. https://youtu.be/WN1slc5O8os Still lots of work to do (especially around PixelArray buffers and such). Then of course, there is the issue of binary wheels, so that `*pip install pygame*` works without needing to compile things from source. How is the speed? (when do we use this tool? Is it fast enough?) If your code is already quite well optimized, and not spending much time in python, you can't expect to see an improvement. However, if you are pushing boundaries in your python code, you can expect very good increases. Some examples where you can expect it to be faster: - if profiling and a pygame function (like blit) isn't at the top of the slow bits. - collision detection (if you aren't using fancy algorithms). - a pure python ray caster. - writing a music synthesizer in python python. Where it can be slower. - if you are going into C code for a lot of small operations. Like when using rect. For me, I'm interested mostly in this for a physics art project which was really slow, and also for a software music synth written in pure python. Even more interesting is running pypy as a separate process for these tasks, and run the gui process with CPython. ciao,
Re: [SPAM: 6.600] Re: [pygame] Re: removing 'experimental' notice from pygame.math
I'll merge this in now. Consider it stable(ish).
[pygame] draw.aaline PR.
Hello, it seems draw.aaline only worked on RGBA 32bit surfaces, not ARGB 32bit surfaces. Often on Mac SDL chooses ARGB these days, so the lines were not working properly (the colors were mixed up). PR here: https://github.com/pygame/pygame/pull/418 Issue: https://github.com/pygame/pygame/issues/395 You might be interested to read it to learn a bit about how to do pixel manipulation in SDL C api. It still needs tests. I left the issue open with a 'low hanging fruit' and a 'help wanted' tag. Also, the issue is nicely filled out with a description of the problem, and even a test case (not in unittest format). So the issue is ready if anyone wants to https://www.pygame.org/wiki/Contribute There's a few of them prepared like this under the 'help wanted' tags. I've written a doc on how to write a unit test(with python stdlib), and how to write one for pygame. I'm waiting for a friend to review it first before adding it to the "Contribute" page. cheers,