Adjust alpha handling for values exceeding 1 for storyboard sprite transforms to match stable behavior. #35925
Conversation
If alpha exceeds 1 during a sprite's alpha transform like in a FadeTo(), it will set it to 0 mimicking stable's behavior.
|
I hate everything about this. It's the kind of bug I'd hope was fixed before people abused it in weird ways. If this is to stay in place (probably needs to now, as bad as it is), inline commenting needs to be louder, and we will potentially want to kill this off in newer beatmap versions. @rrex971 can you provide a list of storyboards that you're aware of utilising this bug? |
|
It's an extensive amount of maps I'm pretty sure, and it's a common hacky technique that's even being taught in the mentorship classes for storyboarding in fact. From what my partner Raybean tells me (they're part of the World Cup design team) it appears that this is something that's been commonplace for a long time among the storyboarding community. I was skeptical on what approach lazer wanted to take moving forward but it might be best to retain the behavior. I've asked for inputs from a few active storyboarders about this PR, but does that mean this should be converted to a discussion maybe? |
|
Input from storyboarders is not required. All I hope for is a list of example maps (the more the better) to understand scope. |
|
Hello. This "flicker" effect has been used eversince it was discovered and I'd like the bug to stay as a feature. Some storyboards utilize this technique as it allows the object to have a really unique flicker effect that cannot be replicated entirely without this feature. By utilising values that exceed the default maximum (1) you are also able to discover new flickers and on top of that, using different outshoot easings also provide different flickers. This feature has been used in a lot of recent storyboards, a lot of them being osu!original storyboards. Here's a few examples of storyboards that utilise such effect: Some of these storyboards aren't that affected by the change, but some use it as build their other commands around it. I'd love for this "bug" to get reimplemented as it's just really useful all-rounder. |
|
Thanks.
If someone raised this like 10 years ago before it was abused, I would have offered an amicable solution (like a new "flash" transform). But alas. |
|
@bdach I know you're probably not going to like this change, but can I get a quick take on the implementation and whether you think it should be done a different way? I did look at trying to do it as part of the parsing logic and it just seems like a huge pain when this seems to work. |
Obviously it would be yes. For this to be viable to do at parse time you'd have to do root solving of the easing equations to determine when they're overflowing in order to split the transforms into each constituent overflowing part which I'm not even willing to entertain in my head. It's just not going to be as easy as slapping a remainder where it go and calling it a day. Or to put it another way if it's not gonna be done this janky way I'm not even sure I'm willing to review alternatives. |
| } | ||
|
|
||
| [Test] | ||
| public void TestSpriteFadeOverflowBehaviour() |
There was a problem hiding this comment.
we'll see how flaky CI can make this
4 participants
On stable, storyboarders often incorporate 'overshoot' easings (like
InElastic,OutElastic,InOutElasticetc.) with the fade commandFto create a 'flicker' effect. While I'm not sure whether this was intended behavior on stable or not, since it's a common practice among storyboarders (with even the recent OWC 2025 Finals TB Gumbarlzo! utilizing this technique), it'd probably be best to preserve this behavior to maintain the intended visuals for storyboards from stable.Example storyboard command to achieve this effect:
(fade from 0 to 1 with 28 easing (InOutElastic) to achieve the flicker effect when the interpolated values go above 1.)
This PR sets the
Alphavalue to0if it exceeds1. For a visual on what exactly it changes: