Change Taiko Classic HD, HR and HDHR to better match stable

[vunyunt]

These values are definitely not a logical match to stable, as they do not match perfectly even visually.

For nomod with very wide aspect ratio, the playfield is trimmed like in classic/stable hidden instead of the notes fading in, to simplify the implementation.

The constants below in TaikoModClassic.cs have abbreviated mod naming to avoid them getting too long, though this doesn't seem to be consistent with the rest of the codebase

        private const float hd_base_fade_out_duration = 0.375f;

        private const float hd_base_initial_alpha = 0.75f;

        private const float hdhr_base_fade_out_duration = 0.2f;

        private const float hdhr_base_initial_alpha = 0.2f;

Comparisons

Due to the amount of combination of mods and resolution, they are uploaded as a zip archive instead of being listed here.

[bdach]

not sure where to even start with this

[bdach]

Why is this setting gone, including the conditional in Update() depending on it? Doesn't this change behaviour of nomod?

[vunyunt]

This was previously set to false in classic to disable aspect range limitations. With these changes playfield aspect range is always limited to some range and never fully unlocked

[bdach]

I believe players wanted the unlock in the first place, which is why I'm not sure where this is coming from.

[vunyunt]

With stable, time range is never fully unlocked:

• With NM, it's limited to a little over 2:1 by fading notes in beyond that
• With HD, it's trimmed to 4:3 by having a black bar block the notes beyond that
• With HR, the playfield "stretches", speeding up notes beyond 16:9, keeping the effective time range to be equal to a maximum of 16:9
• With HDHR, the HR rule applies and playfield isn't trimmed, but notes fades out much earlier

(Note that these are purely from observations, in code they could be implemented differently)

Perhaps we can name this better - time range has been referred to in aspect ratio equivalents in the community, but it might be better to separate the two concepts here, especially with trimOnOverflow set to true, the effective time range and display aspect ratio can be decoupled. The issue with this is we are still expressing time range limits in aspect ratio equivalents in the code here, and I'm not sure if there's a better way to express them without introducing more arbitrary-seeming fractions or decimals

[bdach]

The upper limit used to be 16:9, why has this been increased?

[vunyunt]

This is to match stable with classic mod, stable allows a wider aspect ratio range

[bdach]

How was this upper limit determined though?

I'm asking because I can't find anything like this in stable source.

[chayleaf]

the notes fade in at some point, and while you can't see the fade in with 16:9, you can see it with a higher aspect ratio

[bdach]

I mean sure but that's not evidence of there being a aspect ratio lock on stable, right? That is also consistent with there not being any lock in stable, isn't it? Which we had set already but this PR removes?

As far as I can tell "if you go wider than 16:9 more is shown" means either:

• The upper bound of the lock is above 16:9.
• The upper bound of the lock doesn't exist.

[vunyunt]

