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.

Sign up for GitHub

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

Jump to bottom

performance degrades with many sprites #143

Open

tballmsft opened this issue Aug 5, 2020 · 1 comment

Contributor

tballmsft commented Aug 5, 2020

See Bejeweled. This is due to use of allSprites in too many places (I think).

Contributor Author

tballmsft commented Aug 5, 2020 •

edited

Loading

I think we can leverage change computation to make things faster. Here's the idea

in round N, we have computed the set Delta of sprites/tile that WILL change (between round N and N+1)
in round N+1, we use the changed set of locations (based on Delta) to compute the set of sprites that are PotentiallyAffected and for which we should run rules; sprites outside of PotentiallyAffected do not need to be visit at all

The above requires a spatial index to find the sprites in the 3x3 neighborhood of a given sprite (does it really?).

Once we have paid for computing Delta_N, computing Delta_N+1 should be cheaper.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment