mirror of
https://github.com/ppy/osu.git
synced 2026-05-17 05:52:36 +08:00
Bartłomiej Dach
56e17dd7ba
Closes https://github.com/ppy/osu/issues/22086 While this *is* a case of aspire-tier breakage, I hesitate to dismiss it as wontfix, because the fix is somewhat easy, and probably results in better accuracy across the board. The issue in question here manifests when there is a significant amount of lead-in time, like what the beatmap linked in the aforementioned issue (https://osu.ppy.sh/beatmapsets/948643#osu/1981090) does. Both stable and lazer record replay frames using absolute timestamps, *but* the legacy replay format after the first frame uses time *deltas*, i.e. amounts of time elapsed since the previous frame. This means that the decoding process of the replay has to reconstruct absolute timestamps by doing cumulative summation starting from the first frame. When the very first frame has a timestamp that is very large in magnitude (say, like the negative 2 billion that the beatmap in question uses), this will lead to error if the cumulative summation is using floating point numbers, because it will be adding a small magnitude frame delta to a large magnitude cumulative absolute time. Which means that sometimes adding the frame delta to the cumulative time *will not change the cumulative time*, leading to the loss of time and thus replay de-synchronisation. Knowing that the legacy replay format only deals in integral time values, however, this can be circumvented by just using a large enough integral number type for the cumulative time tracking instead. I think `long` in this case can be safely used "large enough" for our purposes: > Console.WriteLine(long.MaxValue); 9223372036854775807 9 223 372 036 854 775 807 ms equals 292 277 024,6269277149 years
56e17dd7ba
·
2025-05-16 12:52:49 +02:00
History