PyGame


I think I'm really the only person tracking this, and I'm tracking it sloooowwwwly (work + RL = fewer hours for hacking than I'd like - I'm currently trying to PND up BZFlag).


Presumably, loading Notaz's Updated SDL should make Pygame fly, but I keep forgetting about testing it.


But yeah, if you want, try loading the new SDL on your Pandora and try running BSA or something. It runs fine (but choppily, ~10fps) on the Pandora on the slow SDL (wo/HWA). If it runs faster after changing the SDL libraries, then awesome! However, ''that might not be the best test,'' as BSA doesn't use OpenGL mode or Hardware Surfaces, IIRC. Ardentryst might make a better test in that case.
 
Last edited by a moderator:
Nice I'll give that a go.


For reference btw, Bubbman 2 (another Pygame from that site) has been PND'd already although I do love BSA :)


Ardentryst is pretty sweet too. Definately worth PND'ing and I seriously appreciate the effort your putting in to track it...I basically bought my Pandora for Pygame ^_^


But now I learn C++ so maybe that's a better thing (Python is so much nicer tho!)
 
Last edited by a moderator:
Notaz's SDL is not going to make anything faster (unless it currently does software scaling). It adds Vsync, double buffering, and hardware scaling. No HWSURFACE, or anything else to improve performance (other than perhaps compiler flags).


The reason Pygame isn't very fast isn't that it's not optimized. It's the fact that it's doing software blitting to a high resolution screen using an interpreted language (Python is quite slow compared to C/C++) on a slow processor.


But I don't think that Pygame is the primary reason your game is slow. This game, also created in Pygame, runs at over 4 times the resolution than yours and has far more action on the screen. Yes it runs at a similar framerate. You may want to look at the algorithms used in your code. Better algorithms will do more for your performance than any 'optimization' ever will.
 
Last edited by a moderator:
Thanks Ian, I wasn't asking for my game specifically (though it'd be nice).


I have a lot of pygames I like but they aren't worth pnding up at the mo cos they're so slow.
 
richiz said:
Thanks Ian, I wasn't asking for my game specifically (though it'd be nice).


I have a lot of pygames I like but they aren't worth pnding up at the mo cos they're so slow.
Click to expand...
If you have code yourself, it would be very informative to get some performance numbers for how long it takes to flip the screen, and other SDL operations.


This is pretty simple in python and would help us see what the bottleneck is. I don't have a pandora yet so I can't test myself.


EDIT: Also there are things like psycho which might help you speed up some python-only code.
 
Last edited by a moderator:
j0n said:
EDIT: Also there are things like psycho which might help you speed up some python-only code.
Click to expand...
I should point out that Psyco is x86 only; I don't think it even supports x86_64, let alone ARM. Furthermore, I think it's mostly been superseded by PyPy (an alternative Python interpreter), though that isn't yet ready for regular use.


Pygame should not be bottlenecked much more than standard SDL is; Pygame is supposed to be a very thin wrapper around it. So richiz, you might be better off looking into the approaches used to improve performance. I think you mentioned that you didn't use dirty rects, which is really important. It's terribly inefficient to redraw the whole screen every frame.


But if you really need to squeeze extra performance out of Python, you can try Cython. It takes Python code and converts it to C, which can then be compiled. It also allows for type declarations to add extra speed. In one case, I got about 100x speedup with Cython, but that was for heavily array-based scientific work; I don't know how much benefit it would give in a game.
 
Yeah, the Robohell source isn't particularly optimized, and spends most of its time in display.flip and collision processing logic, at least that's what the version I profiled a while back did anyway.


Richiz did an awesome job writing a game from scratch, but could probably get a major speedup from using already invented wheels (or just a few days crawling the Pygame API documentation and investigating the sprite groups with collision detection).


EDIT: In addition to Cython, there's also PyPy which is a Python interpreter written in Python, showing how easy it is to make a research project in Python that dynamically optimizes itself to run significantly faster than an established project.


Tempel: Did you ever try Numpy? It's supposed to be significantly faster for scientific work (array processing).
 
Last edited by a moderator:
When I get around to it, I'll post a HWSURFACE demo that reports framerate differences with the option on and off. Though Will McGugan's OpenGL Test might be useful in the mean time along with his SubPixel Blitter


Typing on my Panda, so forgive the grammar.
 
myownlittlworld said:
EDIT: In addition to Cython, there's also PyPy which is a Python interpreter written in Python, showing how easy it is to make a research project in Python that dynamically optimizes itself to run significantly faster than an established project.
Click to expand...
Yeah, that's where the Psyco devs went. It's advancing really quickly, but isn't yet on par with CPython features (though it's must faster with JIT). Also, as far as I'm aware, it's currently x86 and x86_64 only, not ARM.

myownlittlworld said:
Tempel: Did you ever try Numpy? It's supposed to be significantly faster for scientific work (array processing).
Click to expand...
Yep, that's exactly what I was using. When used with proper typing in Cython, NumPy array operations can be hugely sped up, which was how I got that 100x speed increase. Typically, though, I don't need all that speed, and just use NumPy and SciPy from ordinary CPython.
 
Using Notaz's SDL binaries somewhat improve the Pygame framerates (while playing BSA). However, as Tempel notes, we still don't have hardware acceleration, which is probably where the biggest speedups will come from.
 
I had a good look at Richiz's game, and profiled it. It seems to me that his algorithms are fine, and the rendering / SDL part is quick. The slowness seems to be coming from python itself. It simply can't do 60fps of update and game logic even for a relatively simple game like that. Python runs much slower on ARM compared to x86 at the same clock speed, but I can see no good reason for this. Richiz' game wasn't heavy on floating point as far as I can see. It suggests to me that our python could use some optimization to run well on ARMv7.
 
Hey Swwam


I think the main slow downs on my game are text rendering. I have other PyGames I love like Bubbman 2 and Rose Ninja and they run a bit faster than mine.


I think it's because I rendered my sprites from text to image that is the major slow down.


It might be worth me going back at some point and re-writing it using images but I'm learning SDL now so trying to forget all the Python functions I learned. I'm quite liking C++ now I have a proper build environment so I can compile for the Pandora. Which I never bothered learning for Python :p


I'm not impressed with Python to be honest and I think SDL is better (though harder) in the long run due to the ability to compile for a ton of platforms. It would be nice to have PyGame working at a good speed though as there are a few very awesome PyGames :)
 
You must log in or register to reply here.

Similar threads

myownlittlworld
Pygame Framerates and HWSURFACE?
Replies
14
Views
13K
may88
may88
F
Top tip to free up some NAND
Replies
6
Views
1K
ibisum
ibisum
porg
Bug: File Browser Thunar - Trashing file crosses filesystem boundaries
Replies
8
Views
3K
porg
porg
S
U-Boot from ext2 formatted SD card fails.
Replies
8
Views
15K
Vorporeal
Vorporeal
Sephiroth
Python hardware support
Replies
6
Views
5K
chris_c
C
Back
Top