New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rendering system overhaul #6693
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Draws now immediately apply to the render target, in stead of accumulating on the drawing surface. This means textures can start to be used for drawing in stead of surfaces, and both systems should be able to be used interchangably for now. Some things have been broken, including but probably not limited to: * background blur * the occasional direct SDL_FillRect call * floating labels * map screenshots Some things will be broken if textures are used for drawing: * widget restore images * other screenshots * clipping areas However, this is the first step towards proper high-dpi hardware- accelerated rendering.
Label background restoration is still a little broken, but that is slated for removal anyway.
This is now done in a way compatible with hardware rendering, but is not yet behaving correctly.
This fixes most problems with floating labels and background redraws.
That being when the logical viewport is slightly offset on the underlying render target. SDL doesn't give a way of determining this offset, but it's straightforward to calculate.
This will correctly work for both the old surface blit calls, and the new texture blit calls.
It can now be phased out. Everything should now be fixed and working except map screenshots.
If you are forcing hardware rendering, this check is unnecessary.
github-actions
bot
added
Building
Build-time issues.
Help
In-game Help functions
UI
User interface issues, including both back-end and front-end issues.
labels
May 8, 2022
mesilliac
force-pushed
the
rendering_system_overhaul
branch
from
May 8, 2022 00:39
93247ff
to
36ece6b
Compare
Clarifies usage of a non-intuitive SDL error code in CVideo::fill.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a basically complete forward-compatible bridging layer for the rendering system.
Everything is now rendering using the new system, but most parts of the code are using a compatibility shim with relatively low performance. Basically to finish conversion to the new high-dpi hardware-accelerated system, everything that is using SDL surfaces and rendering via
CVideo::blit_surface()
should be changed to use SDL textures and render viaCVideo::blit_texture()
.blit_texture()
could be renamed, as it's not really blitting, but it makes it obvious for now that it is a direct replacement forblit_surface()
.A more detailed description of the changes and the new system can be found in the forum post: https://forums.wesnoth.org/viewtopic.php?t=55695
There should be only one thing that is currently broken, which is map screenshots. As i understand it, a solution for this should be able to be forward-ported from the
old_master2018...
branch.