[Mnemonic]

Hey folks, I was just wondering if there's anyone interested in adopting and maintaining a Linux build of WME Lite. It shouldn't be terribly hard, it's mainly about compiling the dependencies and preparing build files. Perhaps also preparing some way of distributing the games using WME Lite.

Sadly, I have zero experience with Linux development myself (last time I used Linux seriously was in the late 1990s ) and I don't have time delve into it right now. But maybe you know of some skilled Linux developer who would be interested in helping with the project (or maybe you are one!). If so, please point them in this direction

[HCDaniel]

Hi Mnemonic,

I can give this a try when I'm finished pushing all my WME1 changes to you. I'm not too good at creating Makefiles or "./configure" scripts, but usually I get stuff to compile sooner or later So if nobody else steps up who has more experience in creating a proper Linux source package and handling dependencies in the right way, I can take a look.

[Mnemonic]

That would be awesome!

[2.0]

Do I understand correctly that this is a little step in the direction of Android?

[HCDaniel]

Hi Mnemonic,

I tried it the quick and dirty way, WME lite compiles for Linux (tested on Ubuntu 12.04 32 bit).

The compiler emits a lot of warnings. The one warning about "typedef ignored" I cannot silence without a source code change, so can you please apply commit 27cf77c from the forked version if it does not break the other builds?

Then there are a lot of warnings about using string literals which are passed to functions that do not define the character sequence as "const" - these I can switch off easily. I don't think you want to go through the painful process of fixing that

Some more warnings appear that NULL is assigned to a non-pointer type - I switched them off as well. These would probably be easier to fix (and there's only a couple of them), but I don't know whether it is worth the effort.

The rest of warnings is here:

Code: [Select]

./BGame.cpp:4758:7: Warnung: mehrere Token am Ende der Direktive #else [standardmäßig aktiviert]
./BGame.cpp: In Elementfunktion »virtual HRESULT CBGame::ScCallMethod(CScScript*, CScStack*, CScStack*, char*)«:
./BGame.cpp:2088:32: Warnung: Format »%x« erwartet Argumenttyp »unsigned int«, aber Argument 3 hat Typ »crc {aka long unsigned int}« [-Wformat]
just FYI. Nothing serious I would say.

I tested the sample game, I could play it but it segfaulted on exit. I'll see whether that is in WME or one of the libraries.

[Mnemonic]

Thanks! I went through the warnings and fixed most of them (unused entities, missing braces, the #else you mentioned and others). I disabled the unused switch values and "conversion from string literal to 'char *' is deprecated" warning.

[Mnemonic]

Do I understand correctly that this is a little step in the direction of Android?

I don't really know, to be honest. Even though Android is based on Linux, I don't know how similar the toolchain is.

[HCDaniel]

Android is more difficult. SDL exists (and compiles), BASS exists. What's missing are freetype, freeimage and boost libs, which have to be provided for that platform.

I tried to compile as much as possible of WME lite for Android (without linking), just by providing the necessary include files. The freetype and freeimage headers are ok, but the boost headers don't work. I'll check the error message in detail soon. EDIT: Looks like Android does not understand "std::runtime_error"?

Furthermore, Android native C++ code does not like (or not support at all, I'm not sure) C++ exceptions (maybe because it's too difficult to pass them to Java in case the exception is not caught in native code). So the compilation of SXString.cpp fails. I haven't checked the code whether it is possible to live without the use of exceptions in WME lite, if just for the Android platform.

Mnemonic, what's your opinion about C++ exceptions, and do you think you can get rid of the boost library anytime soon?

[Mnemonic]

Even though the android NDK didn't originally support C++ exceptions, they are now supported (since NDK R5). According to this they need to be explicitly enabled (I don't know if it's still the case with current NDK).

As for boost, yes, my plan is to remove this dependency. It would simplify a lot of things. Can't give you any timeframe, though

[Mnemonic]

For now, this looks useful: https://github.com/MysticTreeGames/Boost-for-Android

[HCDaniel]

Hi Mnemonic,

thanks for the hints. With exceptions enabled, the STL target and the boost-for-android headers I can now compile all source files for Android. Now I need to find appropriate references (and time) to generate libfreetype and libfreeimage for Android. Then I can see whether it'll link And finally I will have to check how to glue SDL to WME of course, on Android there's no main().

[HCDaniel]

Hi Mnemonic,

how does WME lite search for the game packages? In Android, I cannot simply add them to the "current" directory, so I would have to specify a dedicated path. I would want to supply this as an argument to WME's main(), so how can I do that?

[Mnemonic]

WME maintains a collection of search paths. The collection is filled in CBFileManager::InitPaths(). Currently WME Lite adds the current directory ("./") and on OSX/iOS it adds the application bundle path.

I have zero experience with Android. Does it have a concept similar to Mac app bundles?

[HCDaniel]

Ok, so for the moment I hardcoded "/mnt/sdcard/" so that I could at least run the demo project.

Android has several ways to supply resources, but once you hit the 50MB limit you can no longer ship it as one package (at least when installing via the play store). For that, Google has introduced "expansion files" which will be downloaded when you install the app.

Long story short, in the end your Java app wrapper knows where your files are supposed to be, so you need to get that information to WME. How about adding this to the arguments of main() in some way?

[Mnemonic]

Ok, I'm not sure I follow here. How will main() get the information, from where?
Isn't there some API function that returns the path where application data is stored? I did some quick search and couldn't the nativeActivity->externalDataPath property be used for the purpose?

In any case, in WME Lite the command line arguments are parsed in CBPlatform::Initialize().