-
Notifications
You must be signed in to change notification settings - Fork 26
Support lines with any number of points #4
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.
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
base: master
Are you sure you want to change the base?
Conversation
|
@markv12 I actually think we should put this in the asset store (for free naturally), because there's nothing this robust for handling isometric sprites and I wish I had found it sooner. Let me know if that's OK with you! |
|
Thank you for showing interest in the project. Some of the feature additions look good. The distinction between moving and non-moving sprites is also mostly for performance. This is more of a personal preference, but I don't see a ton of value to adding something like Zenject. |
|
@markv12 what are you using to profile LINQ like that? I had no idea it would make such a huge difference with the latest C# and some of its optimizations. Re: moving and non-moving, that optimization can be kept, you just don't need a separate list to do it. Re: Zenject yeah, that's an artifact of implementing this in my game. Definitely not necessary here, and the old-school singleton can be put back easily. |
|
This is awesome, and it's probably the ultimate in complex isometric sprite sorting, but it needs to be optimized! |
I've got a fork where I've refactored this and put in a variety of improvements for my game. This PR is accidentally all Zenject, so ignore the diff—the gist of it can be seen here or in the last commit:
The actual code changes to IsoSpriteSorting.What does it do?
Adds support for lines of any length, and uses some trigonometry to compare points with line segments. This lets us configure sprites that would have previously required splitting, like this escalator:
What else?
It fixes a nasty sorting bug that resulted from trying to track the static sprites separate from movable sprites. There's actually no need for this separation, at least not in my testing—we can keep them all in the same list and rely on
transform.hasChangedto identify the sprites that are moving efficiently. We can then remove theisMovableproperty and greatly simplify some of the topological sorting code.What else???
Some quality of life improvements:
IComparableto simplify the built-inList.Sort