Introduce Renderer.SwapWorldBuffer and Renderer.CloneWorldBuffer.#21237
Introduce Renderer.SwapWorldBuffer and Renderer.CloneWorldBuffer.#21237PunkPun merged 2 commits intoOpenRA:bleedfrom
Conversation
69423ed to
feb09ec
Compare
|
Updated. |
|
This causes glitches on load Issues.mp4 |
|
Outsides of the map also glitch Jiggle.mp4 |
|
Those both appear to be caused by the edge-of-map scissoring not working. Interesting... |
|
I get this wild effect on chrono vortex ending Wowzies.mp4 |
feb09ec to
bf9bfd2
Compare
|
Fixed scissoring glitches and rebased. |
PunkPun
left a comment
There was a problem hiding this comment.
I can't catch it on video, but on maps with a post process effect like desert rats the whole screen jitters. You need to be in an inbetween zoom level. The jitter it just by 1 pixel. In some zoom levels it jitters more than in others
bf9bfd2 to
115aa36
Compare
|
Updated: this is now stripped down to just the API change to allow the world buffer to be read during normal world rendering. |
PunkPun
left a comment
There was a problem hiding this comment.
Interestingly on RA shellmap it feels like every time chrono strikes, performance goes down by about 10%. It could be a fluke but it felt like a pattern to me
The current post processing plumbing isn't suitable for in-world distortion effects (e.g. disruptor/sonic tank beams), which need to be able to access the already-rendered state at arbitrary points during rendering so that they can be occluded by foreground objects.
The main feature of this pr is the new
Renderer.CloneWorldBuffermethod, which serves that use case.At the same time, we are able to avoid unnecessary texture copies in the common case of full-screen effects by implementingRenderer.SwapWorldBufferwhich behaves similarly but destroys the current rendered state - not an issue when we're re-rendering all of the pixels anyway.The first commit is necessary to work avoid the limitations of Sprite and Sheet not being able to change the texture that their texture coordinates refer to.