Jump to content

Comming from Android programming: how can I help


qnestor

Recommended Posts

Hello all,

 

I was thrilled when I stumbled upon this project which I found listed as one of the top android open source ones. I am an android developer, and wanted to check the code out of curiosity.

 

I can see that it is done in C plus some scripting, then android ndk. Checking the help welcome section I did not find anything specific for android. My question is, is there anything that android developers can help with?

 

I got the source code but I'm unable to have the whole android project built , when I use ndk-build to compile the libraries I get:

 

 

Compile++ thumb : main <= SDLVideo.cpp

jni/src/main/gemrb/plugins/SDLVideo/SDLVideo.cpp: In member function 'virtual int GemRB::SDLVideoDriver::ProcessEvent(const SDL_Event&)':

jni/src/main/gemrb/plugins/SDLVideo/SDLVideo.cpp:191:43: error: 'const SDL_Keysym' has no member named 'unicode'

make: *** [obj/local/armeabi/objs-debug/main/main/gemrb/plugins/SDLVideo/SDLVideo.o] Error 1

 

 

But maybe I can sort that out later. In any case, I don't know that to look at after it's built since most will be c libraries.

 

 

BTW, I had to add some lines in prep_env.sh because prior to the line:

 

cp "$GEMRB_GIT_PATH/artwork/gemrb-logo-glow-36px.png" "$ENVROOT/build/gemrb/res/drawable-ldpi/icon.png"

 

the build/gemrb/res folders were not created. Is that an error in the file?

 

Thanks all in advance

Link to comment

your code is out of date; that error is from an SDL2 API change and was fixed in git. the android build script may need updating too tho, since several new source files were added recently. lots of other SDL changes to the android files may require (or you would benefit from) some work with the gemrb java activity file.

 

as You have discovered one of the things you can do to help with android is fixing up the android buildscript.

 

one thing that would be great for the android version is if you could construct a configuration GUI of some kind; people really struggle with the cfg file.

 

other than that, there isnt really anything android specific, but if you know opengl we could always use that.

 

Edit: well since i only have an iOS simulator for testing touch input you could probably do better and reproducing some reported touch input bugs and fixing them.

Link to comment

I agree with lynx' assessment, the changes SyntaxError is referencing are rather tiny and obvious; I'd just been away from the project for a bit.

 

The README in the android subdirectory seems to be decent to get you started, the TODO has a few things I'm about to start working on during the next few weeks.

 

We should definitely coordinate our efforts, but my experience with developing for Android is rather limited. In any case, I'm available for questions.

Link to comment

Thank you all,

 

Yes I had source from sourceforgenet, so those problems were gone after getting the current version from github.

 

one thing that would be great for the android version is if you could construct a configuration GUI of some kind; people really struggle with the cfg file.

 

Do you mean a GUI so the users can load their games and then launch them without editing the .cfg file?

Are iPhone users also struggling with this? If so maybe the solution shouldn't be android specific but cross platform (mobile)

 

 

Anyways some details for the willing :

 

I still found a detail in gemRB.java file, it references a library that doesn't exist:

 

android.content.Environment (should it be import android.os.Environment ?)

 

Then line 52 assumes this:

 

Environment.getExternalStorageDirectory()

 

After modifying and compiling i could not get gog iwd2 to work, but i could with google play's version. I wonder what android SDK was used to compile the version that is on google play?.

 

Doing this I 'broke' a cheap android tablet (manta brand that costs like 40 dollars) because when you store over 1.5 gb in it it starts having memory issues, and I'm not allowed to hard reset it :/. Tonight I'll try on emulators and on tablets as soon as I get a new one.

 

 

 

If my testing goes well and I am able to contribute something significant I'll write here. I haven't used github yet and I've never participated in any open source project :s

Link to comment

one thing that would be great for the android version is if you could construct a configuration GUI of some kind; people really struggle with the cfg file.

 

Do you mean a GUI so the users can load their games and then launch them without editing the .cfg file?

Are iPhone users also struggling with this? If so maybe the solution shouldn't be android specific but cross platform (mobile)

 

