Storing `DrawableHitObject` for later use is not safe – especially
when accessing `HitObject` – as it's a pooled class. In the case here,
it's important to note that `PrepareForUse` can be called a frame or
more later in execution, which made this unsafe.
Closes https://github.com/ppy/osu/issues/24444.
Regressed in https://github.com/ppy/osu/pull/25216.
The new logic will ensure at least one tick is ready for judgement.
There shouldn't be a case where more than one is needed in a single
frame.
Checking the delta after the application of rate is not correct. The
delta is in screen-space *before* the rate from rate-changing mods were
applied; the point of the application of the rate is to compensate for
the fact that the spinner is still judged in "track time" - but the goal
is to keep the spinner's difficulty *independent* of rate, which means
that with DT active the user's spin is "twice as effective" to
compensate for the fact that the spinner is twice as short in real time.
In another formulation, with DT active, the user gets to record replay
frames "half as often" as in normal gameplay.
stable's `pSpriteText` has a `TextConstantSpacing` flag, that is
selectively enabled for some usages. In particular, these are:
- mania combo counter (not yet implemented)
- taiko combo counter (not yet implemented)
- score counter
- accuracy counter
- scoreboard entries (not yet implemented)
Everything else uses non-fixed-width fonts.
Hilariously, `LegacySpinner` _tried_ to account for this by changing
`Font` to have `fixedWidth: false` specified, only to fail to notice
that `LegacySpriteText` changes `Font` in its BDL, making the property
set do precisely nothing. For this reason, attempting to set `Font`
on a `LegacySpriteText` will now throw.
Noticed this during work on https://github.com/ppy/osu/pull/25185.
In some circumstances, it seemed that spinner bonus ticks (and mostly
them specifically) would not always play with the correct volume.
Hours of debugging later pointed at a trace at
`DrawableAudioWrapper.refreshLayoutFromParent()` not firing sometimes.
Initially I thought it to be some sort of framework bug, but after
preparing a diff and running final checks, I noticed that sometimes
the sample was being played *by a `PoolableSkinnableSample` that wasn't
loaded*. And determining why *that* is the case turned out with this
diff.
As it happens, spinner ticks get assigned a start time proportionally,
i.e. the 1st of 10 ticks is placed at 10% of the duration, the 2nd
at 20%, and so on. The start time generally shouldn't matter,
because the spinner is manually judging the ticks. *However*, the ticks
*still* receive a lifetime start / end in the same way normal objects
do, which means that in some cases they can *not be alive* when they're
hit, which means that the `DrawableAudioWrapper` flow *hasn't had
a chance to run*, and rightly so.
To fix, ensure that all spinner ticks are alive throughout the entirety
of the spinner's duration.
In preparation to remove `DistancedHitObjectComposer`, split off
`IPositionSnapProvider` from `IDistanceSnapProvider`.
`DistancedHitObjectComposer` was not touching `IPositionSnapProvider`'s
only interface member at all, it was just forwarding it for subclasses
to override to their own leisure.
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.
- `default-N` number sprites maximum size increased by 1.25x to a total
of 320x320 to counteract the 0.8x factor applied onto them when
displayed on a hitcircle.
- `sliderb` and parts' maximum size increased to 384x384, to match
`sliderfollowcircle`, as the two are apparently sometimes used
interchangeably by skinners to achieve different visual effects.
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.
