We Keep Coding

Is PyOpenGL as fast as OpenGL?

I am trying to build a general-purpose game engine in Python and PyOpenGL, but I don't know if it is worth even attempting, because I am not sure Python is up to the job...
As far as I am aware PyOpenGL is just a wrapper for OpenGL. Yet, I still see people that say things such as 'OpenGL is better', and 'Python is too slow'.
Take a look at, for example, this question. Most of the answers are biased towards C++.
If they both use the same technology, then why would one be better than the other? To me, it seems as if the language doesn't really matter, because most of the work is done by OpenGl/hardware. What am I missing?

First difference: OpenGL is a specification, not a library. So comparing PyOpenGL with OpenGL it like comparing a blue-print with a house.
Answering your question: Python is an interpreted language, like Java. Game engines require very intensive computation, not only for graphics, but also for physics, AI, animations, loading 3D files, etc. PyOpenGL is probably enough for good graphics, but Python is not enough for all the CPU-side code.
Of course, that also depend of the "level" of your game engine: for simple/academic games, Python may work perfectly, but do not expect a Cryengine with it.

Think of it this way:"how many layers of abstraction are between your App and GPU driver.So let's see.Using Python you have the Python interpreter which reads,parses and converts your code to intermediate (Python bytecode)which then is loaded into Python virtual machine's runtime and the runtime interprets that bytecode and executes it.Now,if you use OpenGL library it means that after that Python should call also GL methods via some abstraction layer,probably similar to Java JNI which wraps OpenGL API function pointers(Usually it is C++ shared library).And only after that the a GL command is submitted to your OpenGL driver.That's how it work also in Java,C# OpenGL wrappers.
Now,if you use C++,and I will omit here all the obvious advantages of C++ as a native language(compiled directly to machine bytecode) upon virtual machine/interpreter based ones,you call those GL API methods directly(once they are loaded at startup) via extension libs like GLEW.No interfaces or wrappers.So,not only you take advantage of C++ performance but you also leverage the language's so called "close to the metal" ability to interact with graphics API directly,without any mediation which usually causes noticeable overhead in heavy apps.
But,as it is said by others,it really depends on the nature of your App.If you work on some prototyping or scientific simulation where the results are more important than the performance then probably Python is sufficient.But if your goal is to squeeze everything from your GPU you should go native.
Hope it helps.

Audio Domain Specific Language vs Python

I want to write some code to do acoustic analysis and I'm trying to determine the proper tool(s) for the job. I would normally write something like this in Python using numpy and scipy and possibly Cython for the analysis part. I've discovered that the world of Python audio libraries is a bit chaotic, with scads of very limited packages in various states of development.
I've also come across a bunch of audio/acoustic specific languages like SuperCollider, Faust, etc. that seem to make the audio processing easy but may be limited in terms of IO and analysis capability.
I'm currently working on Linux with Alsa and PulseAudio installed by default. I would prefer not to involve and of the various and sundry other audio packages like Jack if possible, though that is not a hard requirement.
My primary interest in this question is to determine whether there is a domain specific language that will provide for quicker prototyping and testing or whether a general language like Python is more appropriate. Thanks.

I've got a lot of experience with SuperCollider and Python (with and without Numpy). I do a lot of audio analysis, and I'm afraid the answer depends on what you want to do.
If you want to create systems that will input OR output audio in real time, then Python is not a good choice. The audio I/O libraries (as you say) are a bit sketchy. There's also a fundamental issue that Python's garbage collector is not really designed for realtime stuff. You should use a system that is designed from the ground up for realtime. SuperCollider is nice for this, and as caseyanderson notes, some of the standard building-blocks for audio analysis are right there. There are other environments too.
If you want to do hardcore work such as applying various machine learning algorithms, not necessarily in real time (i.e. if you can get away with reading/writing WAV files rather than live audio), then you should use a general-purpose programming language with wide support, and an ecosystem of good libraries for the extra things you want. Using Python with libs such as numpy and scikits-learn works great for this. It's good for quick prototyping, but not only does it lack solid realtime audio, it also has far fewer of the standard audio building-blocks. Those are two important things which hold you back when prototyping audio pipelines.
So, then, you're caught between these two options. Depending on your application you may be able to combine the two by manipulating the audio I/O in a realtime environment, and using OSC messaging or shell scripts to communicate with an external Python process. The limitation there is that you can't really throw masses of data around between the two (you can't sensibly pipe all your audio across to some other process, that'd be silly).

SuperCollider has lots of support for things along these lines, both as externals/plugins or Quarks. That said, it depends exactly what you want to do. If you are simply looking to detect events, Onsets.kr would be fine. If you are looking for frequency/pitch information, Pitch or Tartini would work (I find Tartini to be more accurate). If you are trying to track amplitude, a combination of Amplitude.ar and some simple math would also work.
Similarly, there is SpecCentroid.kr (for a kind of brightness analysis), Loudness.kr, SpecFlatness.kr, etc.
The above are all pretty general, and there are lots more (the JoshUGens externals package has some interesting FFT-related acoustics stuff). So I would recommend downloading the program, joining the mailing list (if you have further questions), which lives here, and poking around in the Externals, Quarks, and Standard UGens.
Nonetheless, since I am not sure what you are trying to do, I cannot make more concrete recommendations than the above combined with my feeling that it makes the most sense to go to SC for this, rather than writing all of your own tools in Python from scratch.

