So, in my 2D game I push render commands to a list, then order them by z, and then execute them from farthest to closest. I wonder if I should worry about overdraw.

In my case I guess I'll have an average of 3 to 4 overdraws per pixel. I always clear the background to sky blue, that's already filling each pixel; then I draw clouds, then terrain, then entities, then UI. So maybe I could do a custom system that can clip some of those elements, at least the background fill, looking at the closer layers. Would that be reasonable, or a complete overkill?

I won't have complex shaders, so I guess that buys me some GPU compute. If I were to have shaders, they'd be simple effects applied at the end to each pixel, or applied to a separate blank texture, which would then merge with the main buffer, so this way the expensive part (either the merging, or the drawing into the lighting texture) would only be done once, and the overdraw would be cheap. Is this generally a good enough approach, just trying to avoid overdraw with the more complex shaders?

Hi,

The best advice I can give you is to measure. If you can draw everything you need fast enough on the lowest device you're targeting, maybe you don't need to go further. Otherwise, try to make changes in you rendering to see if overdraw is the problem: reverse your drawing order to see if your drawing goes faster because some of your cloud's pixels will be discarded early based on its z-value.

In a 2D game, usually you've got a fair amount of alpha in your assets and therefore you can't really go around drawing back to front to get proper blending without bad artifacts. 3 or 4 overdraws per pixels sounds good enough for any GPU. Even mobile GPUs today should be able to blend 4 layers of pixels at the native resolution of the system. I don't know the game you're talking about, maybe you have some cases where it can be much more than that and where occlusion may make sense (like a building being drawn in front of a crowd of people and trees).

Thanks, I guess I'll have to test and measure, as I thought. But when you say I could use front-to-back ordering and Z-value to early out pixels, that wouldn't apply to my case if I had a simple shader or a separated shader like I described, right? Or is early-out also useful even if your shader is the standard "dest = source"?

Since you said you were ordering your render commands by Z, I incorrectly assumed you had the Z value in your entities' positions and that you had depth test enabled. If you can manage to send your 2D position + depth in your shader and use it and enable depth test, then early-out can happen.

Again, those changes are only for testing if drawing front-to-back is faster than back-to-front to know if overdraw is an issue for you, you'll want to keep your original shader in the end.

Ok, I guess the solution is to test and compare.