For targeting Windows/Mac/Linux CPP what size would you recommend we keep our tilesheets? We were sticking to 2048x2048 but have been told that most computers could handle double that at least.
I tested tile sheets of 4096x4096 on a 9 year old computer and sometimes it performed well and others not so well - so it wasn’t clear to me whether there was something else causing the sporadic slow down.
Would we be OK having such big tile sheets? This is for a recently greenlit project on a relatively short deadline - so we want to support as many systems as we can but also don’t have huge amounts of time to do anything too clever
You should always try to use the smaller one to optimize GPU memory loading times, but 4096x4096 on pc is ok. On phones is better if you can to target to 2048x2048 if you whant to reach old phones. If you try to use an unhandle resolution the app will just crash. I don’t think draw performance is related to the size of the texture, unless you are constantly uploading the texture to the GPU ram.
Direct3D 9_1 & 9_2 can use a max texture size of 2048 but I’m not sure there are still computers using this. Direct3D 9_3 can use a texture up to 4096. Direct3D 10 => 8192 Direct3D 11 => 16384
So I guess using a max texture size of 4096 is good to have a good compatibililty.
Also, big texture size may require some memory. So you can reduce memory usage using different texture size depending on the screen resolution.
According to Steam there is only 0.11% of DirectX 8 and 1.62% of DirectX9. Have a look here for more stats.
Hey guys, thank you all for your interesting answers.
@DanielUranga grouping the draw calls is something I’ve been doing. Although, with certain games where, for example you need to sort everything by a ‘Z’ axis (top-down games for example) this isn’t always possible - but again, thanks
@juakob We are targetting PC and Mac. when you say constantly uploading the texture to the GPU, is that essentially switching between tilesheets multiple times per frame?
@loudo I think that Direct3D, etc is half the battle - as if the hardware can’t support it then it doesn’t matter about the rest. Thanks so much for the stats page though, fantastic resouce!
@all - OK, so it sounds like software and drivers, on PC 4096x4096 is totally, absolutely fine. However, from what I’ve seen - a large number of graphics cards (particularlly ATIs) only support 2048x2048.So it really looks like that to hit the most number of systems it is actually important to stick to 2048? I guess at this point it becomes a wider question then just OpenFl. But thanks all for the insights, really interesting stuff!
Switching between tilesheets is OK they are all in the GPU memory (if you don’t have the memory full), the slowest operation is to upload an image from your memory to your GPU memory. That’s why in some AAA games you see blur textures, they upload a low resolution texture while they wait for the final texture to be uploaded.
So unless you are using a lot of tilesheets you shouldn’t worry about this.
So @juakob can I just confirm, that switching between tile sheets multiple times during the draw calls (in one update) has no impact on performance? If that is the case I will stop worrying!
Example: draw from scenery tilesheet, draw from game objects tile sheets, then go back and draw something else from the scenery tilesheet ?
The answer is not so easy. Multiple tilesheets will make a difference because that will increment the number of draw calls. GPU work at there best when you send to draw a lot of things in one draw call, but of course you can call draw many times in one update. The performance depends on how much work you do. What I normally do is work with “layers” add all background stuff together in one tilesheet and dynamic stuff in another. So when you draw I use less draw calls (2 calls) than if I had stuff mixed.
In legacy, every Bitmap is one draw call (the newer code has auto-batching that can help improve performance)
drawTiles with one tile is about the same performance as one Bitmap.
drawTiles with many tiles is slightly slower than one Bitmap
If you optimize to use fewer draw calls using drawTiles, you will help improve performance, but any amount of batching work you do (other than potential texture swapping) will improve performance over separate calls. Optimizing 90% instead of 100% might be alright
@loudo From what I’ve seen everything draw is put in to a ‘commands’ array, and then all are then called in one go at the end of the step… but that’s what I think I’ve seen from looking in to it. So don’t take my word for it
@juakob I see what you mean. Yes, I use layering as well, but of course you can’t do that in every game type. Presumably if you draw from a tilesheet, go to another and then return to the first that is not ideal?
@singmajesty Thats pretty incredible that multiple drawtiles are only slightly slower than one bitmap! You can definitely see the power. We are building out a couple platformer games at 1080p and getting an easy 60fps. Its lovely. I think I take your point - that its not totally necessary to optimise 100% and that swapping between tilesheets shouldn’t be too big an issue. Thanks for the info!
