Hi! I’m pretty much talking from what I have read and I haven’t use CPython before.
I read that CPython is a tool that can compile to native code python scripts, and as I am concerned the major performance “problem” is the interpretation of python code.
I love python, and I pretty much like the BGE, it feels intuitive and easy to use, maybe not so powerful but still like it.
I read in a Monster’s post that you can get the maximum performance of the BGE only by using logic bricks and when you code with python you are making your game slower.
That is bad, I think. That you are forced to make your game using logic bricks if you want it to have the best performance.
Another good think that may come with this is the reduction of the size of the game because we no longer need to have the entire python interpreter inside our games (I think that is what happens)
So is there a way to compile the python scripts with CPython and use them with the BGE? Thanks!
Anything where you have to itterate over a large data set in python each frame is probably not a good idea, but the good news is there are many functions already that are threaded like mathutils.kdtree can really help with static elements lkke vertex painting, or a bvhtree.
logic bricks are the key to efficient python programing as well,
Sensors are your key to setting states that run python, and falling back to low logic usage states when sensors are not active.
always ---------(one giant script) is a bad game design
timer not equal to zero------------(produce effect and reduce timer)
(this runs until the timer runs out then uses no python)
x is changed-----------python
is also a good design for some systems
bool = True-----------python
with this and making small sublists of data you store, so you don’t ever itterate through all of scene.objects each frame, and you should be able to squeeze out 60 fps.
Monster’s advice is generic, and (although correct), it is important to look at the bigger picture.
The logic bricks are “fast” because they’re written in C, but more importantly, they don’t do much, and when they do, they use proper event management. They don’t run checks every frame (in most cases), whereas many python scripts I see do expensive lookups every frame, instead of developing an event system to support this.
Python is generally slow because of three things:
All “python” objects are allocated on the heap, which means that any time you do things to objects, or between objects, you are pointer chasing (which isn’t as fast as stack-memory lookups).
Everything (including functions can be modified at runtime, so it’s hard to make optimisations that come with the restrictions on C
Python has a little overhead in doing even basic operations because it allows you to override and inspect these features, so it cannot just make these features available if you’re using them.
However, this is only to say that Python is slow compared to C when comparing what the two programs do. Python itself is, after all, doing “more” than C (it’s interpreted in a C-based interpreter). It doesn’t mean you’ll be able to count the number of cycles it takes to do something in game, it’s still blazing fast in that regard.
Python slows your game down predominantly if you’re using it wrong. If you have multiple nested loops running every frame, doing expensive checks (like vector lengths or matrix multiplication) then expect it to slow down.
Most well written game code doesn’t create problems for the game programmer. Yes, when you’re targetting expensive frame budgets you need every fraction of a millisecond you can get, but for most of us, that’s not the case. If your game logic is running over 1-2 ms and you’re not doing much (which most games on BA are not), you need to optimise that code. (These are random numbers I’ve thought of, but regularly I see really basic games hitting 5ms of logic time on my computer, when my networking library (doing serialisation etc in Python (ew)) is under 2ms with game logic).
Cython is what you’re referring to, and it can offer speed ups to your code. However, most BGE games heavily rely on BGE APIs which can’t be improved in speed by Cython. Cython is good at speeding up pure-python code (like numeric operations, dicts etc), and will offer very little improvement (and a lot of hassle) when all you’re doing is raycasting cubes.
if I store a reference to a pointer as a object property and access it with own[‘StoredPointer’] is there a faster way?
if I need to raycast based on a origin and linear velocity, I need matrix multiplication and vector math each frame right?
(for CCD based on raycasts*) (I only do this on fast moving projectiles*)
No i’m not having issues with performance, in fact the bge works pretty well in my old machines. But I’m kind a “performance perfectionist”.
It wasn’t clear to me if the BGE compiles with CPython (or Cython, i don’t know the difference) the python scripts before executing them. For simple games of course we can interpret python code without lossing much speed, but when you start doing AI, or more cpu intensive operations it may be good if the python code is compiled instead of interpreted.
Another great advantage (i think), is that when we export the game to be an executable file, we could easily delete the Python folder, which in my case is being 76 MB large, which is HUGE for simple games.
So…
Why is CPython not being used, or if it is used why we have the Python folder when we export our games?
CPython is the standard Python interpreter (BGE uses it) and Cython is a compiler. Like most interpreted languages CPython pre-compiles the scripts to an intermediate form to gain performance, “.cpy” files. You can by the way distribuite those files instead of the source code and the game will run like always. For intensive operations you can code those on compiled libraries (C/C++) and then call them from Python, but in general you should have no need for so much optimization on performance (at least given the fact that BGE lacks performance in many other areas).
Another great advantage (i think), is that when we export the game to be an executable file, we could easily delete the Python folder, which in my case is being 76 MB large, which is HUGE for simple games.
So…
Why is CPython not being used, or if it is used why we have the Python folder when we export our games?
The Python folder doesn’t contain the interpreter (CPython), the interpreter is embedded in the blenderplayer, what the python folder contains are standard libraries (+ numpy I think?). You can delete the ones you don’t use. Now even if BGE were to use Cython it would still need the Python libraries (in a compiled form probably), so you would only save the space of the interpreter, wich shouldn’t be that much (maybe 30mb?).
Actually since Linux uses a distribuited system, a version of Blender could be compiled so that it doesn’t include CPython and you would instead use the Python installed in the system (so you would save all the 76MB of the Python folder plus some more for the interpreter), since most Linux systems have Python3 already installed it wouldn’t be a problem, I can’t say the same about windows.
Of course if Blender is already installed on the host computer you don’t need to distribute the blenderplayer nor python, the game can use the ones from Blender. For that tought, unless you want people to open the game directly from Blender and press P, you need a launcher, BGECore Launcher for example. <– This is useful spam.
At the level where you describe your game’s business (game’s behavior) you typically do not need about low level speed of that kind.
It is more worth to look at efficient design of your games business. Typically the problems can be resolved by another better fitting design. The challenge is to get the results you want with the resources you have (rather than the resources you do not have). Processing time is a resource too.
Beside of that you need to find a balance between maintainable and efficient behavior description. You can surly imagine that an high-efficient code that nobody understands is not really usable, while very good understandable but time eating code is not sufficient either.