Improve renderer-independent texture format handling, and initial work on indirect texture assets #192
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
Need to implement texture loading support for all formats in tryLoadTextureBuilders().
Going to keep it alongside TextureBuilderIdGroup and eventually delete the others.
Probably going to always pass a palette with texture builders no matter what, since the renderer interfaces need to work with both paletted and true color.
Each frame of an entity animation, etc. should be able to use this for indirect texture references with the texture manager.
This should be useful when trying to allocate entity animation keyframes without worrying about texel data.
The Renderer drawing API is currently broken with several not-implemented macro placeholders and will need to be changed to internally allocate Texture instances for TextureBuilderID + PaletteID pairs as an interim solution to the renderer returning allocated texture handles. Much less of the codebase makes assumptions about textures being 8-bit now, which is a big improvement.
ArenaPaletteName and ArenaTextureName provide direct string references to original assets, instead of having to go through an unnecessary enum-to-string step.
The renderer will handle converting texture builders to SDL textures temporarily until a better design is used where the renderer returns allocated texture handles for users of the renderer to keep track of.
Cleaning up the Texture class a bit.
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 reworks how the engine handles different renderer-independent texture formats. Instead of being explicit about 8-bit or 32-bit textures via Image and Surface/Texture, textures are represented with a TextureBuilder that contains the texels and texture format that is then passed to the renderer for conversion to an implementation-specific format for performance. Design changes to the TextureManager also allow for relatively easy loading of new texture formats like PNG.
The Renderer class now also takes TextureBuilderIDs and can internally manage Texture instances. This is a stopgap until it is able to return allocated texture handles like VoxelTextureID/UiTextureID/etc. to users of the renderer.
TextureAssetReference has also started being used in a few places. This is one step further beyond TextureBuilderID in that it does not assume that the referenced texture is in memory. This class is useful in more memory-constrained situations, especially if modding eventually allows for large textures like 1024x1024. Currently it is not very useful because DOS textures are relatively small in RAM.