Nah, dirty rects almost completely useless for me - we have a lot of movement and a lot of overdraw.

The speedup difference between 50 and 150 draw calls was actually fairly negligible - maybe a 10% boost. However... I finally put VBOs into the sprite engine. Woah! What a difference. 60fps nearly all the time, just like that. Because of how VBOs work I couldn't interleave writes and draws on a state-change basis any more; it's back to writing all the sprites in one go and then rendering everything in one go. But even so - much faster.

One thing in particular may be helping here, which is that I use GL_STREAM_DRAW_ARB and GL_WRITE_ONLY_ARB and map the VBO. This means the data that I write to the buffers is written straight to the card, probably even bypassing AGP RAM, and especially importantly, it completely bypasses any RAM caches on the way.

So: VBOs FTW! I can still implement band sorting but I'll have to write my own much faster interval tree class.

And then I'll have a look at optimising the sprite atlases depending on adjacent sprite image usage and feeding back a data file into the sprite packer.

After that it'll very likely be back to being fill-rate limited like it was 7 years ago when I first wrote the damned thing! But this time I can fill 30x as many pixels

Do it now! Any other method is totally obsolete by the looks of things.

Cas

I'm supposed to be releasing on Monday! Changing the whole drawing system is probably not worth it at this point. Maybe for updates, though. The game stays around 30 FPS but I've already got a few optimizations in mind that I think could definitely get it to around 60.

Well I looked into it, and apparently it does via an OpenGL ES extension. So if I had the time to drop in some optimizations the game could really benefit from a few. I've used FBOs in a couple places, but no VBOs.

That's after 563.75 secs (49696 total ticks). Frame rate dropped to about 45fps with over 2,300 sprites and well over 120 gidrahs. Still not good enough!

There is a reasonable amount of waste going into immediate mode rendering which I will slowly remove over time and replace with triple buffered VBO code.

Collision detection seems to be taking too long - I may try switching to cell-based collisions instead of the quadtree, though this might well not really have that much of an effect. The real problem here is that so many gidrahs are packed tightly together attacking some walls in this test - perhaps I should implement a bit of that behaviour to keep them apart.

As we can see though by far the biggest single waste is writeSpriteToBuffer still, which honestly should be far faster than Java allows it to be.

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