I don't have access to stable's code. But I'm guessing for stable, while there isn't an explicit aspect ratio upper bound for the playfield itself, it still effectively limits the time rage to a ~2:1 aspect ratio equivalent by hiding notes beyond that point (fading them in. Without this high sv will lose most of their difficulty since player can in theory stretch the window and have indefinitely long time range.

if you go wider than 16:9 more is shown

For stable nm, it seems to start fading notes in beyond ~2:1. 16:9 doesn't seem to be a cutoff point for stable nm.

With this PR it is done by trimming the playfield instead. This way we can reuse the trim mechanism used by classic HD, while keeping the upper bound of time range.

[bdach]

it still effectively limits the time rage to a ~2:1 aspect ratio equivalent by hiding notes beyond that point (fading them in

Now we're getting somewhere...

I have experimentally confirmed this on a single taiko map. Graphs are here: https://www.desmos.com/calculator/cdmlh4lm3u

But that generally makes me nervous as to whether it's valid to simulate the fadeout limit by clamping aspect ratio in the first place. Clamping ratio is a hard cutoff, it doesn't emulate limited visibility of the objects as they move onto the playfield, so I don't know that this should be done? Maybe the objects should just actually be fading in instead to match stable.

Note that this affects overlapping scroll too / SVs. If the fade-in is solely in the time domain (which it appears to be on stable), then this means that a fast-moving SV-accelerated circle is going to spend more of its active time fading in on screen than a normal circle would.

@ppy/team-client would appreciate thoughts on this spectacle if you can because I'm feeling increasingly out of my depth here in making shot calls as to how this should behave

[vunyunt]

this means that a fast-moving SV-accelerated circle is going to spend more of its active time fading in on screen than a normal circle would

Never really noticed this previously when playing normally, but I can confirm that this is true. When SV on stable nomod is high enough, it will still be fading in even with 16:9 aspect ratio

With this insight it does seem better to actually implement the fade in (trim was used under the assumption that notes take a fixed amount of space to fade in, which has proven to be false)

[vunyunt]

Don't have access to my local branch right now, but fade in has been implemented. I'll be pushing it & posting comparison videos either tonight or some time tomorrow

[bdach]

Why does this have to be configurable / adjusted at all?

[vunyunt]

This is to match stable's scaling, without it the playfield sizing scales differently from stable

[bdach]

"scales differently" is kind of not helpful... I'd like to see, I don't know? Images showing what's not matching?

[bdach]

I'm guessing that you're meaning this here?

That said I'm not sure we strictly need to match this? Like if we did need to match it, we'd probably have to do that everywhere, not only with classic and HR active? Is this a balancing concern?

Like the range of visible objects is the same, everything is proportionally scales so overlap should be the same, I'm not seeing anything abusable here...

[vunyunt]

Personally I don't see a problem with the slight mismatch, I was just trying to match stable as much as possible since that seems to be the goal for classic

As a side note, it also happens to aspect ratio <= 4:3, but the difference there is also minor

[vunyunt]

Added some comments to the reviews, though I won't be able to edit & test the actual code until saturday probably.

As a side note, it's probably likely that this will be reimplemented with stable's logic similar to #26681, especially with all the values being taken completely by visual adjusmtments here

[bdach]

I've looked at stable source and I'm kinda lost as to what's happening in this PR. As far as I can tell, the list of effects of HR and HD on stable is as follows:

• If HR, the slider velocity is increased by a factor of 1.4x. (stable reference)

  We already do this here.

• If (HR && (!HD || !SV2)), the 1.4x increase in slider velocity is additionally increased by a ratio of $playfieldRatio \cdot \frac{3}{4}$. (stable reference)

  We kinda sorta do this as above, but it's hardcoded to work for 16:9 and we forgot to update it.

• If (!SV2 && HD) || (SV2 && HD && !HR), the visible area of the playfield is capped to 640 scaled width (so basically screen height times 4/3). (stable reference)

• If (SV2 && HR), the preempt of objects decreases by 1.4x. No aspect ratio multiplier here. (stable reference)

• If HD and the screen is wide, the taiko-bar-right is "extended" by placing a black version of the sprite to the right where there would be a void from the cut-off. (stable reference)

I'm not sure where many of the numbers added in this PR come from, and I suspect that accounting for the above by messing with the HR multiplier might eliminate a considerable portion of it. But I won't pretend that I understand all the ins and outs of this at all, because stable's mod handling is... "haphazard" would be the word to use here?

[vunyunt]

If HR, the slider velocity is increased by a factor of 1.4x.

This multiplier is not changed with classic. But classic HR now limits the time range to 16:9-equivalent (consistent with stable). If the game window goes wider than that, the sv speeds up to compensate.

If (HR && (!HD || !SV2)), the 1.4x increase in slider velocity is additionally increased by a ratio of

Gameplay wise, (classic SV1) HDHR doesn't scroll faster than plain HR. I believe what is happening here is it is compensating for HD's 4:3 "lock", and allowing the playfield to stretch to the game window.

If (!SV2 && HD) || (SV2 && HD && !HR), the visible area of the playfield is capped to 640 scaled width (so basically screen height times 4/3).

This is done by setting trimOnOverflow to true and limiting aspect ratio to 4:3.

As a side note to the trimOnOverflow variable as it seems to have caused some confusion here, by setting it to true the upper bound of time range will be enforced by trimming the playfield. Otherwise the playfield will scale indefinitely with the game window, but time range will still be limited to MaximumAspect equivalent, resulting in faster-scrolling note when game window is wider than MaximumAspect.

If (SV2 && HR), the preempt of objects decreases by 1.4x. No aspect ratio multiplier here.

All the adjustments are aimed toward classic SV1 (I was told previously that's the goal of the classic mod, and lazer's behavior is supposed to be the evolution of SV2)

If HD and the screen is wide, the taiko-bar-right is "extended" by placing a black version of the sprite to the right where there would be a void from the cut-off

This is done by trimming the playfield here instead of placing a covering black element on the right side

As for the HD initial alpha values, I'd speculate that in classic the playfield is extended beyond the visible range and notes start there. By the time they are in actual visible range they are already semi-transparent. In the current lazer implementation notes are always visible when they start, hence the initial alpha/fade out duration values to compensate.

because stable's mod handling is... "haphazard" would be the word to use here?

This is especially true with SV1. Personally as a player I prefer lazer's (and to some extent, SV2's) scaling. And judging by most tournaments going with SV2 for the most part, it's probably seen as generally more balanced too.

[vunyunt]

I've noticed an issue with barlines appearing before the trimmed playfield. A fix was attempted in 98f8fa2, but it has to be reverted as it seems to mess with barline's SV.

Barlines seems to appear exactly hit_target_width / 2 away from the right side of playfield.

[chayleaf]

wouldn't it be better to increase the playfield size while keeping the 4:3 aspect ratio instead of cutting it off? that would look much nicer (and it's how HD was originally implemented in Lazer)

