Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Traits using TerrainSpriteLayer cause OpenGL overdraw #17126
if one Mod attaches another Mod dlls
it creates overdraws for glDrawArrays.
It makes calls for gl_DrawArrays just for nothing. Empty call for all pipeline. it sends Vertexbuffer with 9-14 thousands of bytes but XYZ are zero in that vertex buffer
nobody wants this behaviour. D2k.dll linked just for some classes, not for classes that implements
@alexeik You have two SmudgeLayers as well.
@pchote He wants to skip the rendering call of
tl;dr: Something along these lines would be possible, but there's a fair amount of effort required to get something smart enough to be useful in practise (hence why nobody has done it yet!)
To do that, we'd need to track CPU side if the buffer we were about to draw was 'empty'. This isn't straightforward performance-wise.
How often will a buffer be completely empty in practise though? Probably not ever.
This optimization getting defeated as soon as there are any items at all is pretty sad. We need something that can't be defeated so easily.
The current implementation of the layer deals with drawing items on a per-row basis. We could track the number of items in each row to skip any "empty" rows.
But how often, across an entire map, is an entire row devoid of an item to draw? Worse yet, even if the item is offscreen, we still need to draw the row it's in.
What if we checked whether there were any items in rows onscreen instead then? We could skip those and that would probably be pretty nice!
The current implementation has no quick way of checking if there are items in the section of the each row that is visible - it'd have to check each tile within the onscreen area to see what was in it.
By the time we've checked each tile individually to see what we can skip drawing, we've burned more CPU time then we could ever hope to gain back from saved GPU time.
To have an effective solution, you need something that can efficiently determine if you can skip drawing some parts of the buffer, so you don't burn too much CPU time, and therefore can actually gain something back by reducing the effort on the GPU.
At this stage you need to bring
Assuming you get this far, as long as less things to draw outweighs the cost of more draw calls, and some minor CPU overhead for the bookkeeping, then you're onto a winner.
If it turns out that the 'dumb' implementation of one draw call to just 'draw everything' is faster, then you'd just added a lot of complexity for not much gain.
So for some of our existing layers, the dumb implementation is probably already doing a decent job - but for some of the others a smarter system could make some gains.
It's worth looking into, but getting a useful speedup requires an amount of implementation effort.
@RoosterDragon Practical use of #10246 can lead to usecases where only a few tiles use a secondary palette. However this current implementation still result with a consistent perf with the terrain on all maps, so that's probably the better player experience.
Smudges and resources should not use TerrainSpriteLayer though IMO - the current implementation of smudges breaks TS anyway (where smudges can't overlap or stack, if a cell had a smudge on it, then it is immune for further ones IIRC and some had a foundation requirement with being 2x2 sized).