Android

[TheExDeus]

I think it should be now possible to compile without Java boilerplate. Just like the link Rusky gave mentions. You can use GCC directly to compile for android.

[sorlok_reaves]

I think it should be now possible to compile without Java boilerplate. Just like the link Rusky gave mentions. You can use GCC directly to compile for android.

That's only to compile the JNI part. To actually distribute an APK, you'll definitely need some Java source. Even the article mentions it, in the section "Simple Example"

Here, we can see:

  - The 'src' directory containing the Java sources for the sample Android project.

  - The 'jni' directory containing the native source for the sample, i.e. 'jni/hello-jni.c'

I am nearly certain that networking can't be done in JNI code (only Java), and I think Android Ad Services have to run in Java too. Also, the main JFrame must be created in Java.

Edit: This might be a better example; it's a tutorial on using SDL on Android. They basically provide all the boilerplate for you so that you can minimize the Java code you have to write (you just define an sdl_main method, which is in JNI).
http://blog.stuff-o-matic.com/post/2013/10/20/ASGP-s-Android-Port-Part-IV%3A-building-the-APK

[daz]

I'm just gonna throw this out there: would it be better to try to get the ndk-build script to compile all of Enigma? I don't know if it's possible to get the Android.mk file to (a) Compile other makefiles, or (b) compile source code that is not inside of a "jni" directory.

I'll look into this more myself once I'm feeling a bit better, but this might be a better solution than trying to deduce by what black magic the linker links.

[Josh @ Dreamland]

Isn't there a guide anywhere on building manually? Or by any other mechanism than .mk? I mean, I believe I remember you reporting that you have it building all the object files, except some that had libstdc conflicts. Did you get that resolved? That's *most* of the battle. Linking should be the easy part, and whatever goes into it can be accomplished in the ENIGMA makefile using a custom rule, as I described earlier.

[daz]

There really isn't a guide on building manually, and the documentation included in the NDK is very sparse.

The only thing I can think of right now (after some more toying with this) is that SYSROOT might have to be defined earlier in the compile process than the Android makefile. I have no other idea how mingw's libstdc++ files are being included.

My only other guess is that the make.exe I am calling is not using the correct GCC. It smells suspiciously like it's using mingw instead of the ndk... but I have no idea how to prove or fix that.

[Josh @ Dreamland]

A quick way to test that is to call it with -v.

[sorlok_reaves]

You can also temporarily rename your MinGW directory (or unlink it from the path) and see if make.exe complains.

[daz]

You can also temporarily rename your MinGW directory (or unlink it from the path) and see if make.exe complains.

The Enigma plugin does not load if it cannot find make.exe.

A quick way to test that is to call it with -v.

Ah well apparently it is using the right one when attempting an Android compile (by the way interesting the way Enigma works in this regard!)

C:/android-ndk-r8e/prebuilt/windows-x86_64/bin/make -v

Any other ideas?

[Josh @ Dreamland]

Actually, no, and none of the people I work with actually work on Android, so even after hours I can't solicit their help for you. The -v was for gcc, so you can tell if it's calling the right one. But since you already know it is, there's no point. What are you stuck on now, apart from linking? I thought that's where the big issue is, and that's what I don't know how to do. Google results for "link android app" are monumentally unhelpful; they seem to assume that you're writing in Java, so GWS ends up thinking "link" means "hyperlink."

[sorlok_reaves]

