Hi there,

I love coding in Python and thus I have also used Pygame a lot. In general I love Pygame, because it works for the most part, and it's quite easy to use, and it runs on many platforms, including the Raspberry Pi.

What I don't like about Pygame is that it seems like it's impossible to create rock-solid frame rates, which might have to do with the fact that it's still based on SDL1 and it seems like there is no option to turn VSync on. Also, SDL1 is quite old now and I'd prefer something more modern for various reasons. But it would be cool if it would also run on a Raspberry Pi (which doesn't support full OpenGL, meaning some libraries won't be an option).

I've read about PySDL2, PySFML, also I've looked into Love2D which is of course Lua, but seems to be a widely used thing nowadays. But it's a bit hard to judge what's really well-supported and future-proof and so on. That's why I'm struggling a bit with deciding what to use in the future (or maybe just sticking to Pygame, despite its imperfections).

Any suggestions?

Oh maybe one additional piece of information, I am mostly developing 2D-retro-style games with blocky graphics.

Unless it's improved dramatically since I last looked at it, I have to agree that PyGame is pretty awful; just too slow for serious use. Pyglet is more of a low-level wrapper for OpenGL and a few other APIs than a game engine, isn't it?

Have you looked at the Python version of Cocos2d? I've not used it myself but I hear good things.

Hi there,

thanks for your replies! Well, I've looked into Pyglet but as far as I remember, it uses "the real OpenGL", while the Raspberry Pi only supports OpenGL ES, so Pyglet games won't run on the Raspberyr Pi, which is something I'd rather have in my feature list. I might be wrong but I think I remember it that way.

I haven't looked at Cocos2d yet, but I remember that it was quite well-known a few years ago. However, I just checked the specs and it seems like it's also based on Pyglet. I will have another look at my Raspberry Pi issue though, maybe it was something else.

@Julie.chan I also downloaded your SGE engine just now, well as far as it's Pygame-only it won't solve my problems of course. You said you also have an PySDL2 version in the works, so what is your opinion about PySDL2 vs Pygame? Would it make sense in general to move on to PySDL2 instead of Pygame? Is PySDL2 something "solid" or is it something someone created in his spare time but now abandoned it? It's hard to tell sometimes, from just looking at websites and so on.

Well the thing is, even if I use the "clock" functionality and try to make my code run at a stable 60 FPS, it sometimes has 59 FPS or 62 FPS or something like that. Apparently it's not possible to use VSync at all, neither on Linux nor on Windows. The code of the game itself is fast enough (without limitation it runs at 180 FPS or something like that), so that's not the reason here. Now the problem is, when there is a sprite moving smoothly from one side of the screen to the other (imagine a simple arcade-like game, nothing 3D or so), you will sometimes see it jitter around instead of floating smoothly one pixel at a time. And as far as I've read so far, there is no way to fix this when using Pygame, it simply has to be accepted.

Have you profiled? I highly recommend CProfiler if you haven't. Never optimize, or consider switching libraries until you have a consistent data backed narrative that supports your intuition.  A lot of the times in pygame applications I see a lot of time tends to go in to needlessly updating the entire surface every frame. Also, by default, I believe pygame uses a software based surface, which can be quite slow, so make sure when initializing it, you pass the appropriate arguments (pygame.HWSURFACE comes to mind) Take a look at this SO thread, and see if it applies in your case:

https://stackoverflow.com/questions/6395923/any-way-to-speed-up-python-and-pygame

TLDR; you can do some pretty intense stuff with PyGame, but there are performance traps that you'll want to be aware of, and profile for.

PyOpenGL is also actively maintained, and easy to pick up and run with if your express goal is to do only 2D with it. I won't feed you the party line however about using modern gl, and that if you use any legacy functionality you'll die of cancer in three years, and your girlfriend will dump you, but I do recommend it despite how easy it is to get legacy GL to do something initially.