As you are all aware of, JME 3.0 has an Android supports. It’s nice right now, and a lot of efforts have been done, but it’s far from supporting the same features as the desktop side of the engine.
Here is a post to list all the point that could be enhanced on the android part of the engine, and could be a complete project for GSoC.
AndroidHarness flexibility
Right now you’re pretty much forced to have the GLView in full screen if you use the stock Android Harness without overriding some methods. The layout construction is done in the Harness, this should be configurable by the user so he could just have a sub view with the render and some other android native views side by side.
The Harness should give access to the application settings.
Also, recently @iwgeric contributed a way to have a splash screen on android. This splash screen is handled in the activity, and not on JME’s side. Also this spash screen should work the same way than on desktop (by setting an image in the settings). there might be some changes to do in the android build so that the image is correctly copied in the resource path of the mobile project. This splash screen feature should also be extended so that you could display a list of image (kind of a slide show (your company logo, JME logo,the game logo etc…) and even being able to play a video (that’s nice to have).
Way to consult display metrics
One particularity of mobile device is that you can have screens that have the same resolution with a complete different size or proportion.
This is a problem for the UI of course, but it’s also a problem for inputs. Scrolling 1 inch with a finger may return different values on different devices to the engine.
The result, is that if you don’t account for it, is that your game play will look “pushy” on wide screens devices.
To address this issue Android provides display metrics (point density, resolution etc…).
There should be a way in JME to get those information without querying those info from the android Activity
Native calls for critical operations
Dalvik vm, is fine…most of the time, however some operations are slow, one of them for example being native buffer writing.
One could answer “so what?”. I’d say it’s vital because those operations occurs a lot in a skinning process, or inthe recently added batchNode system.
Another obvious example is the jbullet vs native bullet on android.
The android part of the engine could delegate those operations to native code to make them faster.
Audio
We need better audio for android. Right now it’s based on MediaPlayer and SoundPool, but it’s not finished. @prich has contributed enhancements recently, but things remains to be done.
Input handling
Right now android input handling in JME is completely different as any other input handling in JME. This is disturbing for users and doesn’t fit in JME’s API.
Also some weirdness still exists on multi touch event, but recently @techsonic committed a patch.
IMO the whole input system for android should be redone from scratch.
Also we need a proper way to handle text input to nifty textfields but @iwgeric has ongoing work on this and I guess this issue might be addressed before GSoC starts.
Save game through Android embedded database
Right now if you want to save data on an android system from an app you have to use android’s embedded database system. Of course this can be done from the android side of the application, but this implies that the application becomes android specific and that you can’t have the same version for desktop and mobile.
JME has it’s own savable pattern and has an util class called SaveGame that just saves a savable in a system independent way. This could be nice that this SaveGame util was capable of saving data into android DB (maybe via some json serialization or w/e) so you could call it from desktop or mobile with the same result.
Framebuffers, post process and shadows
Android device have nice CPU and memory, but severely lack of GPU power. But i’m pretty sure that this isn’t gonna last forever.
Right now our android renderer does not support off screen rendering in a FrameBuffer, thus preventing the use of post process effects and shadows. adding support for them would be a nice addition.
It won’t guaranty the usability of post process thought, some more work will have to be done (lots of android hardware does not support NPOT textures so there might be changes to make in the FilterPostProcessor).
Physics
Maybe a more general question about physics and not only android related, but jbullet seems barely usable on android, however native bullet gives nice performances.
But native bullet bridge needs to be finalized.
lightweight GUI
This is more an open question.
Right now the official UI for JME is Nifty, however it has poor performances on android once your screen starts to get kinda crowded with controls and fancy effects.
I don’t think it’s a Nifty specific issue, I also used android native UI over the GLsurface and it also severely drops the framerate (you just have to look at the frame rate drop when you hit back and that the quit confirmation popup shows).
So the question is, shouldn’t we make some kind of lightweight UI, based on bitmaptext and quads, to use for HUDS and on-screen information, and keep nifty for full screen menus (being able to disable the background 3D rendering)?
Here it is, my thought on what remains to be done for android. feel free to add your ideas.
BUT, please refrain from posting :
One sentence idea → please elaborate and explain.
features request that are not specific to android and that even the desktop part of the engine does not support.
We won’t make a box world generator for android
Neither we’ll make a MMO template for android…no we won’t !
Right now, the only way to exit the game is by using the back button that is tied back to AndroidHarness to stop the game and end the activity. There is no way to programmatically end the game (ie. through a nice looking nifty menu screen). If you stop the game without using the back button, the game ends but the activity does not get dismissed and you end up in a dead activity with a frozen scene being display. There should be a way to end the application programmatically which causes the activity to automatically be dismissed.
Android Device Life Cycle Events
I think there is a big hole in the current system when it comes to dealing with the life cycle events of Android activities. Right now, the GLSurfaceView and the rendering code are in the same class. This means that if the surfaceview is closed, the game is ended. This becomes a problem if you want to support having the phone switch screen orientations based on the phone internal sensor without losing your place within the game. Right now, if you have the game set to SENSOR and phone orientation is changed, the game is ended and restarted from the beginning. Also, if the phone orientation before starting the game does not match the orientation set in AndroidHarness, you’ll actually see in the logcat that the game starts, ends, and restarts as the phone switches to the appropriate orientation. The rendering and game state code should be in a seperate thread that is kept alive until the game is exiting explicitly by the user or the Android OS kills it to get memory back for other active apps. This way, the games can actually support orientation changes and other life cycle events. When the surfaceview is recreated after an orientation change, it would reattach itself to the rendering and game state code so that the user is put right back where he was in the game, just with a different screen orientation.
Support for Devices without Keyboards
As @nehon mentioned, we are working on a method for users to enter text into Nifty textfields on phones and tablets that do not have a physical keyboard attached. However, I think the real solution relates to nehons idea of a lightweight gui system. I think this gui system should also have a native soft keyboard that works on any platform supported by JME from touch screen pc’s to cell phones.
One area where Android is making improvements in performance is through the introduction of Renderscript. From first appearances and having played with a few samples it does look pretty impressive. It’s facility for building high performance, hardware independent, compute and rendering processes looks just the ticket for a jMonkey optimisation. Currently, the downside is lack of documentation and it’s availability on older devices.
I worked on J2ME a while back, more specifically, I worked on a system which creates a gui through css precompilation.
What I mean here is that, the programmer just codes the game and inserts pre-compile directives. These then get used in the pre-compile step to rewrite the code to match. Through these pre-compile directives, it was possible to have one codebase, and generate Javacode for various devices based on a device database.
Example:
the moment you create your game, you need to set the resolution. This resolution is phone dependant. So, in your code, you could do something like:
//–int screenwidth=${screen.width}
//–int screenheight=${screen.height}
There the screen.width/screen.height would come from the database and the //-- would dignal the pre-compiler to do something with these lines.
This would be a setup which would work for us as well I think, and would seriously simplify developing for multiple different phones. It would still be a different GUI system and thus you’d need a different code base from the Nifty version. But such pre-compile directive could also be used in other areas instead of just the GUI, like the screen width/height example.
True, but this is done at run time. But using my proposed strategy, you move it to compile time. Aside from that, the whole discussion was to switch out Nifty for a more lightweight GUI on Android.
if you create a lightweight gui library then i would recomment to use metawidget 1. Introduction to Metawidget and create a jme desktop/mobile metawidget. You will only have to write the rendering stuff.
Right now you’re pretty much forced to have the GLView in full screen if you use the stock Android Harness without overriding some methods.
Any chance of giving an example on how thats done? Im working on a project right now where I need to integrate JME's GLSurfaceView into a FrameLayout inside my activity, but can't seem to get it working :/
@mradam said:
Any chance of giving an example on how thats done? Im working on a project right now where I need to integrate JME's GLSurfaceView into a FrameLayout inside my activity, but can't seem to get it working :/
Regards, Adam.
If you make a thread for your problem (that also shows what you're trying to do as well as what you've already tried) you'll probably get some answers :) We're trying to keep this thread to discussion on Google Summer of Code.. Thanks!
I’m about to update the topic page for Android… @iwgeric and @nehon… I’m thinking of splitting this into two separate ideas as I think they can be split into “Android Integration” and “Android Functionality (or something)”
Integration is things like saving to the Android DB, Lifecycle issues, and other bits specific to Android (keyboard-less input comes to mind), display sizing issues.
Functionality would be things that are normally addressed by the engine and its integrated components on desktop, i.e: Graphics, Audio, Physics, other input issues.
Does this make sense? I think the tasks posed are excellent, but likely unmanageable for a single student.
Would Functionality include the lightweight gui system item? I think that one would be pretty big by itself. I think the Integration items you listed make sense.
Whoever the member "skye" is just got super confused ;)
@Vortex said:Joystick/gamepad functionality with Android 4.0
Android 4.0 has support for joysticks/gamepads. It would be nice if jME has support for this.
See: http://www.sleetherz.com/2011/10/possibilities-to-plug-your-usb-gamepad-in-android-4-0/
Interesting, makes sense in theory as LWJGL supports such controllers for the desktop system. I'll stick it onto the ideas list and we'll see what happens.
I only did some very minor (and incomplete) grammar and obvious spelling fixes. Will go back over each page with more finesse when more of the pages are complete.
@sbook: Thanks for adding the joystick/gamepad support on the Integration Improvements Page. I haven’t looked in detail too, but I have read some news items about it.
@nehon said:
didn't know you could have a joystick plugged on a phone lol...
In addition to the HDMI output appearing lately, it could make for an interesting gaming experience... Especially as these phones get more powerful and Xbox 360's continue to draw the absurd amount of power that they do.
