2019-01-24 16:43:03 +08:00
|
|
|
|
// Copyright (c) ppy Pty Ltd <contact@ppy.sh>. Licensed under the MIT Licence.
|
|
|
|
|
// See the LICENCE file in the repository root for full licence text.
|
2018-04-13 17:19:50 +08:00
|
|
|
|
|
|
|
|
|
using System;
|
|
|
|
|
using System.Collections.Generic;
|
|
|
|
|
using osu.Game.Rulesets.Timing;
|
|
|
|
|
|
2018-11-02 18:52:40 +08:00
|
|
|
|
namespace osu.Game.Rulesets.UI.Scrolling.Algorithms
|
2018-04-13 17:19:50 +08:00
|
|
|
|
{
|
2018-11-02 18:51:34 +08:00
|
|
|
|
public class SequentialScrollAlgorithm : IScrollAlgorithm
|
2018-04-13 17:19:50 +08:00
|
|
|
|
{
|
2018-10-30 17:00:55 +08:00
|
|
|
|
private readonly Dictionary<double, double> positionCache;
|
2018-04-13 17:19:50 +08:00
|
|
|
|
|
|
|
|
|
private readonly IReadOnlyList<MultiplierControlPoint> controlPoints;
|
|
|
|
|
|
2018-11-02 18:51:34 +08:00
|
|
|
|
public SequentialScrollAlgorithm(IReadOnlyList<MultiplierControlPoint> controlPoints)
|
2018-04-13 17:19:50 +08:00
|
|
|
|
{
|
|
|
|
|
this.controlPoints = controlPoints;
|
|
|
|
|
|
2018-10-30 17:00:55 +08:00
|
|
|
|
positionCache = new Dictionary<double, double>();
|
2018-04-13 17:19:50 +08:00
|
|
|
|
}
|
|
|
|
|
|
Fix lifetime calculation in overlapping algorithm
Changes to lifetime calculation in scrolling rulesets introduced in
#7367, which aimed to account for the distance between hit objects'
origin and its edge entering the scrolling area, fixed some issues with
hitobjects appearing abruptly, but also regressed some other scenarios.
Upon investigation, the regression was localised to the overlapping
scroll algorithm. The reason for this was two-fold:
* The previous code used TimeAt() to calculate the time of travel from
the hit object's edge to its origin. For other algorithms, that time
can be accurately reconstructed, because they don't have periods of
time where there are multiple hit objects scrolling at different
velocities.
That invariant does not hold for the overlapping algorithm, therefore
it is possible for different values to be technically correct for
TimeAt(). However, the only value that matters for the adjustment
is the one that's indicated by the control point that applies to the
hit object origin, which can be uniquely identified.
* Additionally, the offset returned (even if correct) was applied
externally to the hit object's start time and passed to
GetDisplayStartTime(). In the overlapping algorithm, the choice of
control point used in GetDisplayStartTime() is important, since
the value of the speed multiplier is read within.
Externally rewinding the hit object's start time meant that in some
cases the speed multiplier of the *previous* control point is applied,
which led to hit objects appearing too late if the scrolling rate
decreased.
Because of the above, modify GetDisplayStartTime() to take the offset
into account in all algorithms, and apply the adjustment correctly
inside of them. The constant and sequential algorithms needed no
adjustment from the previous logic, since:
* the constant algorithm disregarded control points, and
* the sequential algorithm would effectively rewind to time = 0,
calculate the absolute distance from time = 0 to the hit object start,
apply the origin offset *to the absolute distance*, and then convert
back to time, applying all control points in sequence. Due to this
it was impossible for control points to get mixed up while
calculating.
As for the overlapping algorithm, the high-level logic is as follows:
* The distance that the origin has to travel is the length of the scroll
plus the distance from the origin to the object edge.
* The above distance divided by the scroll length gives the relative
scroll lengths that the object has to travel.
* As one relative scroll length takes one time range, the relative
travel length multiplied by the time range gives the absolute travel
time of the object origin.
* Finally, the control point multiplier applicable at origin time is
applied to the whole travel time.
Correctness of the above is demonstrated by visual tests added before
and headless unit tests of the algorithms themselves. The sequential
scroll algorithm was not covered by unit tests, and remains uncovered
due to floating-point inaccuracies that should be addressed separately.
2020-02-07 05:46:31 +08:00
|
|
|
|
public double GetDisplayStartTime(double originTime, float offset, double timeRange, float scrollLength)
|
|
|
|
|
{
|
2020-05-22 03:41:56 +08:00
|
|
|
|
return TimeAt(-(scrollLength + offset), originTime, timeRange, scrollLength);
|
Fix lifetime calculation in overlapping algorithm
Changes to lifetime calculation in scrolling rulesets introduced in
#7367, which aimed to account for the distance between hit objects'
origin and its edge entering the scrolling area, fixed some issues with
hitobjects appearing abruptly, but also regressed some other scenarios.
Upon investigation, the regression was localised to the overlapping
scroll algorithm. The reason for this was two-fold:
* The previous code used TimeAt() to calculate the time of travel from
the hit object's edge to its origin. For other algorithms, that time
can be accurately reconstructed, because they don't have periods of
time where there are multiple hit objects scrolling at different
velocities.
That invariant does not hold for the overlapping algorithm, therefore
it is possible for different values to be technically correct for
TimeAt(). However, the only value that matters for the adjustment
is the one that's indicated by the control point that applies to the
hit object origin, which can be uniquely identified.
* Additionally, the offset returned (even if correct) was applied
externally to the hit object's start time and passed to
GetDisplayStartTime(). In the overlapping algorithm, the choice of
control point used in GetDisplayStartTime() is important, since
the value of the speed multiplier is read within.
Externally rewinding the hit object's start time meant that in some
cases the speed multiplier of the *previous* control point is applied,
which led to hit objects appearing too late if the scrolling rate
decreased.
Because of the above, modify GetDisplayStartTime() to take the offset
into account in all algorithms, and apply the adjustment correctly
inside of them. The constant and sequential algorithms needed no
adjustment from the previous logic, since:
* the constant algorithm disregarded control points, and
* the sequential algorithm would effectively rewind to time = 0,
calculate the absolute distance from time = 0 to the hit object start,
apply the origin offset *to the absolute distance*, and then convert
back to time, applying all control points in sequence. Due to this
it was impossible for control points to get mixed up while
calculating.
As for the overlapping algorithm, the high-level logic is as follows:
* The distance that the origin has to travel is the length of the scroll
plus the distance from the origin to the object edge.
* The above distance divided by the scroll length gives the relative
scroll lengths that the object has to travel.
* As one relative scroll length takes one time range, the relative
travel length multiplied by the time range gives the absolute travel
time of the object origin.
* Finally, the control point multiplier applicable at origin time is
applied to the whole travel time.
Correctness of the above is demonstrated by visual tests added before
and headless unit tests of the algorithms themselves. The sequential
scroll algorithm was not covered by unit tests, and remains uncovered
due to floating-point inaccuracies that should be addressed separately.
2020-02-07 05:46:31 +08:00
|
|
|
|
}
|
2018-10-30 16:31:43 +08:00
|
|
|
|
|
2018-10-30 17:33:24 +08:00
|
|
|
|
public float GetLength(double startTime, double endTime, double timeRange, float scrollLength)
|
2018-10-30 16:31:43 +08:00
|
|
|
|
{
|
2018-10-30 17:33:24 +08:00
|
|
|
|
var objectLength = relativePositionAtCached(endTime, timeRange) - relativePositionAtCached(startTime, timeRange);
|
2018-10-30 17:00:55 +08:00
|
|
|
|
return (float)(objectLength * scrollLength);
|
2018-10-30 16:31:43 +08:00
|
|
|
|
}
|
|
|
|
|
|
2018-10-30 17:33:24 +08:00
|
|
|
|
public float PositionAt(double time, double currentTime, double timeRange, float scrollLength)
|
2018-10-30 16:31:43 +08:00
|
|
|
|
{
|
|
|
|
|
// Caching is not used here as currentTime is unlikely to have been previously cached
|
2018-10-30 17:33:24 +08:00
|
|
|
|
double timelinePosition = relativePositionAt(currentTime, timeRange);
|
|
|
|
|
return (float)((relativePositionAtCached(time, timeRange) - timelinePosition) * scrollLength);
|
2018-10-30 16:31:43 +08:00
|
|
|
|
}
|
|
|
|
|
|
2018-11-09 18:55:48 +08:00
|
|
|
|
public double TimeAt(float position, double currentTime, double timeRange, float scrollLength)
|
|
|
|
|
{
|
|
|
|
|
// Convert the position to a length relative to time = 0
|
|
|
|
|
double length = position / scrollLength + relativePositionAt(currentTime, timeRange);
|
|
|
|
|
|
|
|
|
|
// We need to consider all timing points until the specified time and not just the currently-active one,
|
|
|
|
|
// since each timing point individually affects the positions of _all_ hitobjects after its start time
|
|
|
|
|
for (int i = 0; i < controlPoints.Count; i++)
|
|
|
|
|
{
|
|
|
|
|
var current = controlPoints[i];
|
|
|
|
|
var next = i < controlPoints.Count - 1 ? controlPoints[i + 1] : null;
|
|
|
|
|
|
|
|
|
|
// Duration of the current control point
|
|
|
|
|
var currentDuration = (next?.StartTime ?? double.PositiveInfinity) - current.StartTime;
|
|
|
|
|
|
|
|
|
|
// Figure out the length of control point
|
|
|
|
|
var currentLength = currentDuration / timeRange * current.Multiplier;
|
|
|
|
|
|
|
|
|
|
if (currentLength > length)
|
|
|
|
|
{
|
|
|
|
|
// The point is within this control point
|
|
|
|
|
return current.StartTime + length * timeRange / current.Multiplier;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
length -= currentLength;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0; // Should never occur
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-30 17:33:24 +08:00
|
|
|
|
private double relativePositionAtCached(double time, double timeRange)
|
2018-10-30 16:31:43 +08:00
|
|
|
|
{
|
|
|
|
|
if (!positionCache.TryGetValue(time, out double existing))
|
2018-10-30 17:33:24 +08:00
|
|
|
|
positionCache[time] = existing = relativePositionAt(time, timeRange);
|
2018-10-30 16:31:43 +08:00
|
|
|
|
return existing;
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-30 17:33:24 +08:00
|
|
|
|
public void Reset() => positionCache.Clear();
|
|
|
|
|
|
2018-04-20 13:16:30 +08:00
|
|
|
|
/// <summary>
|
|
|
|
|
/// Finds the position which corresponds to a point in time.
|
|
|
|
|
/// This is a non-linear operation that depends on all the control points up to and including the one active at the time value.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="time">The time to find the position at.</param>
|
|
|
|
|
/// <param name="timeRange">The amount of time visualised by the scrolling area.</param>
|
|
|
|
|
/// <returns>A positive value indicating the position at <paramref name="time"/>.</returns>
|
2018-10-30 17:33:24 +08:00
|
|
|
|
private double relativePositionAt(double time, double timeRange)
|
2018-04-13 17:19:50 +08:00
|
|
|
|
{
|
2018-06-08 13:49:45 +08:00
|
|
|
|
if (controlPoints.Count == 0)
|
2018-10-30 17:00:55 +08:00
|
|
|
|
return time / timeRange;
|
2018-06-08 13:49:45 +08:00
|
|
|
|
|
2018-04-13 17:19:50 +08:00
|
|
|
|
double length = 0;
|
2018-04-20 13:16:30 +08:00
|
|
|
|
|
|
|
|
|
// We need to consider all timing points until the specified time and not just the currently-active one,
|
|
|
|
|
// since each timing point individually affects the positions of _all_ hitobjects after its start time
|
2018-04-13 17:19:50 +08:00
|
|
|
|
for (int i = 0; i < controlPoints.Count; i++)
|
|
|
|
|
{
|
|
|
|
|
var current = controlPoints[i];
|
|
|
|
|
var next = i < controlPoints.Count - 1 ? controlPoints[i + 1] : null;
|
|
|
|
|
|
2018-04-20 13:16:30 +08:00
|
|
|
|
// We don't need to consider any control points beyond the current time, since it will not yet
|
|
|
|
|
// affect any hitobjects
|
2018-04-13 17:19:50 +08:00
|
|
|
|
if (i > 0 && current.StartTime > time)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
// Duration of the current control point
|
|
|
|
|
var currentDuration = (next?.StartTime ?? double.PositiveInfinity) - current.StartTime;
|
|
|
|
|
|
2018-04-20 13:16:30 +08:00
|
|
|
|
// We want to consider the minimal amount of time that this control point has affected,
|
|
|
|
|
// which may be either its duration, or the amount of time that has passed within it
|
|
|
|
|
var durationInCurrent = Math.Min(currentDuration, time - current.StartTime);
|
|
|
|
|
|
|
|
|
|
// Figure out how much of the time range the duration represents, and adjust it by the speed multiplier
|
2018-10-30 17:00:55 +08:00
|
|
|
|
length += durationInCurrent / timeRange * current.Multiplier;
|
2018-04-13 17:19:50 +08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return length;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|