My very simple match three game (video in this thread) takes around 10 seconds to load, and then during play, the framerate is anything but smooth (jumps around between 30 and 50, sporadically, but mostly holds to low 30s).
I’m running the release apk, so all the logging/debugging overhead should be gone, right?
Is there anything else I have to do, to get a decent loading time, and good performance?
is the board batched? or a custom optimized mesh?
If you bruteforce render it with cubes you loose lot performance.
Depending on it being possible to turn the camera, you could even make it a texture on a quad.
I have 2 meshes exported from blender (one for cube, one for the wedge) and I basically just clone those (in code), to place where needed.
Unless jMonkeyEngine does software rasterization on Android, I don’t understand why such a simple scene would be slow - These are just simple cubes, and there are less than 150 of them at any given time … it should be no problem for anything with a GPU.
Android gpus really suck ass in short.
150 objects is to much , reduce them the draw call overhead is slowing this down not the polygon count.
You would have a massive optimisation just by making that bottom plane a single square. As far as I can tell, there’s no need for it to be composed by individual cubes; there must be ways you can “fake” that animation.
@Goran said: I have 2 meshes exported from blender (one for cube, one for the wedge) and I basically just clone those (in code), to place where needed.Unless jMonkeyEngine does software rasterization on Android, I don’t understand why such a simple scene would be slow - These are just simple cubes, and there are less than 150 of them at any given time … it should be no problem for anything with a GPU.
Two cases, tell me which you think will be more efficient.
Problem: you have to ship 150 pencils to the other side of the world.
Solution 1: you individually package each pencil into its own tiny box. You create 150 separate address labels (all going to the same place) and you hand them to the mailman one at a time. Sometimes you wait until the next day to hand them to the mailman.
Solution 2: you have one box and you put all 150 pencils into it. You create 1 address label and hand the one box to the mailman.
Which do you think will be faster? If you are hand-writing each address label, how much longer do you think the first solution will take?
Solution 1 is tolerable on desktop because the packaging and addressing (preparing the geometry for rendering) is much faster. Furthermore, everything else leading up to rendering will be faster. On Android, this is not true at all and performance will be abysmal.
On the other hand, Solution 2 will fly on either platform. So much faster that it’s not even in the same ballpark.
From what I know about desktop OpenGL: geometry is typically preloaded into some buffer object on the GPU, and you only need to send the ID of the buffer, along with a world transform matrix, to actually draw the object. So, it’s not that much data, even for hundreds of objects.
Also, I think OpenGL will actually cache commands before sending everything (in bulk) to the GPU … Or does that require display lists? … I’m not really sure, but I guess it’s a different process on Android.
I just didn’t expect the draw call overhead to be so high … but ok, I’ll trust that the hardware is under-powered.
Anyway: any ideas on how to improve start up time? It takes ~10 seconds for the app to load, which is quite the wait.
If there’s no way to load faster, is there a way to have a “Loading” splash screen, or something like that?
@Goran said: @pspeedFrom what I know about desktop OpenGL: geometry is typically preloaded into some buffer object on the GPU, and you only need to send the ID of the buffer, along with a world transform matrix, to actually draw the object. So, it’s not that much data, even for hundreds of objects.
Yes, but every objects get culled. Every object has controls run. Every object is checked for transform updates. Every Geometry objects is sorted. Every Geometry object has transforms setup, draw dispatch performed, etc… your buffers are so small as to be immaterial. You still have to make a few trips across the bus for every one of them. More trips if the materials are different, textures need to be swapped, and so on. So your buffers may already be there but you still have 150 times of a bunch of other overhead. The time it takes to actually draw those 24 triangles per object or whatever is such a tiny percentage.
In this case it is better to batch. A mesh of a few thousand vertexes will render much quicker than it takes to do all of that other stuff.
Batch, or replace the background with a static texture that looks the same, that should also reduce load time a bit.