Since everyone's out of ideas, here's a far-flung one (this is probably what I'd do if I was totally lost).

Compile one of the NDK example projects in Eclipse with verbose output on. Then, find the line (in the Console) that does the linking and try copying that for your own project.

[Josh @ Dreamland]

Unfortunately, as I understand it, all the linking is done internally by some Android build tool that works with .mk files. The example mk files are, as usual, a labyrinthy maze of short yet impossible-to-read files of use to fucking no one. And the tool doesn't have a "verbose output" mode. So we have no idea what's going on.

Conceivably, someone could just grep over all mk files for anything resembling a link call, but I haven't tried.

[daz]

An update for those interested, I determined Enigma was calling the wrong compiler when compiling for Android and with the help of Josh we tracked it down to my broken Android.ey file.

Now the problem we have is that apparently the Android g++ fails to invoke cc1plus when compiling Enigma. Even trying to manually compile 1 file fails. I will try manually compiling one of the NDK samples later in this manner to see if it results in the same error. If it does... there is some serious black magic going on behind the scenes.

EDIT:
Further update... the gcc binaries being in a non-standard place did not know where to look for cc1plus. I switched to using the standard bin directory with ugly-named gcc binaries, but compilation started!

The new problems I have are compilation problems. Mainly, OpenGLES is just screwed. It hadn't been updated in who knows how long, and a lot of Enigma's structure has changed in that time. I have been plowing away it it, but I fear I am in way over my head at this point. Fixing compilation errors results in other compilation errors! I will torture Josh if he is on IRC tomorrow (today?).

In the mean time, such fun errors include...

Code: [Select]

./Graphics_Systems/OpenGLES/../General/GSfont.h:36:42: error: 'variant' has not been declared
./Graphics_Systems/OpenGLES/../General/actions.h:47:9: error: 'object_planar' is not a member of 'enigma'
./Graphics_Systems/OpenGLES/../General/actions.h:249:69: error: 'background_replace' was not declared in this scope
./Collision_Systems/actions.h:28:103: error: 'struct enigma::inst_iter' has no member named 'inst'
./Graphics_Systems/OpenGLES/../General/GSscreen.h:29:8: error: ambiguates old declaration 'void enigma_user::screen_redraw()'
c:/androidtoolchain/lib/gcc/../../include/c++/4.6/bits/basic_string.tcc:221:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::basic_string<_CharT, _Traits, _Alloc>::size_type, _CharT, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = unsigned int]
c:/androidtoolchain/lib/gcc/../../include/c++/4.6/bits/basic_string.tcc:221:5: note:   candidate expects 3 arguments, 1 provided

And so much more! OpenGLES may have to be rewritten from the ground up! I also propose the starting of OpenGLES2 as a separate and shiny new Graphics subsystem! (Hell, maybe we ditch GLES1 entirely!)

[TheExDeus]

GLES never worked, so it will have to be rewritten anyway. But the new GL3.3 code is 95% compatible with GLES2.0. So I would suggest you to do this:
1) Make /platforms work with Android (this is probably the cause of the errors you are seeing. They are not connected to the rendering system).
2) Make simple GLES implementation just to render an empty screen. This would mean that all other systems are working fine and that the only thing to do is rendering.
3) Then copy GL3.3 to GLES2.0 folder and fix all the rest of the warnings/errors that come up. Debug context might help.

I sadly still haven't fixed and committed my GL3 changes. I fixed a lot of stuff and removed a lot of incompatible functions, but it crashed when I merged and I didn't have time to figure out why.

But the fact that you actually got it to start compile is a great step forward. You should document the steps you took so others can replicate. Either in this topic or wiki.

[daz]

I would like to push a commit first. After I can get a lib successfully compiled and run it on Android with a blank screen I'll send in a pull request and update the wiki. If anyone is serious about developing Android before then I'm willing to outline the steps here.

EDIT:
Wrote up the process on the Wiki ( http://enigma-dev.org/docs/Wiki/Android ). This process assumes that you are working with ENIGMA which has support for Android. As I have not yet pushed a commit, nothing will happen yet!

Also last night Josh and I got the whole thing compiling happily after much bashing of heads against desks. It seems the linking part fails though. Homestretch? I've also basically deleted the entire OpenGLES and plan to work on it from scratch. After it successfully builds a .so and I can verify it works with the Android project file, I will update the wiki with more information and create a pull request.

ENIGMA will still not be able to create complete Android games for some time, but progress is progress.

[sorlok_reaves]

Wrote up the process on the Wiki ( http://enigma-dev.org/docs/Wiki/Android ). This process assumes that you are working with ENIGMA which has support for Android. As I have not yet pushed a commit, nothing will happen yet!

Thanks for doing this. I'll go through it at some point, as I hope to eventually get Iji working on Android. Good work so far, and good luck with the rest!