|
time-killer-games
|
|
Reply #1 Posted on: July 21, 2014, 02:11:10 pm |
|
|
"Guest"
|
Are you actually going to expand what ENIGMA's android can do atm or are you just bug reporting so you can fiddle with the capability of the android port's current state?
|
|
|
Logged
|
|
|
|
|
|
|
daz
|
|
Reply #5 Posted on: July 21, 2014, 06:37:25 pm |
|
|
Joined: Jul 2010
Posts: 167
|
He probably wants to get the dropbox in the settings panel working now.
Yes this is what I was originally asking. How else can I even try to get Enigma to attempt to start a compile process? I plan to work on a lot of Android if I can. I don't know much of Enigma's architecture so there's a lot I will need help for (e.g. from Josh). TGMG had a long time ago started some basic functionality. A lot of it is not relevant any more, and functions oddly. Currently it looks like he just had Enigma compile a .so. The user would then have to compile the Android project and launch it himself. This is where I will start. In the future it would be nice to configure Enigma to automatically copy an Android project to a staging area, include/exclude Android features from there as well as change the App manifest / icons, then copy in the compiled .so and create an APK and load it to a device. You can maybe see how much work this would be all from the start. So the hard part is to get AndroidNDK working. It should be easier now that it was 3 years ago, because then you actually needed SDK (Java) and NDK (native, or C++) as they were separate. As far as I know now the SDK actually allows C++ to be compiled.
The SDK and NDK are still separate. My understanding is that before it was unofficial, and now Google provides an official NDK. There are more to be done than just the graphics system, there are specific functions that need to be added, virtual keys, in app advertising, tilt and other mobile/tablet specific features, and of course the apps would have to be signed/app store compliant. Not placing any bets on ENIGMA ever being on par with other game making tools in terms of android exports.
This would be a long way off, but you have to start somewhere. I have my own little dummy Android application loading a custom written C++ library. What the first step would be is getting Enigma to compile with the NDK.
|
|
|
Logged
|
|
|
|
TheExDeus
|
|
Reply #6 Posted on: July 22, 2014, 05:46:37 am |
|
|
Joined: Apr 2008
Posts: 1860
|
there are specific functions that need to be added, virtual keys, in app advertising, tilt and other mobile/tablet specific features, and of course the apps would have to be signed/app store compliant. None of which is actually required to run a game on android. I was thinking what is ESSENTIAL for it to compile and run. edit: I think the hello-gl2 example is the one that should be taken as a starting point in creating a window, rendering context and drawing. For me the only thing required is for it to create these things. Then I am willing to code drawing functions to work (which involves changing the GL3 shader to run in GLES2.0).
|
|
« Last Edit: July 22, 2014, 06:24:19 am by TheExDeus »
|
Logged
|
|
|
|
daz
|
|
Reply #7 Posted on: July 22, 2014, 08:49:20 pm |
|
|
Joined: Jul 2010
Posts: 167
|
I was working out my problems with Josh in IRC. We got it to the point where Android could be seen in the drop down and ENIGMA would attempt to compile with the ndk. The problem is that the NDK has 30 of its own makefiles (A) I have no idea how to retrofit our source list to their makefiles (B) I have no idea which makefile to include, even if I knew how to feed in our sources Unless Josh or someone fairly experienced with ENIGMA and makefile hell comes along and integrates this crap, we're at a standstill. If anyone is interested in how to get Android to even show up as an option under Windows, I can help you with that. (But I don't think it's worth putting out a pull request with those changes when Android still does not compile anything)
|
|
|
Logged
|
|
|
|
|
|
|
|
Josh @ Dreamland
|
|
Reply #12 Posted on: July 23, 2014, 10:11:42 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
So, the point of ENIGMA's multiple makefiles is just to let systems specify the source files they include and the libraries they depend on. They operate under two assumptions:
1. You will be compiling some C++ sources into object files in order to build the C++ engine. 2. You will be linking the objects you have compiled into a standalone executable when finished.
Presently, (2) also assumes that the binary you use for linking is the same one you use for compiling. That can be changed. You can also inject additional dependencies and provide targets for them in Android-specific makefiles.
The big issue is, from what we discussed, that Android seems to compile sources into object files, but then there's some nebulous form of magic used to link those objects into a shared object to be loaded by the operating system (namely, through JNI). Unfortunately, I can't make you any recommendations until I can figure out (or someone tells me) what the hell that operation is.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
sorlok_reaves
|
|
Reply #13 Posted on: July 23, 2014, 11:17:18 pm |
|
|
Joined: Dec 2013
Posts: 260
|
Every Android project requires a small amount of Java boilerplate code. You'll typically create a normal Android project (using, say, the Eclipse plugin) with a "java" folder that contains Java code (Android Ad services, Network code, and the main window must go here) and then a "jni" folder (all your C++ code goes here). The "Android.mk" file in the jni folder controls the building of the JNI code (although there are some annoying caveats). In terms of Platform code, the most stable library is, to my knowledge, SDL. Android ports of SDL have been around forever, and it's part of upstream as of SDL 2.0. I think you'll have more luck adding an SDL backend then, say, fiddling with the Xlib code (I have seen Irrlicht running on Android, so it's not impossible to spin your own solution, but SDL has all the easy stuff like keymappings and touch gestures done). At that point, you'll basically build the entire project with the generic "ndk-build" script that is distributed with the NDK. This handles all the compiler irregularities and environment variables, and I've never seen an Android project built any other way (i.e., using GCC directly). You will never have to edit "ndk-build". Here is an example of a project that I know to be working on Android that uses SDL and native code; unfortunately, a lot of the linked page is explaining how to deal with Free Basic (which that project is using, but they also have some C code). I'm not really an expert on the NDK (it's a huge pain, in my opinion), but let me know if you run into any particularly difficult issues and I'll do my best to help.
|
|
|
Logged
|
|
|
|
Goombert
|
|
Reply #14 Posted on: July 24, 2014, 03:34:00 am |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
Yeah the other big problem is spaces in the file paths which we still haven't fixed.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
|