GemRB on Playbook

[drosketer]

First, kudos on what is a huge effort on bringing back, or keeping, these gems alive. I remember playing the originals, then TuTu mods, and now am hoping to port it over onto a RIM Playbook. Has anyone managed to do this?

 

The Playbook is rooted and I pulled down GemRB 0.6.6 off the Android market (waiting for the 0.7 update). Also pulled down alogcat. Currently, just starting up GemRB immediately shuts it down. So assuming that this hasn't been done, I will probably be needing some future help. I am running 2.0.0.6149 version of the OS.

 

In the absence of any IE games installed on the tablet, what should I expect on starting up GemRB?

 

Thanks in advance.

[lynx]

just a bunch of lines in the log and then termination. So far so good, unless you also downloaded the bg2 demo.

[drosketer]

Thanks. Haven't downloaded the demo yet, but will do and report back should anything unusual happen... any guesses on when 0.7 will appear on the market, or should I just proceed with trying to move the BG installation and upgrade later?

[lynx]

You can get a simpler 0.7 build already, it is linked in the announcement topic and can also be manually found on sourceforge.

[drosketer]

Okay, spent some time finding, installing, and patching the source materials for the games. Also decided to download the latest apk from sourceforge and convert it, along with aLogcat from apk to bar files and install them onto the PlayBook (GemRB and aLogcat only at this point since I want to try modding the game files before trying to get them to work on the PB.

 

Looks like I get a little further now when running GemRB, but still end up with a forced shutdown. Here is what I get from aLogcat if I filter on gemrb:

 

 

I/Instrumentation(4800659): invoking onCreate() for Activity net.sourceforge.gemrb.MainActivity

I/System.out(4800659): libSDL: loading lib /data/data/net.sourceforge.gemrb/files/../lib/libsdl-1.2.so

D/dalvikvm(4800659): Trying to load lib /data/data/net.sourceforge.gemrb/files/../lib/libsdl-1.2.so 320aa10

D/dalvikvm(4800659): Trying to load lib /data/data/net.sourceforge.gemrb/lib/libsdl-1.2.so 320aa10

W/dalvikvm(4800659): No implementation found for native Lnet/sourceforge/gemrb/AudioThread;.nativeAudioInitJavaCallbacks ()I

D/Finsky (4911123): [1] InstallStateVerifierRule.run: Version mismatch for net.sourceforge.gemrb, installed=643 asset=660

E/qnx.Launcher(3682440): launching uri android://net.sourceforge.gemrb/%3Factivity-name%3Dnet.sourceforge.gemrb.MainActivity%26dname%3Dnet.sourceforge.gemrb.gYABgNbPZANXky8ADttiw9Tc20I%26perimeter%3D

D/Install@Launch(4923537): net.sourceforge.gemrb is already installed, validating digest ...

D/Install@Launch(4923537): Validated digest successfully for net.sourceforge.gemrb.gYABgNbPZANXky8ADttiw9Tc20I

I/Instrumentation(4935830): invoking onCreate() for Activity net.sourceforge.gemrb.MainActivity

I/System.out(4935830): libSDL: loading lib /data/data/net.sourceforge.gemrb/files/../lib/libsdl-1.2.so

D/dalvikvm(4935830): Trying to load lib /data/data/net.sourceforge.gemrb/files/../lib/libsdl-1.2.so 320abb0

D/dalvikvm(4935830): Trying to load lib /data/data/net.sourceforge.gemrb/lib/libsdl-1.2.so 320abb0

W/dalvikvm(4935830): No implementation found for native Lnet/sourceforge/gemrb/AudioThread;.nativeAudioInitJavaCallbacks ()I

 

Is that what I should be getting? If it isn't, I am debating whether to hold out until OS2 is officially released in the next month or so.

[alx3apps]

Seems like some audio problem. Try to set

AudioDriver = none

in GemRB.cfg

 

If it wouldn't help, try this version (without audio support) - http://www.mediafire...7b2be6bxz2mv04w

 

If it wouldn't help either, please post full alogcat log to pastebin or something, it may help Beholder to investigate this problem. It seems, RIM has its own view of android.

[scriptedfate]

Is that what I should be getting? If it isn't, I am debating whether to hold out until OS2 is officially released in the next month or so.

 

Why wait for release? If you're going for 'convert the Android apk' route, you can do that and test it right now: https://bdsc.webapps.blackberry.com/android/ (Note that this will also require that you either run the 2.0 beta simulator or the 2.0 developer beta build on device in order to run the resultant bar)

 

Personally I'm trying to investigate the 'build natively for PlayBook' option. I've finally got my dev environment set up and have built the PlayBook's SDL 1.2. Now I need to add the project files to the source tree and get gemRB building in the IDE.

[drosketer]

I mentioned that I am running version 2.0.0.6149 in the first post, but aside from that, I think you have the right idea in compiling it all using RIM's development kit rather than just trying to convert the apk... no idea if the underlying dependencies are in place. It probably doesn't help that I am mostly Unix illiterate though.

 

I'll try and update the .cfg file later today.

[lynx]

just a note: don't forget cmake can generate various project files for you. It depends on the platform though, so it is important where you invoke it.

[scriptedfate]

just a note: don't forget cmake can generate various project files for you. It depends on the platform though, so it is important where you invoke it.

 

How do you mean? There could be a Momentics project file kicking around already that I just need to configure into existence? Is this documented?

[drosketer]

Also, it looks like the beta version of the Blackberry 2.0 SDK is available. I will try and get that set up on the pc later tonight.

[lynx]

Momentics? I doubt it, sounds too niche.

[drosketer]

Hah, well, NDK 2 is installed but since I haven't worked with a C compiler in some time (since '98 I think) this is going to take a while. Ran into a make error on first attempt which, best I can tell, is related to not having the various make rules in place which define the order in which to build... like I said, it'll be a while. The joys of learning.

