My game for Android

Thomas. · February 02, 2013, 10:17:34 PM

Because I was very curious to see what CPU cores are doing, I did simple performance monitor.

edit: If anyone would like the source code (of PerformanceMonitor), I can provide.

EgonOlsen · February 02, 2013, 11:50:15 PM

I would be interested in that. You might want to add it to the wiki in the code snippets section!?

kbjansen · February 03, 2013, 02:19:32 PM

your whole project looks just awesome - Congratulations!
Very nice object textures, lights, shadows and impressive 'debug' menu. This CPU-Display looks good, too!
I believe that this will become an awesome game. Please stay tuned and keep us up to date

Thomas. · February 03, 2013, 07:01:34 PM

So, source code of performance monitor with example is on this page

Quote from: EgonOlsen on February 02, 2013, 11:50:15 PM
I would be interested in that. You might want to add it to the wiki in the code snippets section!?

No problem

EgonOlsen · February 03, 2013, 08:48:15 PM

Quote from: Thomas. on February 03, 2013, 07:01:34 PM
No problem

Do you have an account for the wiki? I can't remember...

Thomas. · February 03, 2013, 08:53:09 PM

No, I have not it yet

EgonOlsen · February 03, 2013, 08:57:59 PM

You should have got one now. Check your email.

Thomas. · February 16, 2013, 03:52:57 PM

I started rewriting Jitter Physics to java. This physics engine should be faster than JBullet and supports multi-core CPUs. I have not much free time, anyway now is transcribed about 10% (it is little bit harder than I expected).

EgonOlsen · February 19, 2013, 10:50:06 PM

Quote from: Thomas. on February 16, 2013, 03:52:57 PM
I started rewriting Jitter Physics to java. This physics engine should be faster than JBullet and supports multi-core CPUs.

Apart from the multi-core support...what makes you think that this will be faster?

Thomas. · February 20, 2013, 08:00:40 PM

Quote from: EgonOlsen on February 19, 2013, 10:50:06 PM
Quote from: Thomas. on February 16, 2013, 03:52:57 PM
I started rewriting Jitter Physics to java. This physics engine should be faster than JBullet and supports multi-core CPUs.
Apart from the multi-core support...what makes you think that this will be faster?

jBullet takes about 55ms for 125 inactive boxes and 420ms when are active. Bullet takes 4ms for 125 inactive boxes and 28ms for active. Both are on single-core. I hope, I can get more from java. And why it is so much when no longer active? There is nothing to calculation in my opinion. I did not find any solution how I can get "simple" physics of sphere, mesh and box in jPCT except jBullet...

EgonOlsen · February 21, 2013, 09:40:52 AM

Quote from: Thomas. on February 20, 2013, 08:00:40 PM
There is nothing to calculation in my opinion.

Maybe it takes it's time to determine that something isn't active. It's like with the trees and plants in my rpg. I basically have to scan through all entities in the whole world to see if they will be visible in the next frame or not. In that case, you can optimize that by using some spatial subdivision of course, but in case of a physics engine, that might be different. Another thing might be that JBullet hasn't been written with Android/Dalvik in mind. A lot of things that are free on the desktop are costly on Android. If you ignore this, you end up with really bad performance...but if you embrace it, you can really tweak things. It might be worth a shot to look at the JBullet code instead of porting some other engine and see if there's room for improvement by doing some micro.

Thomas. · February 21, 2013, 10:37:51 AM

I'm not physics programmer, but I thing that when are velocity and every others transformation variables less than epsilon, there are nothing to calculate until some of it will not be changed. I contacted author of java port and he said that it is not optimized for Dalvik and that he do not plans to support multi-core processors. I was thinking about optimize jBullet, but physics is very expensive and without multi-core it be meaningless, in my opinion.

EgonOlsen · February 21, 2013, 02:05:56 PM

I had a quick look at the jBullet sources and they already look pretty much like something that Dalvik might like...except for this Stack-thing. It's doing a lot of Stack.alloc()-calls which refers to some other library that obviously instanciates temporary objects on the stack by doing some twisted bytecode fiddling...and i don't really think that this is a very good idea on Android, because Dalvik actually doesn't use Java-Bytecode but has to convert it.
What i would try to do, is to replace this Stack-class by some pooled entity class, i.e. something that takes the alloc-call and simply returns an instance from a prefilled pool. Of course, these instances would never be returned to the pool and so this implementation will run into either an empty pool or an OOM error, but it might be sufficient to see if that actually can help to improve things.

Thomas. · February 21, 2013, 10:01:23 PM

I agree that the rewriting engine from one language to another would take a lot of time. I'm willing to optimize some of the physics engine and provide the library. I found ode4j, this engine supports multi-core CPUs, but has known bug with ray-cylinder collision. JBullet discourages me from key missing support for multiple cores. What you mean Egon?

EgonOlsen · February 21, 2013, 10:19:24 PM

It's up to you. Personally, i wouldn't rely too much on multiple cores on a mobile device, at least not without giving that quick-and-dirty Stack-replacement a try. It shouldn't be much work and it might help. It it does, you have to modify the JBullet sources to actually deallocate the pooled objects, of course. If it doesn't, you can still try to port something else.