Calculate convex hulls in texture space #724
Open
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
adroitwhiz
force-pushed
the
texture-space-convex-hull
branch
from
d48d426
to
81f210a
Compare
adroitwhiz
force-pushed
the
texture-space-convex-hull
branch
from
81f210a
to
d943c89
Compare
Previously, the `color-touching-tests.sb2` test "touches a color that doesn't actually exist right now" would use a sprite with ghost 50, blended against another sprite, to create the color that "doesn't actually exist" when the query sprite is skipped. Unfortunately the blend result was near a bit-boundary and, depending on the specific hardware used, that test could fail on the GPU. When the renderer uses the CPU path this test works fine, though, so the existing problem went unnoticed. To fix the problem I changed the project to use ghost 30 instead, which results in a color that is less near a bit boundary and is therefore less likely to fail on specific hardware. As an example of what was happening: the `touching color` block was checking for `RGB(127,101,216)` with a mask of `RGB(0xF8,0xF8,0xF0)`. On the CPU it would find `RGB(120,99,215)`, which is in range, but on some GPUs the closest color it could find was `RGB(119,98,215)` which mismatches on all four of the least significant bits -- one of which is enabled in the mask.
Fix direction for Y iteration on CPU path For some reason the JavaScript engine insists on running the code instead of doing what the comment says. I guess they should match. Fix (x,y) => point[] conversion comments
This should ensure that CPU/GPU diffs are actually useful, and not improperly shifted.
adroitwhiz
force-pushed
the
texture-space-convex-hull
branch
from
d943c89
to
b911304
Compare
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.
Depends on #479
Resolves
Resolves #208
Resolves #528
Resolves #592
Proposed Changes
(The last 4 commits contain actual changes--everything else is part of a rebase)
The first commit adds some handy debugging code that draws drawables' convex hulls when
getBoundsis called and there is a "debug canvas". The code previously only drew bounding boxes. This should make it easier to debug convex hull issues.The second commit changes the convex hull calculation to operate in texture space--it now samples every texture pixel rather than every "Scratch-space" pixel. This ensures, for instance, that every pixel is counted on double-resolution bitmap sprites.
The third commit incorporates the bounds expansion from #529, but in a more precise way that doesn't "overshoot" at all--it now precisely calculates the dimensions of a rotated costume pixel and expands the bounds outwards by that much.
The fourth commit makes drawables now mark their convex hull as "dirty" (needing to be recalculated) if their skin's silhouette is updated. This is used for SVG skins, which update their silhouette every time a larger mipmap is calculated.
Reason for Changes
This should make the calculation of sprites' "precise"/"tight" bounds, which use the convex hull, visually match up much better with reality, and prevent sprites from being cut off as a result of their bounds being calculated too far inwards.
Test Coverage
I'd love to add convex hull tests, but I'm not sure how to run Node unit tests on real skins.