Render GUIs on a texture, then render that texture on screen

[ivan-mogilko]

Resolves #1838 and will potentially help #1837 after merged/ported to ags4.

After implementing rendering GUI controls as separate textures (see #988 and #1393 for details), it turned out that the implementation has a serious mistake: any additional visual effect applied to a whole GUI, such as Transparency, would apply incorrectly, as controls would blend with GUI background using same effect, producing different visual result.

I guess there may be different approaches for resolving this problem. But we also assume that in the future GUI may be assigned more various properties, such as rotation (already exists in ags4), which makes it more difficult to clip controls to GUI borders on screen, or custom shaders, which would be expected to be applied to GUI & controls in whole, while each control might also have its own individual effect, making things more complicated.

Therefore the chosen solution is to render whole GUI on a texture and then render that texture on screen. This is kind of similar in logic to what is done in software rendering, except still done as a scene render by GPU, without bitmap operations.

Additionally, same technique may be used later for anything, if necessary (maybe for room viewports, if we decide to support translucent viewports sorted among GUIs, etc).

What this PR includes:

• Direct3D and OpenGL renderers support creating a DDB object (texture) with a purpose of being used as a render target.
• Both support rendering a Sprite Batch to a custom render target, instead of a backbuffer. This resets all parent transforms for that batch, starting clean on a new target, but all the nested batches will be also drawn on same render target, and have merged parent-child transforms.
• In "draw controls as textures" mode engine will now render GUIs each on its own texture buffer, then render resulting buffers as common sprites on screen. The GUI parent transparency will be applied to that final buffer (not the contents).
• For Direct3D we have to reset all these buffer textures when changing display mode, unfortunately. This is required for D3D to be able to reset its mode. They will be recreated on fly during the very next game redraw.

[ivan-mogilko]

Update on this: currently there are at least 2 known errors in OpenGL renderer:
1. GUI contents are always drawn 1x1 pixels down-left.
2. GUI contents are missing (either not drawn, or draw offscreen) in "render sprites at screen resolution" mode (which is quite strange, since the gui contents are not drawn on screen directly anymore anyway).

EDIT: error 2 fixed now.
EDIT: error 1 seem to be fixed now.

[ericoporto]

Hey, this works for me! Tested and both error 1 and 2 seem to be fixed indeed! :)

I think you fixed the caveat you mention in #1837 , on item 1 , about rendering at screen res.

[ivan-mogilko]

I need to tidy (squash) the commits again, and there's also one logical mistake about switching render targets that has to be fixed (it is not seen in the current setup, but may surface if there's more complex batch configuration).

I think you fixed the caveat you mention in #1837 , on item 1 , about rendering at screen res.

No, I did nothing in regards to that.

[ivan-mogilko]

I wanted to do some additional refactor, but met couple of difficulties. So, I'll merge this pr first and make another attempt on refactor bit later.