Stack size is very limited in Dalvik...and so is recursion depth. I could convert the sort to be iterative but that will be slower and consumes additional memory (heap access instead of stack and i would have to keep the virtual stack in memory to avoid object creation). There's an iterative fsort-implementation lying around in the code...just deactivated. I can reenable it and see if it still works. On the other hand: Aren't 1200 single objects a bit too much for Android anyway?

are we talking about polygon sorting or object sorting here ? if objects, merging some objects may help i suppose. i dont know how much this will be possible, since in the course of game, some of the tiles disappear, some of them are highlighted and so on. seems as i will have problem with large levels..

i dont know much about sort algorithms. but as i recall, most (if not all) recursive algorithms can be flattened by emulating recursion. is that what you call iterative sort ?

It's not polygon sorting, it's sorting of compiled instances. Yes, that's what i call iterative sort when you remove the recursion. As said, i once wrote an iterative fsort implementation but never activated it, because on the desktop, it wasn't any faster. I'll enable it for AE and see if that helps and how it performs.

thanks, i will try it ;D i guess this flashSortThreshold is object count threshold to activate iterative sorting, right ?

is it the object or polygon count that sounds too high ? they are just primitive box tiles, 12 polys for each. 400x12=4800 polygons.if i somehow find a way and merge at least some of them, will it help ?

It neither object nor polygon count...it's compiled instance count, which is at least as high as the object count but not quite as high as polygon count.The problem with a high object count is, that the setup work for rendering each of them creates some overhead. It's better to batch as many objects as possible in one. If they need to be split again for rendering, the object compiler will do this anyway but in a way that's more optimal for the rendering pipeline.

i've tried the new jar. it runs without crashing even for 60x20 scene. for 10x10 scene, it's overhead is not noticable. i tried it by setting flashSortThreshold to 15.

Quote from: EgonOlsen

..which is at least as high as the object count but not quite as high as polygon count.

so in this case, sharing compiled data wont help, except for memory of course

Quote

It's better to batch as many objects as possible in one. If they need to be split again for rendering, the object compiler will do this anyway but in a way that's more optimal for the rendering pipeline.

mm, this requires some thought and trials i suppose. as i said, some tiles are highlighted, some others disappear or so. highligting can be handled by other means (an additional plane maybe, or via PolygonManager) but disappearing tiles should be different objects.

with a wild guess, how much gain would you expect from merging 20x20 scene into one ? when this tiles are close to each other or spread around the sccene ?

Can't you merge the level data on the desktop and serialize it using the DeSerializer class? I'm only using objects of that kind, because loading them that way is the fastest way possible (and with the least memory consumption). I've also uploaded a new jar of AE that improves merging performance, but i don't think that this will help much (if any).

To evaluate if some kind of fierce hack is even possible, i have to know more about the structure of that objects. Are they all using the same texture for example?

To evaluate if some kind of fierce hack is even possible, i have to know more about the structure of that objects. Are they all using the same texture for example?

At the moment yes. But this is just a performance test , not the real game and tiles.

Quote

Can't you merge the level data on the desktop and serialize it using the DeSerializer class? I'm only using objects of that kind, because loading them that way is the fastest way possible (and with the least memory consumption).

sure i can. but that will cost me a few things. i prefer text based levels for both small size and simplicity. i can still use them on desktop and serialize objects, but that way level size will get bigger. and manupulating different objects are much simpler. highlighting etc.

i guess i can fit my game to what is possible. my main point is, you made a fantastic job with compiled objects. maybe there is a way to benefit that performance and still preserve usage simplicty of jPCT with seperate objects.

Oh, and while you are there: The Android version of GLFont doesn't seem to set the content of the charWidths-array, so that the width of any string is always 0 when using getStringBounds(). Do you have a working version of this?

Compiling multiple objects into one isn't really possible, because even if geometry and texture usage is the same, the transformations are not. You can't pack everything into one compiled chunk without making the use the same transformation matrix, which doesn't make any sense for multiple objects.