Android NDK target?
Monkey Targets Forums/Android/Android NDK target?
| ||
| Working on a project that uses Box2D, and it flies at a steady 60fps on my iPhone and my older iPad. But on Android, it struggles to maintain 30fps on even my decent Galaxy S5. And I'm guessing this is a Java related performance issue. I have minimized realtime new's so I'm not hitting the allocator or garbage collector. The next step would be investigating switching from the Android target (Java based) to a NDK one that uses C++. I've seen some mention in the MX1 source code about it, but it doesn't appear in Ted. So anyone know anything about the MX1 NDK target? Or is there a NDK target floating around that I could take up the baton on? |
| ||
| hello, i really dont know anything about Box2D nor NDK and so but.. i had an issue with usin mojo2 with android... i made half year ago mojo2 version of my game, tought it would make it run better and look cooler since opengl stuff. but game ran a lot slower with mojo2 than mojo1... what i found out when searching was that apparently usin opengl stuff with Android (in monkeyX 1 ) has/had some sort problems... i tought it might be your problem there? |
| ||
| As far as I remember, Mark had this NDK target once within Monkey 1 but removed it again. I never got to working state actually. So I guess you have to live with that or move on to Monkey 2. |
| ||
| Simonsuuri, I'm using direct OpenGL ES2 (well through Monkey). But I'll poke around and see if it's spending more CPU time in the update or render. Don't care which it is, as long as there's something I can do about it. I know Java can be slower on Android, but 5x slower seems like something is wrong. Xaron, Monkey2 doesn't have iOS yet and sounds like Android isn't complete. From what I have tested that is working it does look great though. So that's on the horizon, but not immediate. |
| ||
| I built a C++ based build system that works with Android and OpenGL ES (and also builds Mac, Windows, soon iOS, Apple TV, it's SDL2 based). I tested it with a quick "crunch" test I did with Box2D and OpenGL and it easily runs faster than Monkey/Android/Java. I can add 10x the number of b2Body's, do physics and rendering and my S5 doesn't even break a sweat at stays at 60fps. Luckily the game was still half way built, in the prototype stage, so I'm gonna reimplement in C++ rather than trying to force Monkey/Java to do things it wasn't suited for. Doh, was hoping to make it work in Monkey X, but the native C++ route has far less speed bumps, and Monkey X (1) seems like a dwindling option with development shifted to Monkey 2. |
| ||
| Im test building on an iPhone and also Android the Android is 15 FPS while the iPhone blazes along at full frame rate. Im using writepixels to an image for 2D unfortunately the Android is not happening ? Has anyone got any ideas how to speed it up ? |
| ||
| What version of monkey are you using? |
| ||
| I don't have any advice to offer, just experience. iOS boils down to native C++ code so it's going to run the most efficient. Android is translated into Java and run as JIT byte code, which will not run as fast. Often it's enough as long as you using the GPU to do all your rendering. But if you are drawing individual pixels every frame (or in my case physics and lots of drawing) then it's going to really struggle. On Android with Monkey, it seems like moving data from CPU to GPU is a real performance bottleneck. If you can, use sprites not pixels. It is way faster to draw 16 16x16 sprites than say equivalent 4096 pixels separately. Or even 256 individual pixels. |
| ||
| Are you optimising your Monkey code a bit to help Java out - e.g. object pooling, 1D arrays etc.? Java is obviously slow compared to C++, but it doesn't have to be terrible. I'd be surprised if moving data from CPU to GPU is intrinsically slower, unless Mark has implemented it some way that could be improved. My apologies if I'm teaching Grandma how to suck eggs here! |
   |