Collectible Card Game Headquarters

By the way, judging from the error I was getting, it couldn't find some kind of a library module in the repository... Do I maybe need to configure NetBeans to look in some extra third party repository to grab the necessary files to build the mobile module?

- Agetian

In r25655, I just committed a change to remove all remaining references to java.awt from forge-gui and forge-gui-mobile. This might have been preventing things working on Android. All java.swing references had already been previously removed from those modules.

That said, I'm a bit confused by why forge-mobile is suddenly set up as an Android module. It's not supposed to be, only forge-gui-android should be. Could you explain this? It's preventing me from running even forge-mobile-dev from source right now.

Also, with the strategy your taking, will it be possible to debug on an Android device from within Eclipse, or only publish an .apk to install?

drdev wrote:In r25655, I just committed a change to remove all remaining references to java.awt from forge-gui and forge-gui-mobile. This might have been preventing things working on Android. All java.swing references had already been previously removed from those modules.

That said, I'm a bit confused by why forge-mobile is suddenly set up as an Android module. It's not supposed to be, only forge-gui-android should be. Could you explain this? It's preventing me from running even forge-mobile-dev from source right now.

Also, with the strategy your taking, will it be possible to debug on an Android device from within Eclipse, or only publish an .apk to install?

I'm away from home right now and won't be back for at least an hour, so I'll look at the stuff then. My main goal was to get things running, then clean it all up. forge-mobile should be set up similar to the way forge-gui is in that it has shared resources for mobile development. If you could get me a short description of what each 'module' is supposed to do, it'll help me figure out the structure for everything faster.

forge-mobile is a library in the same way the forge-gui is. All device specific implementations of libgdx will reference that class, not just forge-gui-android. Besides Android, only forge-gui-mobile-dev references it, and that doesn't need to be published since it's just for testing. So only forge-gui-android should be set up as an android project. See libgdx documentation for more information.

drdev wrote:forge-mobile is a library in the same way the forge-gui is. All device specific implementations of libgdx will reference that class, not just forge-gui-android. Besides Android, only forge-gui-mobile-dev references it, and that doesn't need to be published since it's just for testing. So only forge-gui-android should be set up as an android project. See libgdx documentation for more information.

Alright, I'm back home now. I'll get started on working things out in just a minute.

To answer your other question, once this is done you'll be able to push the build to a connected phone, the emulator, or package it into a signed/unsigned .apk for distribution, depending on the command you give it.

I've gotten back to the point where I can build a runnable .apk (with the correct module this time), even though Eclipse is doing its darndest to throw wrenches into the works. The last obstacle to overcome is adding the res/ folder so that the game can be run. Right now, using assets/res/* doesn't appear to work:

Code: Select all

I/ActivityManager(  372): Displayed forge.view/.Main: +1s323ms
D/dalvikvm( 1060): GC_CONCURRENT freed 139K, 7% free 3068K/3292K, paused 5ms+8ms, total 149ms
D/dalvikvm( 1060): WAIT_FOR_CONCURRENT_GC blocked 146ms
W/System.err( 1060): FSkin > can't find skins directory!
D/dalvikvm( 1060): GC_CONCURRENT freed 25K, 6% free 3468K/3652K, paused 45ms+4ms, total 181ms
W/dalvikvm( 1060): threadid=11: thread exiting with uncaught exception (group=0xb3a1aba8)
E/AndroidRuntime( 1060): FATAL EXCEPTION: GLThread 72
E/AndroidRuntime( 1060): Process: forge.view, PID: 1060
E/AndroidRuntime( 1060): java.lang.NullPointerException
E/AndroidRuntime( 1060):        at forge.assets.FSkinTexture.load(FSkinTexture.java:50)
E/AndroidRuntime( 1060):        at forge.assets.FSkin.loadLight(FSkin.java:72)
E/AndroidRuntime( 1060):        at forge.screens.SplashScreen.<init>(SplashScreen.java:25)
E/AndroidRuntime( 1060):        at forge.Forge.create(Forge.java:65)
E/AndroidRuntime( 1060):        at com.badlogic.gdx.backends.android.AndroidGraphics.onSurfaceChanged(AndroidGraphics.java:334)
E/AndroidRuntime( 1060):        at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1512)
E/AndroidRuntime( 1060):        at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1240)


It would also be best to include the game resources outside the .apk, as if you don't, it crashes most devices with less than 1024MB of RAM from OutOfMemoryExceptions. Not to mention the .apk being huge.

