Rewrite osu!taiko's time range computation logic to match 1:1 with stable #26781
Conversation
frenzibyte
added
ruleset/osu!taiko
area:gameplay
next release
| if (LockPlayfieldAspectRange.Value) | ||
| currentAspect = Math.Clamp(currentAspect, MINIMUM_ASPECT, MAXIMUM_ASPECT); | ||
|
|
||
| // in a game resolution of 1024x768, stable's scrolling system consists of objects being placed 600px (widthScaled - 40) away from their hit location. |
There was a problem hiding this comment.
stable's scrolling system consists of objects being placed 600px (widthScaled - 40) away from their hit location
no reference for this (where's the 600px figure in stable?)
There was a problem hiding this comment.
This is connected with the rest of the comment block about the "in length" value, in that it is all sourced from this line in stable code.
In a game resolution of 1024x768, the "scaled" resolution is 640x480 because of the aspect ratio of the game resolution. So "width scaled" is 640px, subtracting 40 from it leads to the final value of 600px, which is the scrolling distance of the object in a 640x480 space (since it's assigned to the inLength variable, see scroll code.
| currentAspect = Math.Clamp(currentAspect, MINIMUM_ASPECT, MAXIMUM_ASPECT); | ||
|
|
||
| // in a game resolution of 1024x768, stable's scrolling system consists of objects being placed 600px (widthScaled - 40) away from their hit location. | ||
| // however, the point at which the object renders at the end of the screen is exactly x=640, but stable makes the object start moving from beyond the screen instead of the boundary point. |
There was a problem hiding this comment.
the point at which the object renders at the end of the screen is exactly x=640, but stable makes the object start moving from beyond the screen instead of the boundary point
no reference for this
There was a problem hiding this comment.
The comment needs to be reworded but what I was trying to convey is that stable starts scrolling the object from X = hit target + inLength, instead of X = end of screen. See scroll code and notice the X values of the transformations.
|
|
||
| // in a game resolution of 1024x768, stable's scrolling system consists of objects being placed 600px (widthScaled - 40) away from their hit location. | ||
| // however, the point at which the object renders at the end of the screen is exactly x=640, but stable makes the object start moving from beyond the screen instead of the boundary point. | ||
| // therefore, in lazer we have to adjust the "in length" so that it's in a 640px->160px fashion before passing it down as a "time range". |
There was a problem hiding this comment.
what does this mean? what is "a 640px->160px fashion"?
There was a problem hiding this comment.
As in, the inMsLength property in stable currently gives the time spent by the object moving from 760px to 160px (760px is determined by stable_hit_location + inLength, when game resolution is 1024x768).
This is bad for lazer, because 640px in stable is considered the right edge of the playfield, i.e. stable begins scrolling the object from outside of the playfield, while lazer begins scrolling the object from the right edge of the playfield instead (technically scrolls from the right edge of the HitObjectContainer).
So to compromise this, the inLength is changed to be calculated by widthScaled - stable_hit_location (distance between right edge of playfield and hit location) instead of widthScaled - 40 (stable's distance, 600px)
| float widthScaled = currentAspect * stable_gamefield_height; | ||
| float inLength = widthScaled - stable_hit_location; | ||
|
|
||
| // also in a game resolution of 1024x768, stable makes hit objects scroll from 760px->160px at a duration of 6000ms, divided by slider velocity (i.e. at a rate of 0.1px/ms) |
There was a problem hiding this comment.
where does 760px come from here?
|
For classic mod and it's combination with other mods, would it be also preferable to defer the implementation to someone with access to stable's code? |
|
@vunyunt to keep things moving forward I'd still suggest you PR what you have. |
|
Alright, I haven't started on it yet but I can try to port #19604 over, though do keep in mind it is definitely not a logical match with stable, especially with (Classic)HDHR not fully matching even visually |
After cross-comparing against stable, I've found out that the logic in the PR above could be rewritten completely to be based on stable code rather than a linear approximation given by visual comparison (especially when dealing with different aspect ratios).
I have spent some time to get an understanding of how the logic works, so I wrote explanatory comments across the logic in hope that it speeds up the understanding process and keeps the code as close and matching with stable as possible.
The beatmap/difficulty above is https://osu.ppy.sh/beatmapsets/847323#taiko/1774604. It uses a base slider velocity of 1.4x. For extra testing, I've changed the slider velocity to 2x and made another comparison: