jPCT goes Android

zammbi · April 22, 2009, 10:02:27 AM

Well I seen a lot of full 3d games, so it has to be possible $:-\$

EgonOlsen · April 22, 2009, 10:23:53 AM

It used to work with the old SDK. The examples for the new one work too, but their integration in the system itself seems to be different than what you get when starting your own Activity. Anyway, i don't like the whole feel of the platform, performance seems to be worse instead of better and the documentation is really lacking.

fireside · April 28, 2009, 03:33:04 AM

I just saw this:
http://www.brighthub.com/mobile/google-android/articles/32012.aspx

It would be nice if you could get it working. They may have an app store something like Apples.

raft · April 28, 2009, 04:35:04 AM

andoid has a store indeed. google for 'android market'

EgonOlsen · July 09, 2009, 11:12:48 PM

I've given the 1.5 of the Android SDK release a try. They have reworked the GL related stuff again and added a class to ease things...and it really does. For now, the port from 2007 works fine again (but still no hardware acceleration). However, i've to bring this sucker up to the current version of jPCT, complete it and see what happens then...i'm not expecting too much...

EgonOlsen · July 12, 2009, 11:21:12 PM

Update: I've ported the important parts from jPCT 1.18 (without any further refactoring, which is needed...) to Android. Performance is better than with the old port, the bug with multi texturing in the emulator is gone

. Sadly, there's another bug in the emulator that causes vertex lighting to be wrong (http://code.google.com/p/android/issues/detail?id=1709...why not vote for it!?), which is pretty annoying

. I'll continue working on the rest of the code though...

zammbi · July 13, 2009, 09:08:34 AM

Says the issue has been closed.
I hope you will be able to release something. Seems Android has come to NZ so I might buy one soon and start some development.

EgonOlsen · July 13, 2009, 11:21:42 AM

Yes, they have closed it today. About time after more than half a year...

AGP · July 13, 2009, 08:34:41 PM

Does closing mean they solved it? If so, does it mean we may get an Android version some time soon?

EgonOlsen · July 13, 2009, 10:27:29 PM

Quote from: AGP on July 13, 2009, 08:34:41 PM
Does closing mean they solved it? If so, does it mean we may get an Android version some time soon?

I guess so, but i'm not 100% sure. It's closed with status FutureRelease, so i assume that it'll make it into,well...a future release. Not sure, if that means that it'll make it into the next one. I think it should, because it really hurts OpenGL ES with the emulator but maybe that has low priority anyway.

EgonOlsen · July 14, 2009, 11:30:21 PM

I now have a stripped version of jPCT...not really finished but somewhere in between and i tried to load the fps-example in Android. After bothering with some memory restrictions (i can't find a way to increase the VM's memory...), it somehow worked. But that Dalvik-VM is so f*'!"%&ing slow, that you can't use any advanced feature like collision detection without reverting to seconds per frame. All it seems to be to good for, is to rotate some cubes or similar and it's questionable if you need something like jPCT for that. Anyway, i'm going to work further on the port tomorrow and see how this turns out...

It was fun to remove lots of legacy code, which isn't needed on Android, from jPCT anyway...

zammbi · July 15, 2009, 10:27:41 AM

Slow on the emulator or the device itself? If people can port a quake 3, surely jpct would be fine...

EgonOlsen · July 15, 2009, 10:54:56 AM

Yes, they port a Quake3 level VIEWER...i can do that too with mediocre performance. But as soon as you add something that a real game requires, like collision detection let alone adding a physics engine, you are stuck. The device has no FPU. That doesn't really matter that much for the graphics itself because that's basically pushing data chunks down the GL pipeline, but for any floating point calculation, it simply kills performance. A mobile device that claims that it can do 3D, that even may have a dedicated GPU, should have a FPU IMHO.

Anyway, i'll try to optimize some floating point code and see if that helps.

EgonOlsen · July 15, 2009, 08:16:36 PM

I managed to improve the performance somewhat and streamlined the api some more, but i think that i need an actual device to make real progress. As slow as Dalvik is, the emulator manages to render around 40-50fps in the fps demo on a lowly Core2 Duo @ 2.2Ghz (my dedicated Android development machine...

), but only IF (BIG IF!) i omit the actual rendering call. Adding this call, performance drops to 2-6 fps, which is abysmal. The software renderer that the emulator uses is extremely slow and hardly usable at all. An actual device may render faster because it has dedicated hardware for this (or hasn't it?...3d seems to be deeeeeep down on the priority list. I can hardly get any information about that. The Samsung i7500 looks promising, but even samsung doesn't mention its cpu type let alone if it has a gpu or not), but then again, it's cpu is slower...

zammbi · July 16, 2009, 01:42:28 AM

Well what I last read is that the emulator is still slower then the device. There's a large range of derives too. I might get the Magic.