jPCT goes Android

[EgonOlsen]

I did some tests (like mentioned in the thread on JGO), and the result is: The Samsung can do 3D, just not with the Dalvik VM. I've written to their support (couldn't even select the phone from the list...the don't seem to like it), but i don't expect much...

[JavaMan]

So much for Google's claim when Android came out:"We're going to have OpenGL3D Graphics on compatible hardware."

[raft]

so what's the final status of this port ?

if i get it correctly, jPCT can render in Andoid but Android HW support isnt there yet. But it be will someday for sure.

collision detection is too slow because the phones lack an FPU. i think jPCT can still be very valuable without collision detection. isnt it possible to implement collisions without floats ? ie: using integer values with some proper scaling

[raft]

forgot to say: a friend of mine has a HTC Tattoo with Android 1.6. if you provide a test app we can run it on device

[raft]

and what is the status of your Samsung after applying the fix at JGO for HW acceleration ?

[EgonOlsen]

I haven't seen this "fix" yet. Thanks for pointing that out. Maybe i'll have another look at the port, but to be honest: My motivation to do so hasn't increased. At first, i'll have a look at the differences between 1.5, 1.6 and 2.0. If it's not possible to support all three versions with one source code, i may ditch the whole thing anyway.

In addition, i have to merge the changes that i made to jPCT in between into the port, which is really annoying work to do...

[raft]

just to make sure you saw my previous posts. they were three in a row so i guess you only saw the last one

[EgonOlsen]

I have noticed all your posts, don't worry... I've tried the fix and it works that way. Strange thing is, that i already tried this myself but using the default method for setting the depth instead of writing my own config chooser and that didn't work. Anyway, Dalvik's performance still sucks. I'll try to merge my post-port-changes into the port and decide what to do with it afterwards. 3D in Java is a small niche...3D on Android isn't even that. I'm not conviced that all this work is worth anything with the current state of hard- and software of these smart phones.

[raft]

how much sucks ? what fps at what polygon count ?

[EgonOlsen]

It's not sooo much about polygon count, more about doing additional calculations like simple rotations, animations...let alone collision detection. And memory is really limited...you can't do very much before running into an out of memory. I can still slightly improve this though.
I'm half way through merging the current jPCT version's changes to the port. The overall process is really annoying. The phone is sooo slow and so is the emulator. You could be 10 times more productive if it wouldn't take ages even to initialize the simplest scene.
A rough estimate are 20fps for a simple scene. My test case is a plane, two trees and a rock and that thing runs at around that speed on my phone. It's not that bad, but not very impressive either. Plus some stuff just doesn't work. Linear attenuation of light sources for example took me whole evening just to figure out that it doesn't seem to work properly neither in then emulator nor on the phone...

[raft]

i friend of mine had an android developer phone: HTC Dream

for cpu, it's written:

CPU: The MSM7201A is an ARM-based, dual-core CPU/GPU from Qualcomm and contains many built-in features, including 3G and a GPU capable of up to 4 million triangles/sec. It has hardware acceleration for Java,[23] but this does not accelerate execution of Android applications, as they are targeted to the Dalvik VM, not the Java VM.

which really doesnt make any sense to me. how can not it accelerate android apps if they use native interface

[raft]

jME team announced jME3 will support Android: http://jmonkeyengine.com/blog/blog/2010/02/10/android-support-confirmed-for-jme3/

[EgonOlsen]

Sure...that's the second time they are announcing this.  Android's VM isn't really able to handle jPCT...not performance and not memory wise...i doubt that it can handle JME. IMHO, Android support will never make it into JME...but we'll see. Regarding my own stuff, i'm still undecided. I don't like the fact that they are spitting out Android versions as if there is no tomorrow. It's impossible to test on 1.5, 1.6, 2.0, 2.1...and which one should one target

[raft]

arent the SDK's backward compatible ? you can follow the same strategy as you do for desktop jPCT. ie: target a reasonable lowest version and additional features may depend on running version

emulators support all versions i suppose. if your concern is real life testing, community would do it

for performance and memory: i dont think google would let go Android, possibly it would be in market for a long time. in time new phones' performace and memory wil increase for sure.

last month i've joined a seminar in a university about game development. one of the speakers was a turkish guy working at heavy iron studios. someone asked how to decide minimum requirements of a new developing game, he answered: target the highest hardware available on the market. minimum time for a game development is 1-2 years, and after that much time the highest hardware of now will be average. i suppose same applies here

anyway, it's your engine and your call. but if you port it to android, i will -at least- attempt to make a light karga on top of it..

[EgonOlsen]

I'm not sure if they are backward compatible...code for 1.1 didn't work on 1.5. When i find the time, i'll look into it...