[bdach]

wouldn't it be better to increase the playfield size while keeping the 4:3 aspect ratio instead of cutting it off?

At this point I'm of the opinion that it should be cut off because if it isn't as broken as doesn't match stable somebody will come here again and complain again that it doesn't match. I'm not interested in anything but exact 1:1 match at this stage because this aspect ratio chicanery has been going on for way too long now.

[vunyunt]

I will try adding a black bar on the right instead of actually trimming the playfield. It should solve the barline issue and will probably remove most/all of the need for custom HD initial alpha/fade out time. I'll try to get this working within the next week

[bdach]

I will try adding a black bar on the right instead of actually trimming the playfield.

Not sure this is required.

[vunyunt]

I will try adding a black bar on the right instead of actually trimming the playfield.

Not sure this is required.

Sorry haven't been checking this for a few days

I'm mainly concerned about the barline issue mentioned above, and it seems to better match the stable logic mentioned here, specifically this point:

If HD and the screen is wide, the taiko-bar-right is "extended" by placing a black version of the sprite to the right where there would be a void from the cut-off. (stable reference)

One question, is osu framework's draw visualizer mentioned in this page accessible in lazer's? I can't seem to access it with a debug build and ctrl + f1 (hoping to use that to rule out clipping issues)

[bdach]

is osu framework's draw visualizer mentioned in this page accessible in lazer?

Yes it should be. If you have parsec installed then exit it, the thing apparently eats ctrl-f1 presses system-wide for whatever reason.

[vunyunt]

