Multiplatform support

There’s something I don’t get. I’ve noticed a lot of other open-source game engines seem to easily support iOS/Android/etc. such as GameKit, Irrlicht, Urho3D etc. I know the BGE doesn’t have as many developers as other game engines, however what are the technical reasons? What comes to mind are:

  • Lack of Open GL ES support in Blender? (I think GSOC project addressed this)
  • Blender’s usage of Python -> Issues with Python on Android and iOS.
  • Apple’s Stores incompatibility with GPL

Although, overall multiplatform support seems to be a PITA since every platform has its own type of API. For general software and cross-compiling it’s always a PITA but even more so for games/game engines. There’s open standards but generally proprietary companies don’t care much for them. I see how Unity can be really attractive (publish to 10 platforms). In light of what Valve is doing with embracing Linux/FOSS and the Steambox/SteamOS, it seems like this might be a moot point in the future.

It is actually a question of who BGE is aimed at. Mobile platforms simply aren’t in the scope, and never have been. Blender is computer software, not mobile software. Unless something in the upcoming 2.7 version drastically changes, there probably never will be mobile support in blender or BGE.

Lack of Open GL ES support in Blender? (I think GSOC project addressed this)

Yeah, this could be added, but I think it’s outside of the scope, as I said earlier.

Blender’s usage of Python -> Issues with Python on Android and iOS.

I view this lack of dependency resolution a failure of Android/IOS platforms. Heck, even windows hasn’t got it sorted beyond telling you asdf.dll is missing. Software should be able to tell you what libraries it needs, and when OS developers recognize that, the world will change. (Ever use a linux distro? They’ve got this one sorted.)

Apple’s Stores incompatibility with GPL

Once again this is a problem external to Blender Game Engine.

For BGE games to run on any given platform, Blender must provide an export scheme that produces binaries for that platform.

The engine is written in C++, so most of the code can just be compiled for the target in question, but you would also have to add some code (likely under an #ifdef PLATFORM) to interact with the underlying system, because libraries for that are different on mobile, and come with their own API … However, if you were to use SDL2, which supports many mobile platforms, it’s likely that you wouldn’t have to do anything, because that code is already there.

Python is a non-issue (for the most part): The basic interpreter is just C code, which can be compiled with the relevant C compiler.

OpenGL ES is just a subset of OpenGL, and one that has pretty decent parity with regular OpenGL, especially if you’re using the latest versions (which are stated to be fully compatible), so I think that changes in the rendering subsystem would be fairly minimal.

Of course, there’s a big difference between knowing how something could be done, and then actually doing it, which requires quite a bit of time and effort … And honestly, even if I had those resources in abundance, I would be reluctant to spend them on porting the BGE, because there are far more important things than just additional platform support.

Ah, SDL. Unfortunately, I’m not so familiar with the low-level details, thus this thread. I’ve been reading about it and a lot of game engines seem to rely on it. How come Blender doesn’t rely on it so much (to my knowledge)? I know of the cmake flags for SDL but Blender uses native libraries when possible, for speed?

It seems like SDL/middleware is trying to cover everything and ends up becoming “jack of all trades, master of none”. On the other hand, you can combine specialized/native libraries such as Win32API/DirectX, PortAudio, OpenAL, OpenGL, etc. and build your own API to achieve the same goal; I think this is what Blender does as SDL seems to be lacking:

GHOST is a C++ class which handles OS specific interactions (windowing, opengl initialization, mouse/kb events)

The drawing is done in OpenGL so GHOST really doesn’t have to do all that much.

It solves similar problems as SDL and infact SDL could probably replace GHOST however their multi-window support isn’t as good (Gives opengl context switching issues, they know about this), and AFAIK SDL doesn’t handle tablet events.

  • So we continue to use GHOST :slight_smile:

Since the BGE has limited resources, it seems better to focus on properly supporting the established “big 3” platforms (Win/Mac/Linux) than the less stable mobile platforms like Android and iOS. It follows the idea of lots of features with shallow implementations versus a few well-supported stable features.