I'm not 100% sure what you want to do, but as an additional suggestion I would put forth: Spear with scripting in Common Lisp. If what you are doing involves a great deal of spectral analysis, then you can do the heavy Lifting in Spear, and script all of this using Common List with Common Music. Spear has some great tools in terms of editing out very specific partials.

Making a 2d game in Python - which library should be used? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm looking to make a 2d side scrolling game in Python, however I'm not sure what library to use. I know of PyGame (Hasn't been updated in 3 years), Pyglet, and PyOpenGL. My problem is I can't find any actually shipped games that were made with Python, let alone these libraries - so I don't know how well they perform in real world situations, or even if any of them are suitable for use in an actual game and not a competition.
Can anyone please shed some light on these libraries? Is PyGame still used effectively? Is Pyglet worth while? Have either of them been used to make a game? Are there any other libraries I'm forgetting?
Honestly I'm not even sure I want to use Python, it seems too slow, unproven (For games written solely in Python), etc.... I have not found any game that was made primarily in Python, for sure, that has been sold. If I don't end up going with Python, what would a second/better choice be? Java? LUA?

Pygame is just a wrapper for SDL, so technically a lot of games have been made using it, most of the work is done C-side anyways. It's a little slow, though if you are doing a 2D game, it should be sufficient. Frets-on-Fire was written in pure python with PyGame, and FoFiX was written in python with C extensions, and those games are both pretty great, altough on slower computers FoFiX can have trouble running 4 player.
Pyglet is also pretty nice, though I've only used it for emulator development, drawing single layers, so I don't know how well it actually works for game development. I've found that it's much easier to use direct OpenGL with Pyglet than it is with SDL/PyGame, so if you are doing a 3D game, it's probably better than using SDL. Also, since it's written in python, it's very easy to extend classes to change how a function is handled. For instance, I was trying to load data into an openGL texture through the pyglet Texture class, but the class couldn't load the data in a format I wanted, so I extended that class and changed the function that got the texture type (comes from a string) to include the texture I wanted, quick and painless.
One library I don't see mentioned enough is SFML. The 2.0 API (currently in beta) is pretty stellar and simple to use, and, if I remember correctly, runs a little faster than SDL. It is also more "object oriented" than SDL, which is really nice if you are working in an OO language like Python. It has some nice Python bindings written by Bastien Leonard in Cython that are pretty easy to use (or you can use the old C bindings if you don't want to use the most up to date version). I used this a while back and it was quite an enjoyable experience.
The reason why there aren't a lot of shipped games using Python is pretty simple: You can't close Python source. Even if you "compile" python into an executable using Py2Exe or something, it really just packs up the interpreter and python source into an exe file, and the source can be got just by opening up the exe in a hex editor.
While I'm a supporter of the "write it in Python, write time critical parts in C", if you feel python is going to be too slow, I would probably suggest C or, preferably, C++ as the way to go, simply because you don't get that much of a usability advantage for writing in Java, and the C languages can be quite a bit faster running than Java, and Lua will just take away some of the usability of Python without giving you any noticeable performance enhancement. SFML and SDL can both be used straight from C(++).
Advice if you do decide to use python: Use it as it is supposed to be used, as a scripting language. Do not try to bit twiddle or load images in pure python, either use the interfaces available in the library you choose (they all have very good interfaces for those kinds of things) or write an extension module to do that for you. Use python for logic control and fetching data from your libraries. If you follow that simple rule, you really shouldn't run into any performance issues.

