I'm starting to work on a 2D scrolling shoot-em-up game, and I was wondering if pygame is suitable. I would like to hit close to 60 fps while animating a scrolling background with hundreds of sprites (mostly bullets, of course); is this feasible with pygame? From what I've read, I'm leaning toward no, but I'd like another opinion from someone with more experience with pygame.
I'm also looking at using PyOpenGL with pygame, but I have absolutely no experience with OpenGL. Will OpenGL work better in this case than native pygame graphics, and are there any good tutorials for OpenGL/PyOpenGL/using PyOpenGL with pygame?
Pygame is as good as they get for 2D CPU graphics. All the graphics is implemented in C, (PyGame wraps SDL) so the code is nearly as fast as an equivalent C software renderer.
That said, it's still (basically) a software renderer, and there's this interesting device in every modern computer called a GPU which is designed to do that. PyOpenGL/OpenGL will take advantage of it, so yes, absolutely PyOpenGL will render faster than PyGame.
Bottom line:
PyGame is fast, but not as fast as PyOpenGL. For hundreds of onscreen sprites, that will mainly be a logic problem (Python logic is slow, even by interpreted language standards). Rewriting it in SDL would make it faster (because C/C++ is faster than Python). You could also use PyOpenGL, which I predict in this case would improve performance significantly, though not dramatically (but it's much harder to use).
Like I said, though, it will be primarily a logic issue, I think. There is something to be said for using PyOpenGL, but as they say, the greatest optimization you will ever make is when your code works for the first time.
Pygame is the best solution for 2D games in python according to me. You can save Surfaces uses its optimized Sprites animation, so I think it's the fastest solution : as for development process than for code execution.
Related
How could I make something simple like for example crosshair for FPS game (not actually going to do that, just took this as an example). Or how can I set color for some pixels on screen, or something similar. What would be the best way to approach this problem?
You can use OpenCV, that is one of the most useful Computer Vision libraries for Python. You can do whatever you want with images, screencaptures, videos, etc.
But I believe that some prior experience with NumPy library is needed, since OpenCV is heavily dependent on it.
I am a godot user and a Python user. In pygame, in a simple game like pong, I had an average of 55-60 FPS in fullscreen. In addition, when ported to Kivy, I had an average FPS of 60-70FPS. But when I coded this in Godot, and got an average FPS of 180-200 in the viewport, while profiling! My program was extremely similar in both, and I wasn't static typing at all in Godot. Why is pygame so slow and is there anyway I can make it faster?
Godot is using OpenGL ES for drawing to the window. PyGame is based on SDL, which does not use hardware graphics primitives at all. You could also port your game to Kivy, which supports OpenGL ES too.
In terms of pushing pixels to the screen, graphics being drawn with a CPU Vs running on GPU is not a contest the CPU can ever win. That said, for a whole lot of game styles, PyGame is fast enough. There is absolutely no point updating the screen faster than the monitor is refreshing.
I would expect a basic Pong in PyGame to always run at full-FPS. On a huge high-DPI display, maybe even erasing the background is enough of a pixel-load to drop the FPS.
I am making a tile based game, and the map needs to be rendered every frame. Right now, each tile is 32X32, and the visible map is 28X28 tiles. The performance is dreadful. I recently made it only render the visible tiles, but this still did not improve the FPS much. Right now I'm looking for a way to speed up the rendering. I attribute the slowness to the way I am rendering ; every tile is individually blitted to the screen. What would be a more effective was of doing this?
In pygame (afaik), updating the screen is always one hell of a bottle neck. Since I could not see your code, I don't know, how you are updating the screen. Only blitting the the sprites that changed is a start, but you need to only update those parts that changed, on the screen.
Basically it is the difference between using display.flip() or using update_rects() with only the changed rects. I know, that does not help at all, when you are scrolling the map.
Take a look at this question: Why is this small (155 lines-long) Pacman game on Python running so slow?, it has a similiar topic.
One thing I tried when I had a map compiled of tiles and some sprites on it, I tried always having a precompiled image of the map for an area containing the currently displayed part and some 200 or so pixels around that, so that I could blit the prepared "ground" (still only in updated parts) without the need of blitting all those tiles contained in it. That, of course, is quite some thinking you have to put into that, espacially if you have multiple layers and parts of the map that can be above your active sprites. It is interesting to think and work that through, but I cannot tell you, how much you will gain by that.
One totally different possible solution: I began with pygame once (since I did SDL in C++ prior to that). Recently I was directed to another python gaming library: pyglet. This does not suffer from the problems of updating the whole screen as much as pygame (I think it's because of usage of OpenGL acceleration; it still works on my not at all accelerated eee-Netbook). If you are not bound to pygame in any way, it might be interesting to take a look at pyglet.
I'm looking for a Python 2D graphics library that can basically do the following and not necessarily anything more:
Create a window of specified width and height
Set the RGB of pixel X, Y on the back buffer.
Swap buffers
...and that's it basically. I can't find anything that doesn't come with a massive amount of complex baggage.
I recommend PyQt for this - it's a GUI library/framework but it has very good drawing capabilities. If you look at the examples coming with PyQt, focusing on the graphics & drawing samples, it's quite amazing what you can do with very few lines of code.
Oh, and it does the double-buffering you mention automatically so you don't have to worry about it.
Alternatively, you can use PyGame - a library wrapping SDL, used for game development. Naturally it has very strong 2D graphics capabilities.
I am planning to write an simple 3d(isometric view) game in Java using jMonkeyEngine - nothing to fancy, I just want to learn something about OpenGL and writing efficient algorithms (random map generating ones).
When I was planning what to do, I started wondering about switching to Python. I know that Python didn't come into existence to be a tool to write 3d games, but is it possible to write good looking games with this language?
I have in mind 3d graphics, nice effects and free CPU time to power to rest of game engine? I had seen good looking java games - and too be honest, I was rather shocked when I saw level of detail achieved in Runescape HD.
On the other hand, pygame.org has only 2d games, with some starting 3d projects. Are there any efficient 3d game engines for python? Is pyopengl the only alternative? Good looking games in python aren't popular or possible to achieve?
I would be grateful for any information / feedback.
If you are worried about 3D performance: Most of the performance-critical parts will be handled by OpenGL (in a C library or even in hardware), so the language you use to drive it should not matter too much.
To really find out if performance is a problem, you'd have to try it. But there is no reason why it cannot work in principle.
At any rate, you could still optimize the critical parts, either in Python or by dropping to C. You still gain Python's benefit for most of the game engine which is less performance-critical.
Yes. Eve Online does it.
http://support.eve-online.com/Pages/KB/Article.aspx?id=128
I did a EuroPython talk about my amateur attempts to drive OpenGL from Python:
http://pyvideo.org/video/381/pycon-2011--algorithmic-generation-of-opengl-geom
The latest version of the code I'm talking about is here:
https://github.com/tartley/gloopy
It's billed as a 'library', but that was naive of me: It's a bunch of personal experimental code.
Nevertheless, it demonstrates that you can move around hundreds of bits of geometry at 60fps from Python.
Although the demo above is fairly bare-bones in that it uses simply geometry and untextured faces, one thing I found is that more detailed geometry, texture mapping or other more modern graphics effects don't substantially affect the framerate. Or at least they don't affect it any worse than using the same effects in a C program. These are run on the GPU, so it doesn't make any difference at all if your program is written in Python.
One thing that is performance-sensitive from Python is if you are creating dynamic geometry on the CPU side, e.g. moving individual vertices within a shape, by bending or melting the shape. Doing this sort of per-vertex calculation in Python, then constructing a new ctypes array from the result, then shunting this geometry to the GPU, every frame, will be slow. Instead you should probably be doing this in a vertex shader.
On the other hand, if you just want affine transformations (moving objects around, rotating them, opening chests of drawers, rotating car wheels, bending a jointed robot arm) then all of this can be done by the GPU and the fact your program is written in Python makes little difference to the performance.
You might want to check out Python-Ogre. I just messed with it myself, nothing serious, but seems pretty good.
I would recommend pyglet which is a similar system to pygame, but with full bindings to OpenGL. You can start with simple 2D games to get the hang of the system and work up to 3D later. It is a more modern system than PyGame which is built around SDL which itself is a bit long in the tooth these days.
Perhaps a wee bit off topic but, if your goal is to learn Python, how about creating a game using IronPython and XNA? XNA is not OpenGL though, yet I find it an extremely simple 2D/3D engine which is fast and supports Shader Model 3.0.
Check out the Frets on Fire project -- an open source Guitar Hero alternative. It's written in Python and has decent 3D graphics in OpenGL. I would suggest checking out its sources for hints on libraries etc.
There was a Vampires game out a few years ago where most if not all of the code was in Python. Not sure if the 3D routines were in them, but it worked fine.