Implement an abstract renderer#163
Merged
CryZe merged 8 commits intoLiveSplit:masterfrom Feb 13, 2019
Merged
Conversation
Collaborator
Author
|
This is still heavily WIP, as there's no unit tests yet, some documentation is missing and it could use some more refactoring. |
This commit adds a rendering module behind a new feature `rendering` to livesplit-core. The renderer here takes a LayoutState and an implementation of the Backend trait. The renderer takes the layout state and instructs the backend to creates meshes, textures and to render them out. By abstracting out the backend we can use this rendering on a lot of platforms without needing to focus on a specific rendering framework.
Starting to clean up the code for bringing it into the master branch.
Before we had an arbitrary array of three indices that we needed to hack around on every backend. This works much better.
This adds a software rendering backend based on the euc crate behind the new `software-rendering` feature gate. This will allow us to unit test the rendering across a variety of platforms without needing to rely on a GPU framework.
We use checksums for the actual comparisons and the actual images are stored temporarily in Rust's target folder. The individual images there are postfixed by the checksum, so if there's a mismatch you can compare the two versions of the image.
74b6559 to
31db167
Compare
In order to run the rendering tests on all the platforms a few changes needed to be made: 1. The floating point accuracy of i586 platforms is inadequate for rendering the layouts with enough precision to end up with the same checksums as on the other platforms. The tests are therefore disabled on platforms that don't support MMX. However Rust can't currently check for MMX, so we check for SSE in the meantime. 2. Big Endian Platforms can't properly decode zlib streams correctly such as present in PNG images. The platforms are in the allowed to fail list for now until the PR I submitted is merged and published. 3. Turns out we can actually support more targets on Windows, such as the i568 target. Support for aarch64 is almost there as well, so we are tracking that now.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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 PR adds a rendering module behind a new feature
renderingto livesplit-core. The renderer here takes a LayoutState and an implementation of the Backend trait. The renderer takes the layout state and instructs the backend to creates meshes, textures and to render them out. By abstracting out the backend we can use this rendering on a lot of platforms without needing to focus on a specific rendering framework.Additionally there's software rendering backend based on the euc crate behind the new
software-renderingfeature gate. This will allow us to unit test the rendering across a variety of platforms without needing to rely on a GPU framework.