-
Notifications
You must be signed in to change notification settings - Fork 38
Attachables exceeding parent diameter are cropped on settle #18
Description
Discovered while working on attachable terrain collisions but not related to it whatsoever.
Not sure if I can explain this in an understandable manner.
What happens is that if attachables are positioned far away from the parent center, they will be cropped on settling to terrain.
This is happening because stuff is being drawn into a temp bitmap with a preset size that is x2 of the sprite's diameter.
The purpose of this appears to be correct draw order for settling into terrain, and the purpose of the temp bitmap sizes is most likely ancient times optimization which is less relevant for today's times.
Since this is all happening in SLTerrain it's probably impossible to access the object-to-be-settled and get a proper diameter that includes the attachables, so diameter is being copied from MOSprite and multiplied to somewhat compensate this issue.
To Reproduce
Attach something far away from parent and make parent settle.
For example, if you attach something to a brain case at X = 50, it will crop because brain case sprite is 14px wide, multiplied by 2 is 28px and is being assigned a 32px wide temp bitmap.
So anything outside the 32px bounds will be cropped.
If the multiplied diameter was 33px, it would be assigned a 64px temp bitmap and cropping would have been partial or none at all.
Expected behavior
Stuff shouldn't be cropped.
Solution
Ideally, the to-be-settled object's diameter with attachables included should be passed on into SLTerrain and the correct temp bitmap size should be assigned.
An alternative solution would be to multiply the attachables-not-included diameter by a higher number to be assigned a larger temp bitmap, but this is a bad fix.
Another alternative solution would be to ditch the pre-historic optimization and switch to using a single, large enough to contain anything temp bitmap for everything.
Tested with 512x512px and 1024x1024px without any performance impact at all, because the temp bitmap is only being created once and constantly drawn into, but this might also be a bad fix.
Needs some thinking.