Background flashes x_X
New version now with 1300 craps @15fps
HTC Desire HD, Android 2.3.3
Next time, please provide a link… even if it’s the same link as it was. Everybody that didn’t have the demo already would have a hard time finding the link.
Anyway, still the same performance characteristiscs: 300 crabs at 25fps.
I might simply be the case that this device is fillrate limited in your demo.
I may have found a few more fps by eliminating about 1000 Map<String,Integer> lookups per frame. Doesn’t really make a lot of difference to the Galaxy that I can tell - managing about 2,200 sprites here before the frame rate consistently dips under 28fps.
Also fixed the app lifecycle wrt. music not fading out. Is the screen rotation working ok too? I can’t begin to describe just how complex it is to make this stuff work properly 
New version here. Riven - you probably are fillrate limited, yes, if only 300 sprites is all it takes to bring it down to 25fps.
I am quite interested in the idea of using a shader to do the sprite translate/rotate/offset/scale on the GPU… but it does raise the spectre of shady GL-ES 2.0 drivers (let’s face it they can’t even get VBOs working in 1.1 level drivers). And there is every chance that the execution of a vertex shader is going to happen in software anyway 
Yet it still might be speedier, and if it is, then it may make sense to do a whole load of jiggery pokery to attempt to lay out the sprites in RAM in a way amenable to simply writing them wholesale into bytebuffers. Riven’s mapped object stuff would be brilliant but it relies on Unsafe as we’ve ascertained, and that ain’t available. Of course an Unsafe class for ARM could pop out of someone at some point…
Cas
I still have to kill the game using the taskmanager. This is not the new problem that music keeps playing, it’s that the quit-button event is simply ignored, which has been the case since the first version.
As for a MappedObject version for Android, it would probably rely on a single bulky public static final int[] somewhere, of which you control the size with a commandline-parameter, to emulate direct memory access.
Yeah, I haven’t got a dialog in there for the back button (it’s not the “quit” button). The app is in fact behaving properly - if you tap the main home button it’s supposed to go into the background and stay there until Android kills it or you bring it back to the front with a long press and reselecting it or using the task manager. When it’s a properly properly well-behaved app it’ll have a “Really quit?” sort of thing on the back button and do a proper exit at that point.
The int[] array idea sounds like it’d work out pretty nicely without the need for nasty native code. As JNI access isn’t intrinsified anyway it’ll probably be faster to access the int[]. Would it have to be preconfigured in size or could it perhaps be dynamically specified using an annotation or static initialisation of some sort?
Cas
It might behave properly, but it’s the first app that doesn’t ‘respect’ the back-button (every other app closes).
Regarding the ‘long press’ to bring it to the front, how would that work? I can’t even revive an app using the TaskManager, it will kill the selected app regardless of whether you short/long-press it.
It isn’t really that important, you could even initialize it yourself, if I’d make it non-final. On second thought, I’ll probably make it possible to register that int[] per class. As to allow ‘structs’ of more than 1 type. It’s obvious that you’d have to resort to object pooling and compacting data.
At the risk of somebody forking my WIP, I might give it a try. Would ints/floats be enough as for supported primitives?
It does now 
It was going to do an Angry Birds but I haven’t made the dialog yet. Sounds like your phone is low on memory otherwise.
Cas
Ints is best. Raw memory a word at a time. There’s a bug in FloatBuffer such that copying a float[] array into one is deathly slow so avoid float[] like the plague.
Cas
Music is killing fps. It’s about 5fps drop when music start. Otherwise performance is better about 600-700 with 27fps(with 2.2.1 so just support my phone)
Let me know if you need help with performance tuning. I know a trick or two… Still offended that you didn’t use libgdx 
(At least the VBO/VA abstractions that could have saved you a lot of time). VBOs work btw. For sprite batching VAs are usually a tad bit faster, unless you do a fancy fancy trick i can tell you if i get a cookie in return.
Hehe, I’d use libgdx if I didn’t have a massive pile of legacy tools and pipeline and code already Priority #1 is to make it easy to transition for us. Go on then, let’s hear the trick, I’ve got a bag of cookies waiting for you!
Also, how did you get VBOs to work? I mean, they work perfectly well on half the phones I’ve tried it on, and not at all on some others. Of course I wasn’t actually checking that VBOs were available which might account for that But you are right, they are no faster at all, and thus probably quite pointless.
So far the very fastest method I can think of doing this is to actually write the Sprites directly into memory with Unsafe or some equivalent, and then using a vertex shader to do the transform/rotate/scale/etc directly on the data. The only small problem left is the need to sort the sprites before writing the data out but that is remarkably fast anyway, taking only a few % of the total frame time thanks to radix sort being so fast and scaleable.
Cas
I will be including the usual option in actual games to turn the music off so no worries there Though I’m still wavering on 2.2 compatibility just to filter out a load of phones I don’t really want to support.
Cas
I sent you a PM describing the current implementation, that stores all ints & floats in a bulky int[]
Horse, water!
Samsung galaxy tab 10.1
Got a nice 30 fps while 300 crabs. Then it started dropping, ending at 10 fps at 1000 crabs, and 5 fps at 2000 crabs
CLEAR! revives thread
You should try something insane. If you weren’t CPU bound, you’d definitely be fill rate bound, right? So off-loading stuff into a vertex shader should be very cheap (until a certain point of course). My idea would work best with VBOs though… Not sure if you can do it without them.
- Keep one VBO with sprite offsets (x, y positions relative to the sprite center). You only have to change this when you create or destroy sprites.
- Keep a second streamed VBO in which you put the current sprite position (x, y) and rotation (angles) (12 bytes) repeated 4 times (once for each vertex).
- Have a vertex shader that takes in your sprite offsets, sprite position and rotation angles.
- In the shader create a mat2 rotation matrix using cos and sin from the angle. Then transform your vertex by rotating the offset and then adding the position.
If I’m right, this could be faster than what you’re doing. It does however cause you to have to load 50% more data (the angle) into a buffer…
It would appear, I think, that the very process of uploading data in to the buffers is one of the slowest parts of the operation, so that method isn’t going to work too great. I’m hoping to find the time to investigate using an int[] array to store all my sprites contiguously in RAM and cheat that way based on Riven’s ideas with mapped objects and see how that works out. Also I can do some stuff post-sort to get the sprites contiguous in RAM again every frame - likely to improve performance overall as the actual order of the sprites changes only very little from frame to frame.
Cas
Wait a minute! You’re sending texture coordinates too, right? You can compute the texture coordinates in the vertex shader from the offsets!
The texture coordinates depend on the particular sprite image inside the atlas for that particular sprite, so they’re already known at that time and don’t need computing.
Cas