I was planning to set something up to transfer them over from a desktop Forge install or download them automatically from SVN if they're deemed out of date. So please don't include them in the .apk.

drdev wrote:I was planning to set something up to transfer them over from a desktop Forge install or download them automatically from SVN if they're deemed out of date. So please don't include them in the .apk.

Alright. I can't really finish up the build process until I can test that the whole thing starts, so once that part is working I'll continue putting it all together. In the meantime, I'll clean up what I do have a bit.

I'm getting this error when I try and run forge-gui-android:

[2014-04-28 20:05:36 - Dex Loader] Unable to execute dex: Multiple dex files define Lcom/badlogic/gdx/Application$ApplicationType;
[2014-04-28 20:05:36 - forge-gui-android] Conversion to Dalvik format failed: Unable to execute dex: Multiple dex files define Lcom/badlogic/gdx/Application$ApplicationType;

Ideas? I need to be able to run the app before I can build in support for downloading the assets.

Thanks again for your help.
-Dan

drdev wrote:I'm getting this error when I try and run forge-gui-android:

[2014-04-28 20:05:36 - Dex Loader] Unable to execute dex: Multiple dex files define Lcom/badlogic/gdx/Application$ApplicationType;
[2014-04-28 20:05:36 - forge-gui-android] Conversion to Dalvik format failed: Unable to execute dex: Multiple dex files define Lcom/badlogic/gdx/Application$ApplicationType;

Ideas? I need to be able to run the app before I can build in support for downloading the assets.

Thanks again for your help.
-Dan

Ah, yes, forgot to mention that the build commands have changed a bit. You'll need to do the following in order until the ant scripts are set up to automate this:

• Run: "mvn clean compile" (Target folders must be cleared each time)
• Delete your "forge-gui-android/target/classes/forge/" folder, delete your "forge-gui-android/bin/classes/forge/" folder
• Run: "mvn android:dex android:apk"

You can try running the commands together without deleting the folders, but it causes the build process to crash on my end since it's trying to add BuildConfig/Main/Etc multiple times. If you're still having problems, try cleaning out the target folders for forge-gui-mobile if you haven't already.

Is it possible for you to get this to work more easily before I get the assets to work? You can always just copy-paste the assets somewhere on your android device for now and update GuiMobile to point to that location in the Android case of GuiMobile.getInstallRoot.

I would particularly like the ability to run forge-gui-android from within Eclipse without using the command line.

drdev wrote:Is it possible for you to get this to work more easily before I get the assets to work? You can always just copy-paste the assets somewhere on your android device for now and update GuiMobile to point to that location in the Android case of GuiMobile.getInstallRoot.

I would particularly like the ability to run forge-gui-android from within Eclipse without using the command line.

Yeah, I'm back to working on it now. forge-gui-mobile worked fine and was relatively easy to get running... forge-gui-android is being extremely stubborn, despite very little being different.

Alright, forge-gui-android should now have an easy build process. In eclipse, run the project as a Maven build and drop the following into the "goals" box:

Code: Select all

-U -B clean -P android android:dex android:apk


This runs an android build profile that makes sure the files/folders are where they need to be before attempting to compile the .apk. It'll end up as "forge-gui-android-(version)-SNAPSHOT.apk" in your "target/" folder.

To deploy the .apk to all connected devices (emulators/physical android devices), use the following instead:

Code: Select all

-U -B clean -P android android:dex android:apk android:undeploy android:deploy


This builds a new .apk as the previous command, except it uninstalls the previous version from the connected devices and installs the new one automatically once the build is complete.

Let me know if any of this doesn't work for you and I'll jump right into kicking it into submission.

Is there any way to run it as an Android application so I can debug it? Or does the Maven setup prevent that?

drdev wrote:Is there any way to run it as an Android application so I can debug it? Or does the Maven setup prevent that?

AFAIK, you need an emulator or actual device attached to run the .apk (or the project it's built from). There might be a way to run it through Eclipse with ADT, but I haven't looked into it. You might just need to fix the errors you reported from before (remove the duplicate libraries from your classpath or lib/ folders) and run a debugger with that. I think you'll still need the emulator + virtual device to use the debugging tools, but you can leave them open while coding and deploy while it's running. This link appears to be what you want.

Edit: Poking at it on my computer to see if I can get it working the way you want it to.
Edit 2: It looks like it might end up being more trouble than it's worth. The way the multi-module Maven project interacts with the Android project requirements seems to create an endless list of problems.

Edit 3: It seems like the way to go here would be to build and deploy the .apk with Maven, then debug it by selecting the process on the emulator in Eclipse.