6

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?

Community
  • 1
  • 1
Konrad
  • 103
  • 2
  • 7
  • 1
    theres still some overhead with python ... but I would argue that its often worth the cost as python is typically much more readable and its "fast enough" usually – Joran Beasley Oct 10 '14 at 23:32
  • I'm not sure what more can be said. The top answer of the post you linked explains it perfectly. It's viable for many tasks but it's not equivalent to native code. If you want to do anything interesting with OpenGL, then you're going to have a state in your application that you communicate to your OpenGL renderer. Updating that state will require computation which you will do in python. Not to mention last I checked some popular python implementations still have trouble with doing arbitrary multi-threading on more than one core. – PeterT Oct 10 '14 at 23:47
  • For doing just raw OpenGL, the overhead of Python will be negligible. For doing computation that you use to feed the OpenGL… well, without any idea of what kind of computation you're intending to do, nobody can tell you whether Python is "fast enough". If you have a more specific question, ask that. If you don't, your question is just a broader duplicate of the one you linked. – abarnert Oct 10 '14 at 23:49

2 Answers2

5

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.

Adrian Maire
  • 14,354
  • 9
  • 45
  • 85
  • Well, I want to make it just for educational purposes. So I guess it should work? Would it make a difference if I used Cython instead? – Konrad Oct 11 '14 at 00:08
  • 1
    I'm no Python expert, but as far as I know they got pretty good with JIT compilation (see the [PyPy project](http://pypy.org/)) and competes with compiled languages such as C++. That being said, you can always later implement computational intensive stuff in C++ and import in Python as a library if it's worth the effort. – leemes Oct 11 '14 at 00:08
  • 3
    For educational purpose, python is fine. Cython may allow you a fast implementation for some cpu-intensive codes, but IMO, for a first attempt, there is not point to add complexity with it. – Adrian Maire Oct 11 '14 at 00:18
  • @leemes, I am not sure if it is right to say any jit compilation can compete with c++, except perhaps in a few circumstances. If you are serious about graphics and wish to get advances, c++ is perhaps best in a rather big way. But for a simple educational project, sure. – Gavin Simpson Oct 11 '14 at 08:51
  • I used to think the same. But modern JIT compilers pretty much compete with C++, they even are sometimes faster. It's not only about the language but also about the algorithms and how well the compiler can optimize. Anyways, micro-optimization should always be the last thing to consider (which is a rule of thumb also in "the big companies" of the game dev industry, by the way) – leemes Oct 12 '14 at 01:39
  • 2
    "OpenGL is a specification, not a library" I wonder what the 'L' in 'OpenGL' stands for then? – Viliami May 03 '17 at 11:54
  • @Viliami: To be more precise, Khronos release an API specification, not a library (disregarding what the L mean). It is responsibility of the GPU vendors to implement such API and provide the user with a library. For example, Mesa is a library which implements the OpenGL API. – Adrian Maire May 03 '17 at 12:56
  • 1
    @Viliami Open Graphics Language – Badjano Oct 19 '21 at 19:21
4

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.

Community
  • 1
  • 1
Michael IV
  • 11,016
  • 12
  • 92
  • 223