[scriptedfate]

I'm a few steps ahead of you.

 

You'll run in to problems getting cmake to work, as it doesn't really have a facility to cross-configure (you're not compiling on PlayBook for the PlayBook, so you'll need to cross-compile. cmake generates config.h (an evil thing which is used everywhere) which is needed to compile). To fix this, find or generate a config.h for another platform and stick it in a path that you can add to your includes.

 

You'll have to dig up QNX ports of Python (unmaintained) and SDL (maintained). And possibly vorbis, SDL_mixer, SDL_ttf and others.

 

Then you'll run into a problem where QNX is strict about putting all the c++ stdlib functions in the std namespace and not the global one (where other platforms tend to put them in both). The only way I found out how to fix that was by modifying 113 files to include 'using' directives. I'm still trying to figure out the 'why', though, and I work on a similar project that _doesn't_ have this problem, so I'm still hopeful that I can find a directive or define that'll save that ridiculously-disruptive change.

 

Then you'll notice that strndup isn't guaranteed to be on every platform (like, say, QNX) and will need to be replaced. (Only one instance, so not a biggie)

 

Oh, and you might notice by now that all of the plugins are supposed to be compiled individually into shared objects so that you need not worry about a lack of SDL_mixer or SDL_ttf (or that pesky vorbis from above). This will make you wonder if Momentics supports multiple deliverables per project (I haven't yet found such a setting) or whether you'll need to split each into its own project (this is my fear. Though it should compartmentalize things better for compiling and whatnot, I weep to think of the .project files that this will generate and where I will have to put them).

 

Then there's other stuff that needs to be fixed in order to get this to compile. Then you'll not want this to happen again so you'll want to configure a build-slave to auto-build for QNX and complain _very_ _loudly_ whenever someone does something that's non-standard, but acceptable, when developing for another platform. Then you'll realize this requires learning the CLI bbndk tools.

 

Then you'll have crawled across a lot of the code and start wondering why it's doing some things one way and others another. Why all the std::str* calls? Why not use std::string and std::stringstream and all the other wonderful things that C++ provides so you need not mess about so much? Why are there `alloc`s but no `free`s in header files and `free`s but no `alloc`s in .cpps? Why is there an implementation for a string-string map when it's a solved problem in the STL?

 

And then you'll realize that you're hooked, and there's no going back

[scriptedfate]

And then you'll realize that it's a compiler problem. Switch qcc cross-compiling version flag from -V4.4.2,gcc_nto<arch>_cpp to -V4.4.2,gcc_nto<arch>_gpp and it goes away. Why does it make a difference using the general-purpose preprocessor instead of the C/C++ preprocessor? I have no idea.

 

@#$^& pre-processor (@#$^&(@#$ cross-platform ^&()@#$^&)@ ANSI #$^&()#$^ std:: &(@$^&(@$^!!

 

Now I need to figure out how to do this in the IDE so I can continue having it manage the build (or not. Commandline build is acceptable. Same with External Tool Build. Then I could keep gemrb a single project and have the external build take care of generating the plugins' shared objects... hmm...)