This multiplier has to exist.
I'm not guaranteeing that the rest is correct here. Should we be doing
proper cross-testing on this? Maybe, but it's going to be hard to get
right. We could likely check as far as "game pixels", but there's still
a chance that the osu-framework could be doing something weird in the
rest of the hierarchy where playfield scale is involved.
Closes https://github.com/ppy/osu/issues/25162. Tested to fix the linked
replay.
They had scale transforms applied to them in two places: the actual
legacy pieces themselves (esp. `LegacyHitCirclePiece`), and on the
`DrawableSliderRepeat` level.
This change moves all of the scale transforms to the skinnable pieces.
Argon and triangles have received a copy of the previous logic each,
so behaviour on those skins should not change.
It turns out multiple components depend on `Tracking` eventually
becoming `false` at the end of a slider. With my previous changes, this
was no longer the case (as could be seen by the legacy cursor particles
test failure, and heard by slider slide taking too long to stop).
Fixes half of https://github.com/ppy/osu/issues/24956.
The other half is high effort. The number portion is nested deeply and
with reason - depending on skin setting it changes the visual order.
I'm not sure how to fix that one, but I also think it's weird behaviour
and if people don't complain, it's probably fine to just dim the number
for consistency.
That said, the approach circle is an important one to ensure it matches
1:1, so I've fixed that here.
This reverts commit 03c61a573ec9f8f1e83cd98193fd84bd18a75043.
The goal here was to handle an edge case discovered during work on note
lock, wherein it was determined that on stable hit circles would block
input from reaching objects underneath them. However, the change
mentioned above did that _too_ hard and caused overlaps to also be
blocked even long past a hit circle has been faded out.
Revert the change pending further (and more careful) investigation.
This is another similar case where stable floating point precision comes
into play due to use of `hitObjectManager.Beatmap.BpmMultiplierAt` (see
1531237b63/osu!/GameplayElements/HitObjects/Osu/SliderOsu.cs#L680)
Closes#24708.