SyntaxError already wrote an iOS configuration GUI, as far as I know. Of course cross-platform solutions would be nice and I think there was talk about building something in-engine, but I neither remember details nor what came of the idea.

 

In general, we want a configuration screen similar to the one on the Google Play version - the current git HEAD has nothing of that sort, because we took a step away from pelya/commandergenius' build environment and are maintaining our own setup script instead now. Of course we then have the freedom to add more things, like saving different configurations and so on.

 

I still found a detail in gemRB.java file, it references a library that doesn't exist:

 

android.content.Environment (should it be import android.os.Environment ?)

 

Then line 52 assumes this:

 

Environment.getExternalStorageDirectory()

 

It seems I missed to correct the import with the latest pull request.

I'm not sure what you're refering to with line 52; getExternalStorageDirectory() is in the pull request. In any case, glad you could work it out.

 

After modifying and compiling i could not get gog iwd2 to work, but i could with google play's version. I wonder what android SDK was used to compile the version that is on google play?.

 

I think the Google Play version is compiled with Android SDK 12, but I'm not sure and can't check right now. The Google Play version also is compiled against some hacky mix of SDL1.2 with a bunch of changes backported from SDL2, but that shouldn't really be a problem I assume. Did you check logcat output? On first sight it seems like you didn't supply a config file, but "couldn't get it to work" isn't that much to go on. The app extracts a template configuration file to $INTERNALSTORAGE/files/GemRB.cfg, this might be something like /sdcard/Android/data/net.sourceforge.gemrb/files/ or /sdcard/app-data/net.sourceforge.gemrb/files depending on your Android version.

 

 

 

To summarize, we'd need a wrapper Activity around the current GemRB.java which deals with editing and managing configurations files (potentially other engine settings as well if that ever comes up) and tries to ensure a working confguration file (as in, directories exist at least, maybe check for right files). We don't have that anymore (in contrast to the Google Play version) because we switched the SDL dependencies from a non-official mix of SDL1.2 and SDL2 to upstream SDL2.

 

The fact that we don't have any configuration screen is most likely also the reason, why you couldn't get IWD2 to run.

Link to comment

The problem of doing it in-engine is that a lot of the configuration stuff needs to happen very early or before the start and classical game resource stuff needs half to engine loaded to work. It would be possible with another thin client using the same plugins, but I'm sceptical we could tie in all the platform specific details.

Link to comment

Hello,

 

Sorry I didn't write what I intended, I meant that:

Environment.getExternalStorageDirectory() - returns a File , but in the gemRB.java file I had it assumed a string. I think it should just call getAbsolutePath() after and it's good to go.

 

 

I think the Google Play version is compiled with Android SDK 12, but I'm not sure and can't check right now. The Google Play version also is compiled against some hacky mix of SDL1.2 with a bunch of changes backported from SDL2, but that shouldn't really be a problem I assume. Did you check logcat output? On first sight it seems like you didn't supply a config file, but "couldn't get it to work" isn't that much to go on. The app extracts a template configuration file to $INTERNALSTORAGE/files/GemRB.cfg, this might be something like /sdcard/Android/data/net.sourceforge.gemrb/files/ or /sdcard/app-data/net.sourceforge.gemrb/files depending on your Android version.

 

With the build I did, I did supply game data and cfg file (those were the first errors). The last errors I saw were: first some files were missing in files/GUIscript on gemRB data folder, then after adding manually I saw NPE's on GUIScripts/bg1.. weird because I set the cfg file to iwd2. But I didn't want to go into this since I didnt test enough - the tablet broke- but I will, and will see about the GUI config.

 

From what I know a wrapping activity can work like a charm on android going as far as select your game and play, exporting characters, savegames, etc. and even detecting wrong game data prior to the engine. So a demo try may as well be good to illustrate things till you guys decide if in game, crossplatform, etc

Link to comment

Sorry I didn't write what I intended, I meant that:

Environment.getExternalStorageDirectory() - returns a File , but in the gemRB.java file I had it assumed a string. I think it should just call getAbsolutePath() after and it's good to go.

Yes, that definitely makes sense; the latest few patches were a bit rushed on my part, which explaines the two errors you found and corrected.

 

