Fix song select potentially displaying BPM range with equal min/max values #18345
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The wedge determines whether to display a range or a singular value using
Precision.AlmostEquals(..., 0.001f)
, which isn't correct given that the BPMs are rounded and can be equal in integral form but different in decimals.Therefore the BPMs are rounded first, then casted to integers and compared to each other.
While at it, I've also included a change that avoids cases like 120 BPM formed by
120 - 120.4
turn into 180-181 BPM when DT is enabled, instead of staying singular at 180 BPM.However, that... involved rounding twice to achieve expectations, first rounding the decimal BPM value to integral (e.g.
120.6
->121
), then rounding the rounded BPM with the decimal rate applied to it (e.g.121 * 1.5
->181.5
->182
).Can consider reverting if the rate should be applied to the decimal BPM directly and let cases like the one mentioned above (
120
->180-181
) to remain as-is.