Not sure what you mean by this. But in any case, a lot of work has
been done to the Android backend over the last couple of months by Jon
Gill (a Google intern).
His changes were all recently merged, and they haven't been thoroughly
tested since then, so there may be some exciting surprises. That said,
the new code is based on OpenGL and thus provides a higher performance
foundation for future work than the previous backend.
Is the code on the default Mercurial repository?
P.S: And it looks like flash was added as well, very nice progress! Great stuff!
Assuming you have your Android SDK set up and an emulator configured
and running, simply do:
% cd playn/sample/showcase
% mvn install
% cd android
% mvn android:deploy
As a complete Maven newbie, I must confess that I run my Android games
almost exclusively from Eclipse. It's a little more maintenance work,
but generally pretty easy to do. Unfortunately, there's one obnoxious
hiccup in the build process, but we'll get to that in a second.
The steps as I remember them are as follows:
1. Make sure you have all pertinent projects imported into Eclipse
(my-game, my-game-android, playn-core, playn-android, playn-box2d if
it's being used).
2. Ensure that my-game-android is actually an Android project,
targeting SDK 11.
3. Go to the Android Properties of my-game-android and add
playn-android as an Android library that it depends on.
4. Go the the Java Build Path of my-game-android and add any
additional dependencies. I'm not sure which are required and which
Eclipse manages to handle for you. You certainly need to add
pythagoras-1.1-SNAPSHOT.jar as a library and playn-box2d as a
dependent project (but only if you're using Box2D). You may have to
include additional projects — which ones should be fairly obvious.
5. Here's the tricky step: The standard Java method of including
resources in a .jar (putting them directly into a sub-package) does
not currently play nicely with the .apk builder, so you MUST copy any
resources from projects my-game-android depends on into
my-game-android. Say, for example, you keep your image files in
my-game/resources/images/ — just copy all of my-game/resources and
paste it into my-game-android/resources. This will force Eclipse into
compressing the files into the .apk, even though it's subverting the
correct Android method for resource inclusion.
6. Right-click my-game-android and hit Run as Android Application.
Eclipse should load the emulator and you'll be off! Admittedly, it
probably won't run very fast — the Android emulator is not a speed
machine, especially when dealing with complex OpenGL, so you'll be
better off doing most of your testing with the Java app and just
running the Android emulator to check compatibility.
Good luck, and I hope these steps help you to get your game up and
running until Maven is running properly. Let me know if they don't
work — it's been a few weeks since I've set up a project like this,
and I may have forgotten a step somewhere along the way.
Cheers,
-Jon
Description Resource Path Location Type
error executing dx
command=[me.gladwell.android.tools.drivers.DexCommand@1ba0ac2]
(com.jayway.maven.plugins.android.generation2:maven-android-plugin:3.0.0-alpha-2:generate-sources:default-generate-sources:generate-sources) pom.xml /playn-showcase-android line
41 Maven Build Problem
So I am not going to be banging my head much with this one until the weekend.
To fix that error I added the libs to the project with a simple copy
paste, but then I get a GL error:
09-21 18:46:05.969: ERROR/AndroidRuntime(292): FATAL EXCEPTION: GLThread 8
09-21 18:46:05.969: ERROR/AndroidRuntime(292):
java.lang.IllegalArgumentException: No configs match configSpec
09-21 18:46:05.969: ERROR/AndroidRuntime(292): at
android.opengl.GLSurfaceView$BaseConfigChooser.chooseConfig(GLSurfaceView.java:760)
09-21 18:46:05.969: ERROR/AndroidRuntime(292): at
android.opengl.GLSurfaceView$EglHelper.start(GLSurfaceView.java:916)
09-21 18:46:05.969: ERROR/AndroidRuntime(292): at
android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1246)
09-21 18:46:05.969: ERROR/AndroidRuntime(292): at
android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1116)
So there are still some linking issues...
I too seem to be unable to run the samples. I still get the "force
closed" screen which results from the same error shown above (not
being able to find the playn-android library).
Daniel, could you please let me know if you manage to get the showcase
working somehow?
On Wed, Sep 21, 2011 at 7:29 PM, Denis <dsta...@gmail.com> wrote:
To fix that error I added the libs to the project with a simple copy
paste, but then I get a GL error:
09-21 18:46:05.969: ERROR/AndroidRuntime(292): FATAL EXCEPTION: GLThread 8
09-21 18:46:05.969: ERROR/AndroidRuntime(292):
java.lang.IllegalArgumentException: No configs match configSpec
09-21 18:46:05.969: ERROR/AndroidRuntime(292): at
android.opengl.GLSurfaceView$BaseConfigChooser.chooseConfig(GLSurfaceView.java:760)
09-21 18:46:05.969: ERROR/AndroidRuntime(292): at
android.opengl.GLSurfaceView$EglHelper.start(GLSurfaceView.java:916)
09-21 18:46:05.969: ERROR/AndroidRuntime(292): at
android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1246)
09-21 18:46:05.969: ERROR/AndroidRuntime(292): at
android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1116)
So there are still some linking issues...
Ill give it a try on Samsung Galaxy S
There is no menu item and the demo menu is not touch enabled...
I tried to do it was using the adb command line: adb -d shell input keyevent 8
to no avail. Thanks!
The showcase demo is rewritten with a proper user interface, with
buttons you can press in our fork (see previous email for git URL).
That code will also make it upstream when I have time to submit it for
review.
Also it would be great to have a simple way to add buttons and a
virtual joystick, but perhaps that is the sort of thing that is
outside the scope of the framework?
Couple of things:
Did you recompile and rename the playn-android.so library? Because at
first it complained that it could not find it and then I had to rename
the file to match playn-android-nativelib.so after that it crashes
with GL error on phone:
--- CatLog ---
09-23 20:00:28.003: INFO/StatusBarPolicy(211): onSignalStrengthsChanged
09-23 20:00:28.023: DEBUG/BatteryService(128): update start
09-23 20:00:28.031: DEBUG/BatteryService(128): updateBattery level:88
scale:100 status:2 health:2 present:true voltage: 4150 temperature:
320 technology: Li-ion AC powered:false USB powered:true icon:17302213
09-23 20:00:28.046: INFO/StatusBarPolicy(211): BAT. S:2 H:2
09-23 20:00:29.972: INFO/InputReader(128): dispatchTouch::touch
event's action is 0
09-23 20:00:29.972: INFO/InputDispatcher(128): Delivering touch to
current input target: action: 0, channel '409bc6b0
com.gau.go.launcherex/com.jiubang.ggheart.apps.desks.diy.GoLauncher
(server)'
09-23 20:00:29.972: INFO/InputDispatcher(128): Delivering touch to
current input target: action: 0, channel '409456b8
com.android.internal.service.wallpaper.ImageWallpaper (server)'
09-23 20:00:30.058: INFO/InputReader(128): dispatchTouch::touch
event's action is 1
09-23 20:00:30.058: INFO/InputDispatcher(128): Delivering touch to
current input target: action: 1, channel '409bc6b0
com.gau.go.launcherex/com.jiubang.ggheart.apps.desks.diy.GoLauncher
(server)'
09-23 20:00:30.058: INFO/InputDispatcher(128): Delivering touch to
current input target: action: 1, channel '409456b8
com.android.internal.service.wallpaper.ImageWallpaper (server)'
09-23 20:00:30.058: INFO/ActivityManager(128): Starting: Intent {
act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER]
flg=0x10200000 cmp=playn.showcase.android/.ShowcaseActivity } from pid
917
09-23 20:00:30.082: DEBUG/PhoneWindow(917): couldn't save which view
has focus because the focused view
com.jiubang.ggheart.apps.desks.appfunc.XViewFrame@4065f3a0 has no id.
09-23 20:00:30.105: INFO/ActivityManager(128): Start proc
playn.showcase.android for activity
playn.showcase.android/.ShowcaseActivity: pid=2300 uid=10151 gids={}
09-23 20:00:30.144: DEBUG/dalvikvm(2300): Debugger has detached;
object registry had 1 entries
09-23 20:00:30.171: DEBUG/dalvikvm(2300): Trying to load lib
/data/data/playn.showcase.android/lib/libplayn-android-nativelib.so
0x40514160
09-23 20:00:30.175: DEBUG/dalvikvm(2300): Added shared lib
/data/data/playn.showcase.android/lib/libplayn-android-nativelib.so
0x40514160
09-23 20:00:30.175: DEBUG/dalvikvm(2300): No JNI_OnLoad found in
/data/data/playn.showcase.android/lib/libplayn-android-nativelib.so
0x40514160, skipping init
09-23 20:00:30.183: INFO/GLThread(2300): noticed surfaceView surface lost tid=10
09-23 20:00:30.183: INFO/WindowManager(128): Setting rotation to 1, animFlags=1
09-23 20:00:30.199: INFO/TvOut-Observer(128): setTvoutOrientation rotation = 1
09-23 20:00:30.199: ERROR/TvOut-Observer(128): SetOrientation
09-23 20:00:30.199: INFO/TvOut-Client(128): SetOrientation +
09-23 20:00:30.199: INFO/TvOut-Client(128): SetOrientation -
09-23 20:00:30.199: INFO/ActivityManager(128): Config changed: {
scale=1.0 imsi=268/3 loc=en_GB touch=3 keys=1/1/2 nav=1/1 orien=2
layout=34 uiMode=17 seq=20 FlipFont=0}
09-23 20:00:30.250: DEBUG/playn(2300): onResume
09-23 20:00:30.250: INFO/playn(2300): notifyVisibilityChanged: 0
09-23 20:00:30.250: INFO/GLThread(2300): onResume tid=10
09-23 20:00:30.257: DEBUG/playn(2300): Using default sizing.
09-23 20:00:30.277: INFO/playn(2300): Screen sized changed to ( 800 , 480)
09-23 20:00:30.285: INFO/ActivityManager(128): Displayed
playn.showcase.android/.ShowcaseActivity: +186ms
09-23 20:00:30.324: INFO/GLThread(2300): noticed surfaceView surface
acquired tid=10
09-23 20:00:30.324: WARN/EglHelper(2300): start() tid=10
09-23 20:00:30.324: DEBUG/libEGL(2300): loaded
/system/lib/egl/libEGL_POWERVR_SGX540_120.so
09-23 20:00:30.328: DEBUG/libEGL(2300): loaded
/system/lib/egl/libGLESv1_CM_POWERVR_SGX540_120.so
09-23 20:00:30.343: DEBUG/libEGL(2300): loaded
/system/lib/egl/libGLESv2_POWERVR_SGX540_120.so
09-23 20:00:30.382: DEBUG/playn(2300): Using default sizing.
09-23 20:00:30.406: WARN/EglHelper(2300): createContext
com.google.android.gles_jni.EGLContextImpl@405237f0 tid=10
09-23 20:00:30.406: INFO/GLThread(2300): noticing that we want render
notification tid=10
09-23 20:00:30.406: WARN/GLThread(2300): egl createSurface
09-23 20:00:30.406: WARN/EglHelper(2300): createSurface() tid=10
09-23 20:00:30.417: WARN/GLThreadManager(2300): checkGLESVersion
mGLESVersion = 131072 mMultipleGLESContextsAllowed = true
09-23 20:00:30.417: WARN/GLThread(2300): onSurfaceCreated
09-23 20:00:30.417: WARN/GLThread(2300): onSurfaceChanged(800, 480)
09-23 20:00:30.417: DEBUG/playn(2300): Surface dimensions changed to (
800 , 480)
09-23 20:00:30.421: WARN/EglHelper(2300): destroySurface() tid=10
09-23 20:00:30.425: WARN/EglHelper(2300): finish() tid=10
09-23 20:00:30.429: WARN/dalvikvm(2300): threadid=9: thread exiting
with uncaught exception (group=0x40015578)
09-23 20:00:30.433: ERROR/AndroidRuntime(2300): FATAL EXCEPTION: GLThread 10
09-23 20:00:30.433: ERROR/AndroidRuntime(2300):
java.lang.RuntimeException: Exception loading shader strings.
09-23 20:00:30.433: ERROR/AndroidRuntime(2300): at
playn.android.ShaderCallback.error(ShaderCallback.java:30)
09-23 20:00:30.433: ERROR/AndroidRuntime(2300): at
playn.android.AndroidAssetManager.doGetText(AndroidAssetManager.java:177)
09-23 20:00:30.433: ERROR/AndroidRuntime(2300): at
playn.core.AbstractAssetManager.getText(AbstractAssetManager.java:46)
09-23 20:00:30.433: ERROR/AndroidRuntime(2300): at
playn.android.AndroidGraphics$Shader.<init>(AndroidGraphics.java:76)
09-23 20:00:30.433: ERROR/AndroidRuntime(2300): at
playn.android.AndroidGraphics$TextureShader.<init>(AndroidGraphics.java:248)
09-23 20:00:30.433: ERROR/AndroidRuntime(2300): at
playn.android.AndroidGraphics.generateShaders(AndroidGraphics.java:355)
09-23 20:00:30.433: ERROR/AndroidRuntime(2300): at
playn.android.AndroidGraphics.<init>(AndroidGraphics.java:351)
09-23 20:00:30.433: ERROR/AndroidRuntime(2300): at
playn.android.AndroidPlatform.<init>(AndroidPlatform.java:65)
09-23 20:00:30.433: ERROR/AndroidRuntime(2300): at
playn.android.AndroidPlatform.register(AndroidPlatform.java:40)
09-23 20:00:30.433: ERROR/AndroidRuntime(2300): at
playn.android.GameViewGL$AndroidRendererGL.onDrawFrame(GameViewGL.java:68)
09-23 20:00:30.433: ERROR/AndroidRuntime(2300): at
android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1388)
09-23 20:00:30.433: ERROR/AndroidRuntime(2300): at
android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1138)
09-23 20:00:30.433: ERROR/AndroidRuntime(2300): Caused by:
java.io.IOException: Unable to loader resource: vertex-shader.txt
09-23 20:00:30.433: ERROR/AndroidRuntime(2300): at
playn.android.AndroidAssetManager.openAsset(AndroidAssetManager.java:57)
09-23 20:00:30.433: ERROR/AndroidRuntime(2300): at
playn.android.AndroidAssetManager.doGetText(AndroidAssetManager.java:160)
09-23 20:00:30.433: ERROR/AndroidRuntime(2300): ... 10 more
09-23 20:00:30.437: ERROR/(128): Dumpstate > /data/log/dumpstate_app_error
09-23 20:00:30.437: DEBUG/playn(2300): onPause
09-23 20:00:30.437: INFO/playn(2300): notifyVisibilityChanged: 4
09-23 20:00:30.437: INFO/GLThread(2300): onPause tid=10
09-23 20:00:30.437: WARN/ActivityManager(128): Force finishing
activity playn.showcase.android/.ShowcaseActivity
09-23 20:00:30.445: INFO/dumpstate(2310): begin
09-23 20:00:30.937: WARN/ActivityManager(128): Activity pause timeout
for HistoryRecord{405629a0 playn.showcase.android/.ShowcaseActivity}
09-23 20:00:32.437: DEBUG/dalvikvm(128): GC_EXPLICIT freed 789K, 39%
free 7570K/12231K, external 8961K/10921K, paused 99ms
09-23 20:00:32.707: INFO/ggheart(917): onStop
09-23 20:00:32.746: WARN/IInputConnectionWrapper(917): showStatusIcon
on inactive InputConnection
09-23 20:00:32.753: INFO/WindowManager(128): Setting rotation to 0, animFlags=1
09-23 20:00:32.773: INFO/TvOut-Observer(128): setTvoutOrientation rotation = 0
09-23 20:00:32.773: ERROR/TvOut-Observer(128): SetOrientation
09-23 20:00:32.773: INFO/TvOut-Client(128): SetOrientation +
09-23 20:00:32.773: INFO/TvOut-Client(128): SetOrientation -
09-23 20:00:33.062: WARN/PowerManagerService(128): Timer 0x3->0x3|0x3
09-23 20:00:34.753: WARN/WindowManager(128): Window freeze timeout expired.
09-23 20:00:34.753: WARN/WindowManager(128): Force clearing
orientation change: Window{40931128 StatusBar paused=false}
09-23 20:00:34.753: WARN/WindowManager(128): Force clearing
orientation change: Window{4085e340 StatusBarExpanded paused=false}
09-23 20:00:34.753: WARN/WindowManager(128): Force clearing
orientation change: Window{4098c598
playn.showcase.android/playn.showcase.android.ShowcaseActivity
paused=true}
09-23 20:00:34.753: WARN/WindowManager(128): Force clearing
orientation change: Window{40af3000 SurfaceView paused=false}
09-23 20:00:34.753: WARN/WindowManager(128): Force clearing
orientation change: Window{409456b8
com.android.internal.service.wallpaper.ImageWallpaper paused=false}
09-23 20:00:35.921: DEBUG/VoldCmdListener(75): asec list
09-23 20:00:37.773: WARN/SurfaceFlinger(128): timeout expired
mFreezeDisplay=1, mFreezeCount=0
09-23 20:00:38.054: DEBUG/BatteryService(128): update start
09-23 20:00:38.058: DEBUG/BatteryService(128): updateBattery level:88
scale:100 status:2 health:2 present:true voltage: 4146 temperature:
320 technology: Li-ion AC powered:false USB powered:true icon:17302213
09-23 20:00:41.925: INFO/dumpstate(2310): done
09-23 20:00:42.000: INFO/ActivityManager(128): Config changed: {
scale=1.0 imsi=268/3 loc=en_GB touch=3 keys=1/1/2 nav=1/1 orien=1
layout=34 uiMode=17 seq=21 FlipFont=0}
09-23 20:00:42.050: WARN/ActivityManager(128): Launch timeout has
expired, giving up wake lock!
09-23 20:00:42.058: INFO/ActivityManager(128): No longer want
com.android.voicedialer (pid 2132): hidden #16
09-23 20:00:42.082: INFO/DemoService(917): DiyScheduer.onStart
09-23 20:00:42.082: INFO/ggheart(917): onStart
09-23 20:00:42.148: INFO/StatusBarPolicy(211): BAT. S:2 H:2
09-23 20:00:42.222: VERBOSE/MmsProvider(223): Query
uri=content://mms/inbox, match=2
09-23 20:00:42.355: WARN/System.err(931): java.lang.SecurityException:
Permission Denial: opening provider
com.google.android.gm.provider.MailProvider from
ProcessRecord{4094c668 931:com.gau.golauncherex.notification/10114}
(pid=931, uid=10114) requires
com.google.android.gm.permission.READ_GMAIL or
com.google.android.gm.permission.WRITE_GMAIL
09-23 20:00:42.355: WARN/System.err(931): at
android.os.Parcel.readException(Parcel.java:1322)
09-23 20:00:42.355: WARN/System.err(931): at
android.os.Parcel.readException(Parcel.java:1276)
09-23 20:00:42.355: WARN/System.err(931): at
android.app.ActivityManagerProxy.getContentProvider(ActivityManagerNative.java:1882)
09-23 20:00:42.355: WARN/System.err(931): at
android.app.ActivityThread.getProvider(ActivityThread.java:3351)
09-23 20:00:42.355: WARN/System.err(931): at
android.app.ActivityThread.acquireProvider(ActivityThread.java:3376)
09-23 20:00:42.355: WARN/System.err(931): at
android.app.ContextImpl$ApplicationContentResolver.acquireProvider(ContextImpl.java:1810)
09-23 20:00:42.355: WARN/System.err(931): at
android.content.ContentResolver.acquireProvider(ContentResolver.java:748)
09-23 20:00:42.355: WARN/System.err(931): at
android.content.ContentResolver.query(ContentResolver.java:256)
09-23 20:00:42.355: WARN/System.err(931): at
com.gau.golauncherex.notification.monitor.gmailmonitor.GmailMonitorService.a(GmailMonitorService.java:163)
09-23 20:00:42.355: WARN/ActivityManager(128): Permission Denial:
opening provider com.google.android.gm.provider.MailProvider from
ProcessRecord{4094c668 931:com.gau.golauncherex.notification/10114}
(pid=931, uid=10114) requires
com.google.android.gm.permission.READ_GMAIL or
com.google.android.gm.permission.WRITE_GMAIL
09-23 20:00:42.359: WARN/System.err(931): at
com.gau.golauncherex.notification.monitor.gmailmonitor.GmailMonitorService.a(GmailMonitorService.java:16)
09-23 20:00:42.359: WARN/System.err(931): at
com.gau.golauncherex.notification.monitor.gmailmonitor.b.run(GmailMonitorService.java:138)
09-23 20:00:42.375: VERBOSE/MmsProvider(223): Query
uri=content://mms/inbox, match=2
09-23 20:00:42.425: WARN/ActivityManager(128): Permission Denial:
opening provider com.google.android.gm.provider.MailProvider from
ProcessRecord{4094c668 931:com.gau.golauncherex.notification/10114}
(pid=931, uid=10114) requires
com.google.android.gm.permission.READ_GMAIL or
com.google.android.gm.permission.WRITE_GMAIL
09-23 20:00:42.453: WARN/System.err(931): java.lang.SecurityException:
Permission Denial: opening provider
com.google.android.gm.provider.MailProvider from
ProcessRecord{4094c668 931:com.gau.golauncherex.notification/10114}
(pid=931, uid=10114) requires
com.google.android.gm.permission.READ_GMAIL or
com.google.android.gm.permission.WRITE_GMAIL
09-23 20:00:42.453: WARN/System.err(931): at
android.os.Parcel.readException(Parcel.java:1322)
09-23 20:00:42.453: WARN/System.err(931): at
android.os.Parcel.readException(Parcel.java:1276)
09-23 20:00:42.453: WARN/System.err(931): at
android.app.ActivityManagerProxy.getContentProvider(ActivityManagerNative.java:1882)
09-23 20:00:42.457: WARN/System.err(931): at
android.app.ActivityThread.getProvider(ActivityThread.java:3351)
09-23 20:00:42.457: WARN/System.err(931): at
android.app.ActivityThread.acquireProvider(ActivityThread.java:3376)
09-23 20:00:42.457: WARN/System.err(931): at
android.app.ContextImpl$ApplicationContentResolver.acquireProvider(ContextImpl.java:1810)
09-23 20:00:42.457: WARN/System.err(931): at
android.content.ContentResolver.acquireProvider(ContentResolver.java:748)
09-23 20:00:42.457: WARN/System.err(931): at
android.content.ContentResolver.query(ContentResolver.java:256)
09-23 20:00:42.457: WARN/System.err(931): at
com.gau.golauncherex.notification.monitor.gmailmonitor.GmailMonitorService.a(GmailMonitorService.java:163)
09-23 20:00:42.457: WARN/System.err(931): at
com.gau.golauncherex.notification.monitor.gmailmonitor.GmailMonitorService.a(GmailMonitorService.java:16)
09-23 20:00:42.457: WARN/System.err(931): at
com.gau.golauncherex.notification.monitor.gmailmonitor.b.run(GmailMonitorService.java:138)
09-23 20:00:44.371: DEBUG/dalvikvm(128): GC_EXPLICIT freed 210K, 39%
free 7538K/12231K, external 9210K/10860K, paused 94ms
09-23 20:00:45.417: WARN/PowerManagerService(128): Timer 0x3->0x3|0x0
09-23 20:00:47.523: DEBUG/dalvikvm(904): GC_EXPLICIT freed 25K, 52%
free 2599K/5379K, external 1596K/2108K, paused 68ms
09-23 20:00:47.523: DEBUG/UNA(904): [PackageAgent] Finalizing
09-23 20:00:47.523: DEBUG/UNA(904): [PackageAgent] Finalizing
09-23 20:00:48.085: DEBUG/BatteryService(128): update start
09-23 20:00:48.089: DEBUG/BatteryService(128): updateBattery level:88
scale:100 status:2 health:2 present:true voltage: 4148 temperature:
330 technology: Li-ion AC powered:false USB powered:true icon:17302213
09-23 20:00:48.105: INFO/StatusBarPolicy(211): BAT. S:2 H:2
Are you running from Eclipse? That doesn't work. But if you're
creating the apk and installing it from the command line via Maven,
that works.
If you see something looking for a playn-android library, that sounds
like your code is out of date. You probably need to update your playn
checkout and "mvn install" at the top-level to be sure all the latest
fixes are installed.
The Flash backend is nothing more than a technology demo and I
wouldn't recommend taking it seriously. It exists because one GWT
engineer though it would be cool to see if GWT could cross-compile
Java to ActionScript, and hacked something out. It's non-performant
(it uses untyped ActionScript). It's largely untested. I know of no
one that is seriously considering it for a real game. No one is
working on filling in missing functionality or fixing bugs in existing
functionality. Flash is a dying platform. If you need to ship a game
on Flash today, you shouldn't be using PlayN. Even if there was a full
time engineer taking the PlayN Flash backend seriously, by the time
PlayN was able to ship decent Flash games, no one would care about
Flash.
The Android backend was completely rewritten recently to use OpenGL,
so there are bugs. I am actively using PlayN to develop a commercial
mobile game, and I test said game on a Nexus S periodically. So at
least one actual engineer is working to make it more solid.
Building for Android continues to vex most people who show up around
here. I wish it were simpler to build and deploy to Android, but there
are multiple complex components (the Android SDK, the Maven Android
plugin, Eclipse, and the Eclipse Android plugin) that ought to
collaborate, but often seem to be fighting one another instead. So
don't expect that you can walk in, press button, and have something
running on Android (especially not if you want to do it from Eclipse).
You should have some experience deploying software to an Android
device (don't imagine you can test with the emulator, it's not
remotely viable for an edit/compile/test flow, plus I don't think it
supports OpenGL). You should be ready to paste some error messages
into Google if you run into them. I can build and deploy games to an
Android device just fine (cd playn-samples ; git pull ; cd showcase ;
mvn clean install ; cd android ; mvn android:deploy), as can other
engineers at Three Rings, but I don't have enough fingers and toes to
count the number of people that have shown up here complaining about
some Android deployment problem or other.
> Have the Android demos been patched to react to key events? That is if
> i press back btn will it go back, etc...
If you mean does the showcase demo support the back button, the answer
is yes. I recently added much improved key support so that all keys
across all the platforms can be used.
> is the android platform ready
> (stable enough) to be used for deployment?
Are you planning on shipping a commercial game in the next three
months? If so, I would advise using an Android-only library and
developing a game directly for that platform. I hear libGDX is good.
If you're looking at a six month time frame, then you might be in
better shape. However, you should be prepared to roll up your sleeves
and help with the Android backend. There are bugs and unimplemented
features that need fixing and implementing. Given an infinite amount
of time, I'll probably personally fix them, but I've never known a
producer to agree to a schedule with infinity on it.
What would be great is if someone showed up that was willing to help
fix and improve the code rather than just expecting a fully
operational magical system that allows them to fling together a game
with the tiniest bit of effort and press the big magical button and
have it running on HTML5, Android, Flash and in an applet on their
refrigerator.
> Ill look into the code this weekend but I would love to know if I am
> going to be excited or still a bit frustrated with PlayN on Android.
That all depends on your expectations. :)
> Much appreciate all the work that you guys have put into this.
> Specially Jon and Michael fer being so patient and informative.
Cheers. I apologize for directing a bit of pent up steam in your
direction. It's not personally directed at you, but more the general
crowd that has turned up on the mailing lists in the last month or so.
This email just happened to be the straw that broke the camel's back.
Being the guy that has made 71 of the last 100 commits to PlayN, I'm
starting to wonder why I spend my time helping people with their
problems on the mailing list, and jumping through Google's annoying
review before commit hoops, and improving the new user documentation
and development experience. I seem to be the only one putting his
money where his mouth is (20 of the remaining 29 commits were made by
engineers being paid by the game company I founded, so that leaves a
whopping 9 commits from other helpful people). There are also the
hundreds of commits I've made to Triple Play, our library that builds
on PlayN to provide higher level services like a UI toolkit, or
SocializeN, the library I'm working on to make it easy to integrate a
PlayN game with Facebook and Google+, or React and Pythagoras which
are used by those libraries.
The two games that I'm working on would undoubtedly be way farther
along if I just unsubscribed from all the PlayN mailing lists, stopped
worrying about pushing changes from github.com/threerings/playn to
code.google.com/p/playn and just focused on getting shit done. Maybe
someone will come out of the woodwork and convince me that I shouldn't
do this by fixing some bugs or contributing a useful feature to PlayN.
Perhaps this is my fault for participating in an open source project
that seems to have more marketing support than engineering support.
I've never seen such a strange beast before, so I can at least forgive
myself for not seeing what I was getting into.
Anyway, enough ranting. This is even less conducive to getting my game
done than filing code review issues.
I proposed that very thing months ago and met with resistance. The
word from Google was that Flash was critical to the value proposition
of PlayN because not everyone is ready to move to HTML5. Of course,
that criticality has not motivated anyone (other than me, of course)
to actually *work* on the Flash backend. So it remains a lovely
albatross around our necks, dragging PlayN down, just as it was
dragging PlayN down months ago when I complained about it the first
time.
> Right now Flash literally breaks the build and causes Android
> to never compile ( which shouldn't have been allowed in the first
> place in a 1.0 release ),
If I didn't have to do this release by proxy through a Google
engineer, I assure you it would have been of higher quality. But the
opportunity to get a release out the door given that I had been
pushing for that for months as well, engendered some unfortunate
haste.
> I like PlayN and am trying really hard to make it accessible and
> appealing to new developers, but when every step involves 13 hoops
> they have to jump through, it is kinda hard to justify recommending
> PlayN over various other options, and in this space there are a
> literal ton of them.
I've tried to reduce the hoop jumping to a minimum, but there are
dozens of moving parts involved in getting things built across all of
the backends, and those parts are constantly changing themselves. So
it's extremely non-trivial to sweep all this behind the curtain and
present a magical error-free process that allows unsophisticated users
to easily deploy their game to four platforms.
In this particular case, the GWT Maven plugin lacked a feature we
needed, so I had to patch it and publish the patched version to a
custom Maven repository so that we could use it. Then GWT released a
new version and the GWT Maven plugin released a new version that
included my patch, so I upgraded GWT and the GWT Maven plugin to
remove at least that one additional moving part from the process, but
the GWT upgrade broke the ActionScript cross-compiler.
Similar issues have plagued us with the Maven Android and Eclipse
Maven plugins. Android builds broke recently because Android released
a new SDK which broke both the Maven and Eclipse Android plugins, so
we had to upgrade those, but the latest Maven Android plugin does
things that the Eclipse Maven plugin freaks out about, which requires
the manual suppression of warnings that you have so nicely documented
in your installation procedures. I wish these components didn't suck,
and would just get along, but when shit breaks, I have to fix it to
stem the inevitable flood of questions from new users who naturally
download the latest Android SDK and then wonder why PlayN doesn't work
with it.
> In my discussions among more experienced
> developers, irregardless to the experience they do or don't have with
> PlayN, the number one reservation is that of Google's commitment to
> the project.
I'd be happy with the commitment of a few other enthusiastic open
source developers. Most of these other frameworks are not backed by
mega-corporations, they're backed by enthusiastic amateur (or in some
cases professional) game developers who enjoy working on game
frameworks.
- I was pretty excited when I saw some impressive Flash11 demos of the Stage3D stuff. But Flash 11 seems to be not making it out the door in a timely manner.
- Then you have to wonder when you see announcements like this:
http://blogs.adobe.com/conversations/2011/11/flash-focus.html
Michael, et al.,As someone at least partially responsible for encouraging the Flash backend, allow me to apologize for the pain it's been causing everyone. To give a little background on why I pushed for it (not *just* because it's kind of clever, although perhaps that played a small part):About a year ago, Ray and I were invited to give a talk on HTML5 for games at a very-large-company-that-shall-not-be-named. After the talk, a development manager asked the simple question -- "This HTML5 stuff is really cool and all, but we build Facebook games, and have a large percentage of IE6, 7, and 8 users. if I go to my boss and tell him 'we have a great new way to build and deploy our games; all we have to do is abandon the IE users', he'll kick me out of the room. What am I supposed to do about that?"This was before forplay and angry-birds. But I've heard this sentiment echoed by game developers at other companies, and it's what got me thinking about bridging developers to HTML5 by creating an abstraction layer that allows developers to target Flash while still targeting modern web browsers. The Flash backend could theoretically become vestigial over time. Seems like a nice strategy for actually getting something you can ship while slowly moving everyone over to "the future".
That said, the reality has been much uglier than that. No one's had time to make the AS3 backend "good", and doing so will take time, as well as distract from what I'd really like to see, which is a C or LLVM backend for targeting iOS and consoles (and maybe even Android/NaCl one day if the performance difference is great enough).
This has effectively already happened because the Flash GWT plugin
doesn't work with GWT 2.4.0. We are still building the playn-flash
subproject, but nothing can actually use it.
I don't mind continuing to stub out interfaces as new features are
added to PlayN, but we should remove Flash from the getting started
instructions and explain on the website that the backend is
languishing for lack of anyone willing to help with the code.
On Wed, Nov 9, 2011 at 1:25 PM, Alain Ekambi
<jazzma...@googlemail.com> wrote:
> To me the Flash backend should have the same priority as the HTML5 one.
Then vote with lines of code committed to PlayN.
In the open source world, a project lives or dies by its contributors.
Unless the Flash backend finds an enthusiastic contributor, it is
doomed to the latter fate.
On 11/09/2011 02:00 PM, Joel Webber wrote:
>
> There are a couple of other signals that make me wonder about the wisdom
> of my decision as well:
> - I was pretty excited when I saw some impressive Flash11 demos of the
> Stage3D stuff. But Flash 11 seems to be not making it out the door in a
> timely manner.
Have you looked at the MAX 2011 videos? The Unreal Engine now runs in
the shipping flash player. The in development games for Stage3D are
impressive. At least on desktop computers, flash will be around for a
while.
http://tv.adobe.com/show/max-2011-develop
> On 11/09/2011 02:49 PM, Michael Bayne wrote:
>> On Wed, Nov 9, 2011 at 1:25 PM, Alain Ekambi
>> <jazzma...@googlemail.com> wrote:
>>> > To me the Flash backend should have the same priority as the HTML5 one.
>> Then vote with lines of code committed to PlayN.
Or encourage particlecode to open source their significantly more
advanced Java to AS3 translation technology.
http://www.particlecode.com/forums/topic.php?id=178
http://www.phoronix.com/scan.php?page=news_item&px=MTAwODE
I am mostly a lone wolf developer, I work as an Indie and on Contract.
I am currently developing multi-platform apps/games using
airplay/marmalade. It took me 6 months to develop a decent game
engine. My interest in playN is due to my familiarity with Java and my
interest in porting games to HTML5. I already have a working iOS,
Android game engine, but I have no way to do WebGL or Flash code
simply, therefore I have interest in this project, but no resources to
actually contribute time and code to the framework. Being a Google
project I was hoping their resources would take care of the
development of the framework and most of the game engine mechanics
since as you know it takes a long time to develop tech, plus it's
never actually done I am still adding features to my own game engine.
My expectation when I became aware of PlayN was to just focus on
Gameplay and reuse my existing game assets to target web platforms
like Google+, Facebook and others that use Flash or HTML5.
I think perhaps my expectation was too high after I saw the IO 2011
presentation and that Rovio was using this. After the project became
public I looked at the code and noticed that it lacked maturity, since
I do not have the resources to contribute to it I decided to wait some
months in hopes that the project would reach a more mature state as I
completed my own game engine, I would look at the website and mailing
list from time to time to try and assess the state and try to run the
samples to see how it was progressing as an API, i think many
developers come here with the same mindframe. They do not have the
Perhaps it would be best to have just a developer mailing list to keep
things separated, since there is little documentation and the one that
exist is sometimes outdated, people come to the mailing list, it's the
goto place for quick replies, the fact is that mailing list suck to
search, so the stackoverflow page solves this partially.
Javaland has always sucked at project configuration, path finding,
dependency management etc... Eclipse suck even more since plugins are
developed ad-hoc, plus getting all this stuff that is developed
independently to actually work together is nothing short of a miracle.
But when something changes usually everything breaks, because there is
no way to actually have versioned plugins, where your project uses the
same development environment for the duration, then you have maven
that most people have a super hard time using because it's a complex
system with a lot of flexibility, it's great if you know what you are
doing, but sucks if you are just starting out.