In the attached save file, all asteroids can be observed to "snap" their orientation after unpausing.
If the snapping is caused by a timer being reset or a modulus overflowing, it can be fixed by ensuring that asteroids rotate around an integer number of times between timer resets.
[2.0.11] Asteroid orientation snapping
[2.0.11] Asteroid orientation snapping
- Attachments
-
- snappybug.zip
- (7.33 MiB) Downloaded 6 times
Last edited by Gergely on Sun Oct 27, 2024 12:50 pm, edited 1 time in total.
Re: [2.0.11] Asteroid orientation snapping
Thanks for the report however this is Minor issue.
In order for floating point math to not go out of hands, we only use tick value modulo 65536 to animate asteroid orientation and its done in a stateless way.
In order for floating point math to not go out of hands, we only use tick value modulo 65536 to animate asteroid orientation and its done in a stateless way.
Re: [2.0.11] Asteroid orientation snapping
In this case you can fix the bug by rounding each randomly generated period to the nearest value with no more than 16 fractional bits.
If P is the number of times the asteroid does a 360° turn per tick then P*65536 (P << 16) should be an integer to prevent snapping. Which is the case if P has no more than 16 fractional bits.
P = round(P << 16) >> 16
If P is the number of times the asteroid does a 360° turn per tick then P*65536 (P << 16) should be an integer to prevent snapping. Which is the case if P has no more than 16 fractional bits.
P = round(P << 16) >> 16
Re: [2.0.11] Asteroid orientation snapping
Oh, thanks for the tip with 16 fractional bits, it never occured to me, that this would work with floats too.
Fixed for 2.0.17. I ended up turning the random rotation computation to fixed point math.
(Duplicate: 120952)
Fixed for 2.0.17. I ended up turning the random rotation computation to fixed point math.
(Duplicate: 120952)