I think the Google Play version is compiled with Android SDK 12, but I'm not sure and can't check right now. The Google Play version also is compiled against some hacky mix of SDL1.2 with a bunch of changes backported from SDL2, but that shouldn't really be a problem I assume. Did you check logcat output? On first sight it seems like you didn't supply a config file, but "couldn't get it to work" isn't that much to go on. The app extracts a template configuration file to $INTERNALSTORAGE/files/GemRB.cfg, this might be something like /sdcard/Android/data/net.sourceforge.gemrb/files/ or /sdcard/app-data/net.sourceforge.gemrb/files depending on your Android version.

 

With the build I did, I did supply game data and cfg file (those were the first errors). The last errors I saw were: first some files were missing in files/GUIscript on gemRB data folder, then after adding manually I saw NPE's on GUIScripts/bg1.. weird because I set the cfg file to iwd2. But I didn't want to go into this since I didnt test enough - the tablet broke- but I will, and will see about the GUI config.

Did you delete the subdirectories below gemrb/android and rerun prep_env.sh after you migrated to github? Missing python files indicates that you have old versions of the GUIScripts folder - prep_env.sh copies the folders from the gemrb repo to include them in the .apk so users don't have to worry about having the right version of GUIScripts, unhardcoded and override for gemrb. This, of course, means that developers have to worry about that.

 

As for the NPE, that seems like it might from the extraction process, although I don't quite see why it would NPE there; I'd like to look at a backtrace if you still have it handy.

 

Otherwise, just delete the subdirectories below gemrb/android and rerun prep_env.sh. You probably should insert your corrections into GemRB.java inside gemrb/android, seeing as that file gets copied during prep_env.sh, so you don't have to edit inside it inside the build environment every time.

 

From what I know a wrapping activity can work like a charm on android going as far as select your game and play, exporting characters, savegames, etc. and even detecting wrong game data prior to the engine.

 

That's my impression as well, and is also how the Google Play build handles much of it.

For reference, this is the build environment for the GemRB build that's currently on Google Play. This folder contains most of the java files pertaining to the build environment, which might be useful as a reference.

Link to comment

qnestor: another helpful thing for somebody looking to improve the Android experience would be to track down and fix this

 

About the GUI config: what lynx said :p

 

also there are nasty platform specifics to account for like how iOS you can just copy the Game from your pc to some random location so the GUI for iOS allows you to upload a zipped Game and then it will decompress it and create a cfg file for you. Other than that the iOS gui is just a listing of different cfgs for selecting and playing different games with a text editor for changing options. pretty basic.

 

the mac GUI is much more rich (tho perhapps limited) in that it utilizes actual GUI controls (checkboxes, radios, etc) to configure gemrb.

 

either approach would be suitable and both solve the primary problem people have of not knowing where the cfg file is/should be. I prefer the more rich GUI, but that is considerably more work (which is why the iOS GUI is still text based)

Link to comment

Hello Again,

 

Sorry for the absence, it's hollidays time around here.

Anyways I'm still interested in this, so I am resuming. To be clear: I have no issues with cfg files with the Googgle Play version, I run good IWD2, BG1 and BG2 demo. The problems I was having was with the build made from what's in github.

 

Now, I can't build with the current repo. Executing prep_env I found these:

 

- can't read .../gemrb/android/build/gemrb/jni/SDL/src/main/android/SDL_android_main.cpp

(I checked http://hg.libsdl.org/SDL, and the downloaded file. It seems to be SDL_android_main.c)

 

After renaming I found a similar issue with:

 

cp "$ENVROOT/libogg-vorbis-android/libs/armeabi/libogg.so"

(similarly to the previous, I don't see a libs folder from the cloned site: https://github.com/jcadam/libogg-vorbis-android)

 

 

So am I doing something wrong? I'd appreciate any help getting this to build so then I can focus on that wrapper activity.

 

 

oh also, the ndk-build commands are not always recognized if you just download the ndk like i did.

I don't know if I'm bothering with these messages in the forum, should I PM someone?

 

Thanks!

Link to comment

Where did libogg.so get built in instead? Maybe sdl renamed that file in the meanwhile, though that's pretty odd.

 

About the ndk, I have no idea., but can you be more specific?

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...