I want to start learning OpenGL but I don't really want to have to learn another language to do it. I already am pretty proficient in python and enjoy the language. I just want to know how close it is to the regular api? Will I be able to pretty easily follow tutorials and books without too much trouble?
I know C++ gives better performance, but for just learning can I go wrong with PyOpenGL?
With the caveat that I have done very little OpenGL programming myself, I believe that for the purposes of learning, PyOpenGL is a good choice. The main reason is that PyOpenGL, like most other OpenGL wrappers, is just that: a thin wrapper around the OpenGL API.
One large benefit of PyOpenGL is that while in C you have to worry about calling the proper glVertex3{dfiX} command, Python allows you to just write glVertex3(x,y,z) without worrying about telling Python what type of argument you passed in. That might not sound like a big deal, but it's often much simpler to use Python's duck-typing instead of being overly concerned with static typing.
The OpenGL methods are almost completely all wrapped into Python methods, so while you'll be writing in Python, the algorithms and method calls you'll use are identical to writing OpenGL in any other language. But since you're writing in Python, you'll have many fewer opportunities to make "silly" mistakes with proper pointer usage, memory management, etc. that would just eat up your time if you were to study the API in C or C++, for instance.
PyOpenGL
I don't think it is a good choice. In my opinon in C/C++ it is easier to play around around with your OpenGL code - start with simple app, then add shader, then add some geometry functions, make a texture/geometry generator, build scene via CSG, etc. You know - to have fun, play around with code, experiment and learn something in process. I honestly just don't see myself doing this in python. Surely it is possible to do OpenGL programming in Python, but I see no reason to actually do it. Plus several OpenGL functions take memory pointers as arguments, and although there probably a class (or dozen of alternatives) for that case, I don't see a reason to use them when a traditional way of doing things is available in C/C++, especially when I think about amount of wrappers python code uses to pass vector or array of those into OpenGL function. It just looks like making things more complicated without a real reason to do that. Plus there is a noticeable performance drop, especially when you use "RAW" OpenGL.
Besides, if you're going to make games, it is very likely that you'll have to use C++ or some other "non-python" language.
P.S. I've done enough OpenGL programming, a lot of DirectX programming, but I specialize on C++, and use python only for certain algorithmic tests, tools and scripts.
Related
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.
My current primary programming language is python. There are lots of things I like about it, but I also like functional languages. Not enough to do an entire program in them, but definitely for certain functionality, that fits the functional mould well.
Of course .NET is amazing in this regard, having both ironpython and F#. But considering the ironpython support for the scientific python ecosystem is still dodgy last time I checked, .NET is not much of an option for me. I am a bit shocked at the apparent lack of tools to facilitate interop between cpython and say, Haskell. They are both mature languages with large communities, that seem like such a nice match to me.
Is there something about their architecture that makes them ill-compatible that im missing, or is this just something awesome that is still waiting to happen?
To clarify; there are some half-baked projects out there, but I am thinking of something that parallels the awesomeness of Weave, pycuda, or boost. Something that automates all the plumbing inherent in interop with just a few annotations.
Another approach is to use unix pipes, and just write a Haskell program, and also write a Python program, and have them communicate over text. Haskell and Python even share the same syntax for lists, so it's really easy to pipe data from one to the other.
Referring to:
Is there something about their architecture that makes them
ill-compatible that im missing, or is this just something awesome that
is still waiting to happen?
I think it is about the people doing these languages:
There are not much people who want to do Haskell and Python at the same time.
to make use of both languages (liek Haskell and Python) at the same time you either could go via the C-Interface or create a protocol both languages speak.
Both are fairly advanced, limiting the number of people who could do it. Sure there would be also tradeoffs which make it difficult to use the full power of both languages.
I am using Python and although I know some Haskell, I do not program it. I am a bit stuck in object-orientation, telling me that some day a problem will decide for me that it can better be solved in Haskell than python. That problem did not yet occur because my first thought is: I know how to do it in Python. I think other 'experts' face that problem, too.
You start thinking in a language. I think that Haskell has a totally different way of thinking with its functional style, no side-effects. To get into this thinking I need to forget or not use my Python knowledge. Switching between these two ways of thinking requires some strength.
Wrapping it up: because that two languages are not so close they stay apart. It is hard to do both and there are not many or easy ways to practice doing both.
I think that any answer to this question would be remiss without considering the inertia of object-oriented and imperative languages relative to functional ones. Consider the following situation, beginning with the fact that functional languages are not taught at nearly the frequency that object-oriented or imperative languages are at the secondary, university, or graduate level. As User mentions, there is significant momentum involved as a programmer concerning one's choice of language. For example, during the course of a typical CS degree at a four year University, one may learn a handful of languages and more than likely, not one of them is a functional language. This typical graduate will then proceed to work in industry, where, after programming for 40+ hours per week for one's job, it is very difficult to then take time to, not only learn an entirely new language, but to learn a language that operates completely differently from the one's one already knows. On top of all of this, there is the drawback that functional languages are not nearly as useful in industry as object-oriented or imperative one's are. One can see that given this current state, it is understandable that the interoperability between Python and Haskell is not what some programmers would like it to be.
If you were to use Haskell to Python bindings, what would you do in each language?
If you consider binding C and Python, for example, you use C when you need the speed boost, or when you need to push bits around, and you are using Python when want to be expressive and concise. It's common that you have a pair of languages, one for most of the logic, and one that you can drop down to for speed, at the cost of clarity. The more of a gap between the languages, the more you can gain from switching.
If we were to bind Haskell and Python, it is less clear what you'd get out of it. I wouldn't drop from Python into Haskell just for speed, since Haskell, while fast, isn't as fast as C. But if I was using Haskell, when would I use Python? Python isn't more expressive than Haskell, not like comparing C and Python.
I think that most of the time, it's easier to just import functools, and program functionally in Python, instead of having to convert objects into some Haskell representation, do some work, and then convert it back.
Though, if you really wanted it, Cython would make it easy to write functions that Haskell's FFI can use.
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?
How practical would it be to use Cython as the primary programming language for a game?
I am a experienced Python programmer and I absolutely love it, but I'm admittedly a novice when it comes to game programming specifically. I know that typically Python is considered too slow to do any serious game programming, which is why Cython is interesting to me. With Cython I can use a Python-like language with the speed of C.
I understand that I'll probably need to learn a bit of C/C++ anyway, but it seems like Cython would speed up development time quite a bit in comparison.
So, is it practical? And would I still be able to use C/C++ libraries like OpenGL, OpenAL, and Bullet Physics?
If you're working with a combination like that and your goal is to write a 3D game, you'd probably get better mileage out of a ready-made 3D engine with mature physics and audio bindings and a Python API like OGRE 3D or Panda3D. Even if you don't, this post about using Cython with Panda3D may be helpful.
I'm not sure about now, but back in 2007, the trade-off between the two was basically that:
Panda3D was better-documented and designed from the ground-up to be a C++ accelerated Python engine (apparently they made some API design decisions that don't occur to C++ engine projects) and, predictably, had a more mature Python API.
PyOgre was built on top of a much more advanced engine and had a larger and more vibrant community.
...however it's quite possible that may have changed, given that, passage of time aside, in 2007, Panda3D was still under a GPL-incompatible license and that drove off a lot of people. (Myself included)
I'm the developer for the Ignifuga Game Engine, it's 2D oriented and Python/Cython/SDL based. What I generally do is develop the code in Python, and then profile the engine to see if there are some obvious bottlenecks (the main loop, the rendering code are good candidates), and convert those modules to Cython. I then run all the code (Python and Cython based) through Cython, and compile it statically against SDL.
Another of Cython's big "pluses" is that binding to SDL, or any C based library, is almost trivial.
Regarding threads, the engine is currently single threaded with cooperative multitasking via Greenlets, though this comes from a design decision to mitigate potential multi threaded pitfalls that unexperienced developers might fall into, rather than a limitation on Cython's part.
at this date (12th of April 2011) unixmab83 is wrong.
Cython doesn't forbid the use of threads, you just needs to use the no_gil special statements.
Beside the bindins of c++ is now functional in cython.
We do use it for something which is close to gamedev. So while I cannot be final on this, cython is a valid candidate.
I've found that a lot of the time, especially for larger libraries, you wind up spending a tremendous amount of time just configuring the Cython project to build, knowing which structures to import, bridging the C code into Python in either direction etc. While Cython is a nice stopgap (and significantly more pleasant than pure C/C++ development), the amount of C++ you'd have to learn to effectively use it basically means you're going to have to bite the bullet and learn C++ anyway.
How about PyGame?
I know Cython and you do not have to know C/C++.
You will use static typing but very easy.
The hardest part is to get the compiling working, I think on Windows this is done over visual studio thing.
There is something like a standard library including math for example. The speed gain is not too big but this depends on your scope.
ctypes was much faster (pure C) but the connection to Python was very slow so that i decided to look for Cython which can still be dynamic.
For speed gain in a game Cython will be the right choice but i would name this performance also limited.
Threads!!! A good modern game must use threads. Cython practically forbids their use, holding to GIL (global interpreter lock) the entire time, making your code run in sequence.
If you are not writing a huge game, than Python/Cython is okay. But Cython is no good as a modern language without good thread support.
What is that needs to be coded in Python instead of C/C++ etc? I know its advantages etc. I want to know why exactly makes Python The language for people in this industry?
I work in this industry, and here's what I've observed:
It's a nice, tidy language that's not hard to pick up. You don't have to be a language guru to use it.
It embeds nicely in C/C++ applications.
It has data types, so numeric operations can be done without type shimmering.
Speaking of numeric operations, NumPy!
Network effect -- everybody else uses it, so we get a virtuous cycle of interoperable scripting.
Perhaps that's because it's a scripting language for Blender?
A few other points I've not seen in the existing answers:
it's free
it's fast [enough]
it runs on every platform I know of (AIX, HPUX, Linux, Mac OS X, Windows..)
quick to learn
large, powerful libraries
numeric
graphical
etc
simple, consistent syntax
the existing user-base is large
because it's easy-to-learn, you don't have to be a "programmer" to use it
Because Python is what Basic should have been ;)
Its a language designed from the beginning to be used by non-programmers, but with the power to be truly used as a general purpose programming language.
Aside from the fact that it's already in use, the main advantage is that it's quick to use. Java, C, and friends almost all require tedious coding that merely restates what you already know. Python is designed to be quick to write, quick to modify, and as general as possible.
As an example, functions in java require you to declare the type of each of the input variables. In python, as long as you pass input variables that work with the function, it's valid. This makes your code extremely flexible. You don't waste time declaring variables as one type or another, you just use them.
Some people will tell you that java produces code that is "more correct", but in animation and graphics, producing code that works in as short a time as possible is usually the goal.
My guess is that it is the tool for the job because it is easy to prototype extra features.
I used python for molecular animation using PyMol. Many molecular visualization programs have their own scripting languages. PyMol's scripting language is python, a real programming language. So, if your task requires calculations of any kind, text parsing or calling the net, you are welcome. Before I assume that in "conventional" animation the situation is similar.