Jump to content
  • Advertisement
drwuro

Pygame - alternatives?

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement

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

Share this post


Link to post
Share on other sites

A bit of shameless self-promotion:

http://stellarengine.nongnu.org

The SGE Game Engine is designed to be re-implemented in other backends. Future-proofing was one reason I designed it that way, though another reason is so (eventually) you can just choose what backend you want to use with no change in code. Currently I only have a Pygame version (though it also supports Pygame-SDL2), but I do intend to make a version based on PySDL2 or Pyglet at some point.

On that note, Pyglet is another option you didn't mention. It uses OpenGL.

Edited by JulieMaru-chan

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

PySDL2 seems like a good thing to use in my opinion. It's made using ctypes, which is nice. As for whether it's actively developed still, the latest commit on GitHub was in May 2018, so I'd say it's a bit stalled at the moment. Nevertheless, it's libre, so anyone can take up the project and continue updating it if they wish to do so.

For what it's worth, by the way, Pygame is still being updated; the latest commit on the Pygame Git repo is from a couple days ago. I don't think there's an immediate issue of Pygame dying off, and it's been used so much that it's supported pretty much anywhere. For that reason my plans to make SGE implementations based on PySDL2 and Pyglet are actually on the backburner right now, and the main motivations would be to diversify and to have a version that works with PyPy (for a potential performance enhancement). I'll still be keeping the Pygame version as the main, reference implementation.

Actually, maybe I should have asked this earlier: what do you mean by "rock-solid frame rates"? Are you talking precision or speed?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

You mention vsync, which would suggest you're talking about tearing. But the problem you describe sounds more like the problem of using float positions, which is a different issue. That would be avoided by using only integer positions.

If you're talking about actual tearing though (when the top and bottom halves of the screen are in different positions), apparently Pyglet is better for preventing that. It's true that mimicking the refresh display can minimize tearing, but it's not possible to time everything exactly as you propose. Plus, it's very possible for someone to have a different refresh rate, e.g. 59 Hz is one I've seen in some computers I've used, so it's not a 100% reliable solution anyway.

Edited by Julie.chan

Share this post


Link to post
Share on other sites

You should have a look at HARFANG 3D, that is a full C++ engine with a Python API (just import harfang and you take it from there)
I'll let you have a look at the samples below and try it for yourself. Just feel free to contact me if you have any question, I'll be glad to help (I work for the company that develops HARFANG).

A mini "ace combat" game, all done in Python :

 

A snooker simulation, in full rigid body physics, all done in Python :

and a couple of code snippets, including VR :

https://github.com/harfang3d/vr-python-quickstart

Edited by Astrofra

Share this post


Link to post
Share on other sites

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.

 

Edited by markypooch

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!