Ahh thanks, that worked (didn't have parsec installed but I'm using KDE which had ctrl+f1 as a shortcut, but that's beside the point)

Looking at the visualizer (video attached below), it seems like barline playfield is properly sized, but the barline outside of bound is displayed anyway. Not sure if this (no clipping) is intentional for containers, or if this would be considered a bug in osu framework. Assuming it's not a bug, I'm guessing it's some machinery behind ScrollingPlayfield that causes the barlines to display early, though it would probably take me a while to investigate as I'm not familiar with the inner workings at all

2024-03-02.18-51-04.mp4

[bdach]

Drawables don't clip by default. If you want clip to bounds you need to have masking enabled.

[vunyunt]

Thanks, I'll try looking into it today

[vunyunt]

Barline clipping issue fixed with a88b56a

I've also noticed a gameplay issue where notes with low sv notes would appear too close to the hit area when starting a map with HD, causing them to be unreadable (could be an issue with specific maps only). Though that's out of scope of this PR as it also happens without the classic mod.

2024-03-04.18-47-00.mp4

[bdach]

That video is pretty terrible. I'm not even able to see what I'm supposed to be seeing. As in sure there is a miss but with zero context I have no idea why or what was missed.

Though that's out of scope of this PR as it also happens without the classic mod

If this doesn't happen in stable it needs to be a separate issue at least because that is clearly broken.

[vunyunt]

That video is pretty terrible. I'm not even able to see what I'm supposed to be seeing. As in sure there is a miss but with zero context I have no idea why or what was missed.

Though that's out of scope of this PR as it also happens without the classic mod

If this doesn't happen in stable it needs to be a separate issue at least because that is clearly broken.

Miss is unrelated (autoplay wasn't enabled). To be able to play the first few notes, whenever the map starts it should appear from the right, or at the very least a decent amount of time before it reaches the hidden area where notes completely fade out. Here when the map starts notes are already in the hidden area.

[vunyunt]

If this doesn't happen in stable it needs to be a separate issue at least because that is clearly broken.

Forgot to include it in the previous comment, but it doesn't happen with stable.

[KatK1]

but it doesn't happen with stable.

it technically can happen, but i don't know any maps where this actually becomes an issue in stable
as an example, this map's first note is barely visible with hidden, and making it slower by 0.01x (from 0.1x -> 0.09x) in the editor makes it completely invisible at the start of the map with hidden

[vunyunt]

Ahh, seems like it's an issue with both clients (checked with another low SV map), just more common in lazer due to the generally shorter lead time

[chayleaf]

I agree, memorizing isn't an issue in most cases but Lazer adds RD which makes memorization impossible, it would be nice to get a separate PR that adjusts the map start delay, but that's offtopic for this PR and should probably only be done after any broader HD changes are finalized. There's another HD issue where notes stay invisible after being hit (the after-hit animation of the notes going up should always be visible, unless game UI is hidden), but that's a pretty minor issue, and off topic as well.

[vunyunt]

NM Fade in has been implemented.

Comparisons:

1920x480 with low SV:
https://github.com/ppy/osu/assets/5846322/f8216835-49e6-4d08-a9d1-9c519f10db8a

1920x480 with higher SV:
https://github.com/ppy/osu/assets/5846322/b47e2a5b-21a5-4c8c-84f5-2926cc440c73

1280x720 with very high SV to show the effect being visible at 16:9:
https://github.com/ppy/osu/assets/5846322/5bba27a0-f685-40b8-90cb-5b2851a35857

DrawableHitObject.BeginAbsoluteSequence seems to be able to handle arbitrary start time. I'm going to try implementing classic HD logic by adjusting preempt instead of simulating the behavior with initial alpha and fade duration.

[bdach]

Just as an update - as I said in the catch-up meeting today I'm personally deprioritising looking at this indefinitely as I'm no longer confident that I can progress this change in a way that all parties can agree with. The behaviours this mod brings back are so weird that I would not want to move on this further without backup from someone else from the client team that it's fine to bring them back.

[vunyunt]

I was able to get HD working with preempt time instead of initial alpha, but not without introducing the same arbitrary-seeming adjustment ratio like the current implementation has.

as I said in the catch-up meeting today I'm personally deprioritising looking at this indefinitely

With this, I'll probably pause on updating this for now too, unless the nuances of stable's mod behaviour is determined to be desired in the classic mod.