Fix decreased performance of software rendering #22820
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
The software renderer stores textures as run-length encoded chunks of pixels. This makes accessing a pixel (or a range of pixels) in the middle of the texture slow, as the chunks in front of it must be decoded first. To avoid this, the new code creates a single texture for each tile (setting the maximal texture size to the tile size means the following code will separate each tile into its own texture). Those textures will be drawn complete (from the beginning to the end), which makes drawing fast again.
If that is not fulfilled (e.g. very small maximal texture size and very large tiles), the game won't be able to allocate even a single tile texture.
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.
Fixes #22739.
The software renderer stores textures as run-length encoded chunks of pixels.
This makes accessing a pixel (or a range of pixels) in the middle of the texture slow, as the chunks in front of it must be decoded first.
To avoid this, the new code creates a single texture for each tile (setting the maximal texture size to the tile size means the following code will separate each tile into its own texture). Those textures will be drawn complete (from the beginning to the end), which makes drawing fast again.
This was the behaviour of the code before #22579 (it would create single texture for each tile). I compared the performance of this version with the version directly before #22579, it's about the same, noticeable faster than the current master.
Note: the performance slightly depends on the used tileset. I tested it with ChestHole.