Main Menu

jPCT goes Android

Started by EgonOlsen, December 12, 2007, 12:20:23 AM

Previous topic - Next topic

.jayderyu

It would be cool to see jPCT go Android. Though I don't know if any of the current users would make a lot of use of it. Then again maybe it would bring in a new crew of people and interest?

Though honestly jME is the LAST Java 3d engine I would put on Android(Except for Java3D). It's bloated and a heavy weight game engine. Android would need a lean and mean version of a SceneGraph or something similar to jPCT. I also wouldn't consider Ardor3d, or Ogre from the CPP entries. These are full fledge apis, not something you can shoehorn into a small portable device just because it has OpenGL ES.

I dropped jME because of it's heavy weight for webstart and applets. If I ever do a full size PC like game. Then yeah I would probably go to Ardor3d or jME. But for smaller, leaner, meaner games. jPCT all the way.

Personally I don't like the answer given for development time. Though the idea has merit. However look at the state of game development companies of Blizzard compared to any other PC developer. It's clear Blizzard doesn't consider "average" future computer a valid enough of a target. If theres complaints about that, then theres more than enough evidence to show that Blizzard does better than most other PC game developers in regards to profit per product. I think it would better to assume current average now, then that becomes the minimal standard after development time. ( my sister in law STILL plays Diablo 2. And she doesn't like any other PC games or VG violence.)

raft

Quote from: raft on February 11, 2010, 09:34:46 PM
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..
i want to make my statement clear here. i dont want to put any pressure on this porting. it's true that i want to do something related to karga on android, but i also want to do several other things about karga. but the reality is i did very less in the past 3 years. i was dedicated to karga when developing it as a full time job, but it's not the case now.

i mean, i dont want to feel guilty if jPCT is ported to android and i dont do much on top of it ::)

@jayderyu
i agree jPCT is a better match for android because of its small size compared to others but others may also have an advantage since they are natively targeted to HW rendering. jPCT does much more in software because of its hybrid pipeline and that can be a bottleneck on such a constrained device.

EgonOlsen

The Android port of jPCT contains no hybrid pipeline parts anymore. It's like using the compiled pipeline in "normal" jPCT, just without the need to call compile(). Anything else doesn't make any sense on Android, because it would be much too slow.
However, what Android really really misses is a JIT IMHO. I've seen benchmarks of other VMs on the Android platform that have one and they all wiped the floor with Dalvik. We are not speaking of a few percent but of magnitudes. I've also watched the presentation from Dalvik's architect where he stated that this isn't needed for Dalvik, because it's already fast enough for it was meant for. I disagree with that. It's just wrong not to include even a simple JIT. If they are afraid of the memory it uses in addition, they can make it optional.
Anyway, i appreciate that raft pokes me from time to time. That's the only reason why i haven't dropped this port completely yet.
...and i predict that we'll never see jME 3 working on Android in a reasonable way. It's like making an elephant fitting into a VW Beetle.

raft

Quote from: EgonOlsen on February 13, 2010, 08:11:27 PM
Anyway, i appreciate that raft pokes me from time to time.
if this is the case, i can happily continue poking forever ;D
you may wish to have a look at jME's progress

EgonOlsen

3 fps in the emulator...stunning...

EgonOlsen

Just to prove that something is there, the test scene on the emulator and on the real device:


runs @ 13fps on a 3.2Ghz Core2 Quad
(with wrong lighting...the software renderer in Android 1.5 has improved but still has some bugs)



runs @ 20fps on the Samsung i7500

raft


raft

i've opened an issue for hardware acceleration on emulator. voting may help:
http://code.google.com/p/android/issues/detail?id=6816

EgonOlsen

#68
Voted! There have been no other issues posted about this? That shows how important that topic is...

raft

i couldn't find any. if i had opened issue that time, we might have a accelerated emulator now ::)

EgonOlsen

#70
I doubt it. 3D still seems to have a very low priority for Android and partially for a reason.

Here's a Quake3 level on the phone in all its 2fps 3fps glory:

zammbi

#71
I hope one day you can get going fast enough. Here's some more nice 3d games: http://androidandme.com/tag/android-3d-games/
Google Earth is also now on Android, though not too much 3d in that...

EgonOlsen

#72
Quote from: zammbi on February 27, 2010, 06:15:19 AM
I hope one day you can get going fast enough.
That won't happen unless hardware improves. The demo uses VBOs to render the geometry and there is no faster way on Android to render. It uses jPCT's compiled pipeline, which reorganizes the parts of an object in a way that minimize state changes and still it's not going beyond 3 fps...it's just to heavy for the GPU to handle. If you disable the actual drawing of the polygons (i.e. commenting out one single line), the fps are between 30 and 50...with a black screen of course. If you enable it again, you are back to 3. Current mobile GPUs are just not build to handle Quake3 levels. Simpler scenes usually work much better.
You may improve this particular demo if you were using the bsp information from a real Quake3 level (not a converted one like i'm using it), but that's not part of jPCT and it won't be.

raft

is there collision detection here ?

EgonOlsen

No. The methods are still in the port but not really usable on the Dalvik VM except for simple scenes. The performance is simply too bad for doing complex calculations. However, that may not be that much of an issue for mobile apps, because the controls have to be simplified anyway to be usuable, so that a much simpler collision detection might work well enough. By the time the devices are fast enough to render such scenes, they should be fast enough for proper collision detection too.