TheoTown

Started by Lobby, August 24, 2015, 11:24:05 AM

Previous topic - Next topic

Lobby

Hi,

I wrote a 2d city simulation game using jPCT as blitting engine. It's still in alpha phase but I'm working on it :)

Homepage: http://www.theotown.de/app/
Google Play: https://play.google.com/store/apps/details?id=info.flowersoft.theotown.theotown

Greetings
Lobby

EgonOlsen

That's pretty impressive...I ended up more or less bankrupt, but anyway... ;)
Are these buildings individual textures or are you using sprite sheets/texture atlas'...whatever you want to call multiple images on one texture?

Lobby

Thank you :)

I use a huge 2048x2048 texture which contains all the graphics (so it's a texture atlas). Textual plugins then define the coordinates of single frames. I experimented on other solutions but the texture atlas seems to be the fastest for drawing.

This is the texture with a scaling of 25%:


A problem are old devices with a too small VM stack. They can't run the game, even if the texture size is supported.

EgonOlsen

I see. That's because a 2048*2048 textures needs 16mb alone on the GPU plus the same amount in VM memory. There are some possibilities to tweak texture memory usage like using 16bit or ETC compression, compressing the VM copy in memory or even swapping it to the SSD by using the Virtualizer class. But I somehow doubt that this will cut it in the low end...how much memory do these devices have available?

Lobby

It has a heap size of 16 MB ;D

ETC doesn't help because it needs for a short time even more memory than without it (I guess it's because of the compressing process). I think it would be needed here to upload just parts of the texture so that the whole image never has to be stored within the VM heap.

EgonOlsen

Even then it wouldn't work. The texture memory counts as VM memory as well. There no chance that this texture can be loaded into 16mb VM. But honestly... who on earth is still bound to such a low limit? Even my first Android device has a 32mb VM (running Android 1.6).

EgonOlsen


Lobby

#7


Thank you, Egon.

Is there any chance to improve blitting performance? Another thing is that uniforms applied to a blitting shader seem to be ignored because blits are drawn batched so just the last set values will be used for one batch.

EgonOlsen

Performance improvements...I don't see much room for that, to be honest. Have you profiled your app? Are you sure that improving blitting performance would actually help?

About the shader issue: Yes, that's caused by batching. You can break batching by inserting some small, transparent blit with another texture here and there but that would actually reduce performance even more (not the dummy blit itself, but the interrupted batch).

So the need for more performance and the option to be more flexible with the uniforms are actually conflicting wishes here...

EgonOlsen

If you can provide me with a test case that somehow mimics what your actual game does, I can try to improve things a little but I can't promise anything...