Haven't figured out what's causing the erratic framerate yet Also discovered a lifecycle bug if you hold down the button to get the recent tasks list up - game pauses and never recovers. So don't do that

Whenever someone says "sprites" I get the picture of Pokemon on Gameboy and the old Final Fantasy games on Snes, so I'm having a little trouble imagining how you would put 400 sprites on the screen at the same time... Care to share an example from a real game?(I'm not criticizing you at all, I'm just curious about what game you're making xD)

Aha I can force it to to 16-bit too, didn't realise that would make such a huge difference. So I shall, in the next quick test, when I've figured out how to fix that small lifecycle problem.

@theagentd: so... basically a Sprite is any little rectangular bit of graphics. Once upon a day on machines like the C64 we'd have only 8 "hardware sprites" and a character-mapped background which could be arbitrarily scrolled 8 pixels in any direction, and people designed games around this curious limitation and did pretty well at it though of course it did rather limit the designs.

These days, every single thing you see on the screen is made up from one or more sprites layered on top of each other. Each sprite can be arbitrarily positioned, rotated, offset, scaled, coloured differently in each corner, and arbitrarily transparent, and also each sprite runs its own independent animation program. One small exception in the Puppygames sprite engine is that things like those expanding circle effects and bitmap fonts are actually psuedosprites injected into the scene at the appropriate point. They're not just simple rectangles but arbitrary bits of dynamic geometry, so they're a bit more expensive to draw than plain sprites but that's why there's not that many of them around - we only use them for text rendering and the odd special effect like a radar range or strobe.

It may not look like it at first but Titan Attacks typically has around 500-1000 sprites on screen in any single frame, drawn at 60fps, and each sprite is animated. Some sprites are huge - for example, the background and HUD consists of a few really big sprites - and some are tiny. This is why it always makes me chuckle when people dismiss Puppygames' graphics as being no better than what you can achieve in Flash I haven't yet seen Flash reliably demonstrate maybe a tenth of that performance, typically, and we've been able to achieve that in Java for about 8 years now through LWJGL. Our more complex games like Droid Assault and Revenge of the titans have literally maybe 4,000 - 8,000 sprites in every single frame. This is also probably why though many people like to dismiss our "retro" style as being trivial and simplistic, nobody has actually managed to emulate it or copy it yet because it's actually a lot more involved than it looks.

So anyway: porting Titan Attacks to Android, we're aiming for 30fps on account of the fact that it's almost indistinguishable from 60fps on small phone screens and there's no point in aiming too high just yet what with Dalvik being so lame. This means we need the average phone to be able to cope with at least 1,000 sprites @ 30fps, just to port our crappy Space Invaders game! We could maybe optimise some of that stuff away - at least 300-400 of those sprites are particles in things like bullet trails and explosions and smoke from ruined buildings in the background, so we'll be looking to tweak in those areas to get the performance we need.

Would I be mad to mandate Android 2.3+? I know that means quite a few of you couldn't test but... it'd also mean a far greater likelihood of only people who have phones fast enough will be trying the games out.

Fallback to what, though? No explosions? It's hard to really sensibly draw a line at this point. Even relatively modern Android phones are getting risible framerates because they were cheapass in the first place :/ Myself, I can't see why anyone would buy one for less than $500 and then expect it to be "good" at stuff but there we go

Indeed VBOs don't seem to work at all.The reason for going for 2.3+ is to filter out hardware released 2 years ago that's just not fast enough anyway. And: incremental GC in 2.3 That's very handy in an action game if you don't want to have to arse about with object pools polluting your nice simple to understand code everywhere. The sprite engine is already hairy enough with all the object pooling it has to do, and as we all know, object pools are the enemy of the actual required GC that the collector has to do.

You are doing a lot of math on the CPU that I think could/should be offloaded to the GPU. I don't know how you're batching your drawing, but it seems to me that all of the transformation could be done in a vertex shader while not having to submit much more data to the GPU...

Ok, new version's up, and hopefully screen rotation and lifecycle management all work now. Also I tried that background hack - maybe it'll get us a few more fps. Gentlemen, fire up your phones and benchmark! Now what I'm interested in is the point at which it consistently drops under about 27fps and stays there, and also whether it seems smooth or erratic.

It's now 1000 crabs that mine seems to slow down, 900 is 30 steady, 1000 and it starts to wobble, anything from 17 to 29, normally around the mid 20s. The last version seemed to quit fine, this one seems to leave the music playing after I hit home. Roll it back to the previous version .

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org