Added shadow rendering for resource sprites

[Mailaender]

Closes #18780.

[pchote]

You don't need to touch TerrainSpriteLayer at all (this just makes things worse for all other consumers of that code). Just add a second TerrainSpriteLayer in the resource rendering for the shadows.

Please also only enable this if the mod explicitly sets Shadows: true on the traitinfo - making mods that don't have resource shadows render blank sprites is just wasting performance.

[Mailaender]

I rewrote this. A programming mistake made me think there can be only one TerrainSpriteLayer per tile.

[pchote]

This doesn't look right. The kv.Value.Clear(cell); needs to run to make sure that the old sprite is cleared if the resource changes to something that uses a different palette.

[Mailaender]

I can't clear the old sprite otherwise I see only the shadows.

[pchote]

Let me be clearer: this will cause corrupted states where two (four if you count shadows) sprites will be rendered on the same cell.

[Mailaender]

I think the resource layer only allows one resource per tile so this shouldn't be a problem?

[pchote]

Like I said in my first comment, the problem occurs when the one resource in the tile changes from type A which uses palette X to type B using palette Y. Adding this check stops the kv.Value.Clear(cell); below from clearing sprite A, which means that both sprites A and B will be rendered even though the cell no longer contains A.

[Mailaender]

That makes things worse:

I pushed it to https://github.com/Mailaender/OpenRA/tree/multi-sheet-resource-renderer as this pull request is in a working condition for quite some time now.

[pchote]

The fundamental problem is that the order that you loop over a dictionary is undefined, so under the old code there is no way to control which layer is drawn on top of the other. This wasn't a problem when the trait guaranteed that different layers never rendered to the same cells, but is a problem now with shadows.

#18982 removed the limitations that forced the ResourceRenderer to use a dictionary in the first place, giving it back control of the rendering order. Your branch reverts all those fixes, so its no wonder it didn't work!

627ac9e shows what I meant, which is much simpler. (EDIT: Updated to new commit with shadow and blend mode fixes)

[pchote]

The ShadowPalette is also a problem, since we're actively removing those from all traits as part of adding support for 32bit sprites. Adapting this PR to use tint-based shadows is easy enough, but requires changes to TerrainSpriteLayer. At this point, if you don't object, it would be easier if I take over and file a new PR for this feature.

[pchote]

Actually, the Sequence-based shadow frames have never supported a separate shadow palette, so adding that here is not needed. Dropping the ShadowPalette definition simplifies this further, and avoids the need for any other changes: 627ac9e (EDIT: Updated commit to remove redundant BlendMode check)

[pchote]

#18982 has been merged.

[pchote]

I filed my rebased/simplified version as #19059, so closing this one as superseded.