BGE: Fix broken build assumptions and invalid flag-dependent initialization.

Authored by Neal Alexander (NHA) on May 16 2015, 11:55 AM.


Inês Almeida (brita_)
Mitchell Stokes (moguri)
Apply Patch
arc patch D1304


This patch against blender-v2.74-release allows blenderplayer to function despite Python or audio being disabled. A number of issues related to WITH_AUDASPACE and WITH_PYTHON are fixed.


The KX_PythonInit module is absorbing functionality outside its intended domain. It is currently responsible for initializing mandatory global state unrelated to python in other modules. When WITH_PYTHON is disabled these global symbols remain exported, but uninitialized. We fix the forced dependence on KX_PythonInit.setupGamePython by adding the new function KX_KetsjiEngine.setupGameGlobals, which properly initializes gp_KetsjiEngine and gp_KetsjiScene regardless of build flags. Additionally KX_RasterizerDrawDebugLine, KX_RasterizerDrawDebugCircle, KX_GetActiveEngine, KX_GetActiveScene, KX_SetActiveScene are moved out of KX_PythonInit and into KX_KetsjiEngine.


Addresses minor #ifdef related issues.

Larger Perspective

The long term goal of this patch series will be aimed at improving and modularizing BGE as a standalone unit. Ideally, the blender conversion routines of BGE will remain in the main blender repository, while the rest of the game engine is separated into its own tree, similar to cycles-standalone.

Diff Detail

Neal Alexander (NHA) set the repository for this revision to rB Blender.
Neal Alexander (NHA) updated the summary for this revision. (Show Details)

Hello, i will review this later, currently just a inline comment.


This check is also done in RNA ?

This is more @Campbell Barton (campbellbarton)'s area, so I'll leave this patch mostly to him to review.


Even when we don't use Python, these are still available from KX_PythonInit, so I don't see a need to move them in this patch. If you're moving them as part of cleanup, then please split that into a separate patch.


Do we need both this #ifdef and this #ifndef?


Is this include necessary? I'm guessing we could run into issues if we relied on something from WITH_PYTHON or WITH_AUDIO to include this indirectly. But, I'd just like to double-check.


Ah, (in response to another inline comment) I guess assigning these here would be a problem for building without Python. However, we should just be able to move this initialization around instead of moving all of those functions out of KX_PythonInit to keep this patch smaller (which makes the patch easier to review). Also, we've supported building without Python in the past, so I'm not sure how we got to this point.


Why move this down here? I'd prefer it at the top of the file where it was.


DISABLE_PYTHON doesn't seem to be used anywhere else - no clue why it was there.


gcc wanted it for the printf at line 203.


Having the functions inside the KX_PythonInit module doesn't reduce the size of the patch much compared to all the noise generated from the gp_KetsjiEngine -> KX_GetActiveEngine() substitution. We could break encapsulation and declare gp_KetsjiEngine/Scene extern, allowing KX_PythonInit special treatment (its the only module that accesses the global vars directly - the other modules seem to use the proper get/set functions).


Locality reasons - class KX_KetsjiEngine isn't referenced anywhere else but in the following line.

Campbell Barton (campbellbarton) requested changes to this revision.May 18 2015, 11:47 PM

This patch isn't applying for me

Applying patch source/gameengine/Ketsji/KX_PythonInit.cpp with 6 rejects...
Applying patch source/gameengine/Ketsji/KX_GameObject.cpp with 1 reject...

This revision now requires changes to proceed.May 18 2015, 11:47 PM

This patch isn't applying for me

Which branch are you patching against?

Hello. Please, could you use arcanist to send patches ?

This has become obsolete with the changes in the UPBGE branch. Closing