In my experience, the things that are really going to kill you aren't generally related to graphics at all. Sure, it's a challenge to get all your frame rendering done in less than 16 ms without techniques like dirty-rectangle updating, but that's not going to be the big thing you'll lose sleep over. The biggest performance considerations are going to come from much more elementary things - collision detection, spatial searching, and pathfinding are three of the big ones - that can easily send your logic frame rate into the floor if done inefficiently over even a few hundred objects. For problems like these, pure Python may not be the best choice, but it's not hard to offload these to C/C++ while retaining Python for higher-level logic. This is essentially what games like Civilization 4 and EVE Online (client and server!) do - offload performance-critical code to C++ while retaining the flexibility and simplicity of Python for 'everyday' tasks.
pygame is actively developed (they haven't had a stable release in a while, but the Mercurial repository is quite lively) and fairly popular. It also uses the well-regarded (C-based!) SDL library under the hood. pyglet is also actively developed and uses OpenGL for all of its rendering, making moving to 3D development easier if you're planning to go in that direction (since you'll already have most of the basics).
If you decide to go the not-Python route, you can use SDL directly with C/C++, along with addon libraries like SDL_gfx (for primitives), SDL_ttf (for text), and SDL_net (for basic networking). Another excellent and widely used alternative for C/C++ is Allegro. I've used both, and I will claim that it's largely a matter of taste which one you go with.

Pygame should suffice for what you want to do. Pygame is stable and if you look around the websites you will find games which have been coded in pygame. What type of game are you looking to implement?

Is there a way to access hardware directly in Python?

I want to learn about graphical libraries by myself and toy with them a bit. I built a small program that defines lines and shapes as lists of pixels, but I cannot find a way to access the screen directly so that I can display the points on the screen without any intermediate.
What I mean is that I do not want to use any prebuilt graphical library such as gnome, cocoa, etc. I usually use Python to code and my program uses Python, but I can also code and integrate C modules with it.
I am aware that accessing the screen hardware directly takes away the multiplatform side of Python, but I disregard it for the sake of learning. So: is there any way to access the hardware directly in Python, and if so, what is it?

No, Python isn't the best choice for this type of raw hardware access to the video card. I would recommend writing C in DOS. Well, actually, I don't recommend it. It's a horrible thing to do. But, it's how I learned to do it, and it's probably about as friendly as you are going to get for accessing hardware directly without any intermediate.
I say DOS rather than Linux or NT because neither of those will give you direct access to the video hardware without writing a driver. That means having to learn the whole driver API, and you need to invoke a lot of "magic," that won't be very obvious because writing a video driver in Windows NT is fairly complicated.
I say C rather than Python because it gives you real pointers, and the ability to do stupid things with them. Under DOS, you can write to arbitrary physical memory addresses in C, which seems to be what you want. Trying to get Python working at all under an OS terrible enough to allow you direct hardware access would be a frustration in itself, even if you only wanted to do simple stuff that Python is good at.
And, as others have said, don't expect to use anything that you learn with this project in the real world. It may be interesting, but if you tried to write a real application in this way, you'd promptly be shot by whoever would have to maintain your code.

This seems a great self-learning path and I would add my two-cents worth and suggest you consider looking at the GObject, Cairo and Pygame modules some time.
The Python GObject module may be at a higher level than your current interest, but it enables pixel level drawing with Cairo (see the home page) as well as providing a general base for portable GUI apps using Python
Pygame also has pixel level methods as well as access methods to the graphics drivers (at the higher level) - here is a quick code example

This is rather an old thread now, but I stumbled upon it while musing the same question.
I used to program in assembly language. In my day, drawing on screen was simply(?) a matter of poking a value into a memory location. The value turned a pixel on or off and defined its colour.
The term 'poke' comes from Basic by the way, not assembler. In assembler, you had to write a value into a data register then tell the processor where to put the data using another command and specifying an address register, usually in hexadecimal form! And each different processor had its own assembly language. But hec was the code fast!
As hardware progressed, I found that graphics hardware programming became more and more complex. There's much more to it than now simply defining a pixel. The graphics subsystem has its own processor -- or processors -- and it's that that you've got to learn to talk to. The processor doesn't just plonk stuff in memory locations. (I believe that what used to be the fastest supercomputer in the world for a while ran on graphics chips!) 'Plonk' is not a Basic command by the way.
Sorry; I digress. In answer to the original poster's query, I believe that the goal of understanding the graphics-drawing process could have been best achieved by experimenting with a Raspberry Pi. It's Python compatible and hence perfect for the job. Its hardware is well documented and it's cheap and easy to use.
Hope this helps someone, Cheers, M

2D RTS in Python?

I am a great python fan. Recently I got an idea to write RTS engine and/or maybe a simple RTS game based upon this engine. There are a couple of things I need to think about and maybe you can give me some advice on these:
Performance. Most games are written in C++. Isn't python too slow for game engine? I am aiming only at 2D, but still it may be too demnading.
Graphics. Are there any good graphics libraries for python? SDL/OpenGL bindings or maybe something more suitable for python?
Game engines. Do you know of any existing RTS engine written in python?
Any tools/libraries for python that maybe helpful in developing RTS
Thanks in advance!

Performance may be an issue with heavy graphics/math processing. If so, see Panda3D, NumPy, Cython, and PyPy.
Use Pyglet, PyOpenGL with Pyglet, Panda3D (although you are writing in 2D, you can still use a 3D engine), or perhaps some other library.
There don't seem to be existing RTS libraries, but there are definitely pre-existing generalized engines.
Try searching for RTS-related libraries in general: you'll need AI, pathfinding, networking, and so on. Therefore, you may be interested in Twisted, for instance, since it helps with networking.

I can answer your first two.
Python isn't too slow for games. That all games must be written in C++ is a myth. Sure C++ (or C) might give you the best performance, but it doesn't mean you're unable to write a game in another language.
Try PyGame: SDL bindings for Python.