Since it uses Ctypes it would be portable to PyPy and possibly Jython. I will have to check this out.
Since this looks like a 1:1 call level interface to SDL there still needs to be a Cocos http://cocos2d.org/ or Pyglet http://www.pyglet.org/ style layer on top of this. It could be the basis for something like LuaLove, http://love2d.org/
PyGame was a good start but the world needs to move on.
In my experience Pyglet is a lot more pythonic than PyGame. It's probably not as game-focused as PyGame, but it is self-contained, compact and provides a good API to build upon.
This is because you are using opengl inefficiently. Your method of drawing a rectangle requires sending a bunch of bits to the GPU, rather than letting the GPU do the rendering and calculate the values of the bits. Data transfer from memory to CPU to the GPU is expensive. Instead, you should define the rectangle using vertices and opengl drawing primitives. For images (sprites, textures), you load these once onto the GPU and then let opengl translate and render them. http://www.pyglet.org/doc/api/pyglet.image.Texture-class.html
I have several examples of pyglet drawing, translating and rotating many polygons at over 60fps. Associating these vertices with textures already loaded on the GPU would not slow it down much if at all.
see http://tartley.com/files/stretching_pyglets_wings/presentation/
Python is a comparatively slow language, yes, but it's still very, very fast; plenty fast for pretty much anything an average (or above-average) indie developer is likely to throw at it.
That said, Py*game* is going to throw a massive performance wall in your face almost immediately. It's fine for simple games where the screen stays mostly static (maze games, Pong clones, Tetris/Bejeweled, single-screen platformers, etc.), but as soon as you want to work with medium to large textures and scrolling environments Pygame basically poops its pants.
Last project I tried in Pygame, I needed a pretty detailed scrolling background image. With a single 1280x768 texture for the background being drawn on every frame, the game ran at 40 FPS with nothing else being drawn whatsoever. After ransacking the Internet for a solution (there isn't one), I finally switched to Pyglet.
The exact same game, with no changes except swapping out the Pygame draw function for Pyglet's equivalent, now ran at 960 FPS.
Pygame's chief advantage is that it's very easy to use, which makes it great for learning the basic concepts of game programming. As terrible as its performance is, if you don't need to redraw the entire screen on every frame it's still plenty fast for lots of simple (but not bad!) games. Don't let Random Dude From the Internet convince you to drop everything and learn something new just in case you need more power. Make games first, enjoy the process, and if you find you need better performance the more advanced libraries will always be available :)
I contest your PyGame assertion. I found pyglet (http://www.pyglet.org/) to be better designed and easier to package. I loved it so much I wrote a tutorial for it (one that assumes you know basic Python). http://www.steveasleep.com/pyglettutorial
For sprite rendering, I'd go with either rabbyt or pyglet. Both libraries are hardware-accelerated via OpenGL, so they should easily be able to handle your requirements. For math, I'd say Numpy is the way to go, like you said. Now with networking, things are a lot less clear. You see a lot of suggestions for Twisted for things like this, but it's my opinion that higher-level libraries like legume are better for game development.
Not many AAA titles are written in Python, but a number of them use Python for scripting. Even if you never release a game made in Python, you still get the wealth of experience learning to actually program in a very friendly environment. Besides, Python is a fantastic programming language for many other purposes.
That said, check out http://pygame.org/news.html. There's screenshots, and project lists on this site. Most of these games are pretty simple, but some are surprisingly well thought out. The pygame library itself is pretty easy to use, but I generally prefer pyglet http://www.pyglet.org/
I've been writing games in my spare time for a long time. I offer only this advice: keep doing it. You're only as good as you are right now. You only get better by doing it over and over and over. Start small. Build on what you learn. If you get stuck, ask questions. Heck, ask questions if you're just not sure, but don't get discouraged. This is hard, otherwise all gamers would be doing it.
http://www.pyglet.org/doc-current/api/pyglet/media/pyglet.media.riff.html#module-pyglet.media.riff
There's lots of different formats that can be put in a WAV file, it's not just a single format. The documentation claims it only supports uncompressed wav files. You could maybe see which kind you have if you look at the "details" tab in those file detail windows you made a screenshot of.
You could open it with the wave
module and see what happens, maybe those error messages are more descriptive?
import wave with wave.open('test.wav') as f: desc = "Audio compression: {} ({})" print(desc.format(f.getcompname(), f.getcomptype()))
Or maybe Audacity can display some details about how the file is encoded?
Check out Pyglet: http://www.pyglet.org/
It's a really nice window / event / media manager for python that makes game coding really easy. It's low level enough that you get to do the physics / control the sprites, but it's not low enough where you are manually rendering things.
I made a top-down shooter with this over a weekend: http://maeprojects.ucsd.edu/mae156/winter2011/group4/movie.swf
The frame rate on that sucks because the screencap software couldn't capture at 60fps. I can even give you the source if you really want.
Either way I say go for it! Coding a game is fun and a great demonstration of a language
I'm sorry, I don't own a Mac, so I couldn't test it there, but I guess all you have to do is install the pyglet python library. I didn't think to package it with the source code, butt here's an installer on the website for Mac OS X.
If you're doing anything involving networking, it's probably worth looking into Twisted. For the front-end, pygame is pretty popular with people who already have some experience with SDL in other languages, but I'd actually recommend pyglet instead; pygame is a pretty thin layer over SDL, and pyglet just feels more Pythonic a lot of the time.
If you don't want your friend to have to install anything besides Python, it's of course possible to do everything using something like telnetlib and Tkinter, but I wouldn't recommend it.
Well, at least try using pyglet's own image loading functionality. Things might be slow because of all types of conversion that needs to happen when you call blit (data is not converted when you instantiate ImageData).
I notice these descriptions in the docs:
ImageData An image represented as a string of unsigned bytes.
...
Texture An image loaded into video memory that can be efficiently drawn to the framebuffer.
And elsewhere it mentions relatively expensive conversions. I assume the docs show the best way to use pyglet.
I've never used pyopengl with cython, but cython is compiled to c, so I think it should support anything that has a c/c++ interface. There's another project called pyglet that I've used for basic game programming that might be worth looking into though.
In my opinion, Pyglet is the better python game development framework, from a purely programming standpoint. But pygame has the larger community where more help and tutorials will be available.
It depends what else you need, but the <code>pyglet</code> library is good for this sort of thing. You make a Window
, and can assign functions to run for events like on_key_press
, on_mouse_move
, etc. It works well with the OS so the window needs to be focused for it to catch key presses, just like regular applications. Not sure if that's what you're looking for.
Of course. Have you looked into the library pyglet? I've used it in the past and their media playback is quite speedy. Although out of the box it only supports WAV files, installing AVBin along with it opens up support for other filetypes.
http://www.pyglet.org/doc-current/api/pyglet/pyglet.media.html#module-pyglet.media
pyglet is pretty great. Use the 1.2alpha version. It's cross-platform and the same code should work on anything, and the interface is nice. Using events is so much better than doing everything in one big loop like you have to do with pygame and (I think) PySDL2.
Also, for shameless self-promotion, I made a simple little library to make it easier to make rectangles and circles and such with pyglet: pyglet2d.readthedocs.org
I've never used Kivy but I just browsed through the docs and it looks pretty good also. I'd recommend Kivy or pyglet over pygame or pySDL2. May as well start learning the more powerful methods from the get-go instead of learning bad habits from mucking around with a giant run loop. My intuition says to use Kivy if you want high-level stuff like browsing through data, moving between different views, more like a traditional app. If your goal is closer to (as it sounds like) something like artwork that morphs based on mouse movements, use pyglet.
I believe Pyglet works pretty well for this.
Some guy on /r/tinycode made a minimal, but functional Minecraft clone in python using pyglet.
edit: the minecraft clone at github if you're interested - https://github.com/fogleman/Minecraft
Pygame is not a good library for modern game development. Even if you are making a 2d game, it limits you to outdated software blitting. It doesn't make particularly good use of python's object oriented programming, so you could just as easily code in C or C++. You are much better off using Pyglet, Cocos2d, or Python SFML. All of these make use of your $99 GPU which would sit around collecting dust with pygame, and hardware-based rendering actually simplifies 2d game creation quite a bit.
Wow, thanks! I'm still a neophyte programmer who's really only comfortable with Python, and I've been waiting for someone to pull this off. I can see myself using this to do some basic experiments I wasn't otherwise sure how to handle in Unity and UE4, maybe even getting back into Pyglet and building some simple procedural geometry. Assuming I ever find the time, I'll let you know if I manage to make something cool with it. ;)
You've got your dates all wrong. http://www.pyglet.org/news.html - last release was July 13, 2012...pyglet is also 64 bit compatible, updated to work with Python 3, etc. BSD license for Pyglet, vs LGPL for PyGame too if that matters at all (more freedom as far as packaging code)
Also, have you run Pyglet on PyPy? If you haven't...do. You'd be crazy to use PyGame vs PyPy+Pyglet. PyGame doesn't work under PyPy last I checked.
Any special functionality you're using right now that you're concerned about? Pyglet is basically a high-level wrapper around OpenGL, so it's got pretty much all the possible graphics pipeline you need.
Their documentation is absolutely fucking superb too: http://www.pyglet.org/doc/programming_guide/index.html
This is the part I meant: http://www.pyglet.org/doc/programming_guide/displaying_text.html But you probably read it.
If nobody here knows, try http://stackoverflow.com/questions/tagged/pyglet or the pyglet mailing list. I'm sure someone's had the same issue.
Python is great! You might want to check out Pyglet instead of PyGame. I personally feel it's better (just an opinion!).
Check out Pyglet here: http://www.pyglet.org/ And also a tutorial for creating a space game using Python & Pyglet here: http://www.learningpython.com/2007/11/10/creating-a-game-with-pyglet-and-python/
With both of these, you should be able to hit the ground running fairly quickly!
Good luck!