-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add legacy key counter support #29027
Add legacy key counter support #29027
Conversation
* Make the font match stable style
Gotta say, this is half-baked at best.
As I know people want this, I guess I'll use this as an opportunity to port this properly on top of what's here, but I really expect a better quality of PRs going forward. |
https://osu.ppy.sh/wiki/en/Skinning/Interface#input-overlay And i think I've missed the colour when key down, and the blending mode is not match the stable. |
I dunno what the wiki is claiming with the "24px" figure or why but I'm not playing conversion games either. Dimensions ballparked via screenshots captured at x768 resolution. Also removes a weird homebrew method to keep the text upright. There is one canonical way to do this, namely `UprightAspectMaintainingContainer`. And the other key counters were already using it.
Sigh... I am working on this branch right now. Please do not push further until instructed. I'll probably force-push most of your changes out anyway at this point because this code needs dire improvement anyhow. |
miss clicked the button,sorry |
After the legacy key counter was moved to ruleset-specific component containers, `TestSceneSkinnableHUDOverlay` no longer had a key counter, because it wasn't creating a ruleset-specific HUD component container due to https://github.com/ppy/osu/blob/4983e5f33ed11ba3777e53face6271066ba01ab9/osu.Game/Screens/Play/HUDOverlay.cs#L131-L133 Therefore, to fix, do just enough persuading to make it create one.
@bdach May I ask about the progress of the review? |
I'm not the one to ask. I asked others for review. I'm not reviewing this myself because I changed too much. |
osu.Game/Skinning/LegacySkin.cs
Outdated
@@ -437,6 +388,84 @@ protected override void ParseConfigurationStream(Stream stream) | |||
return null; | |||
} | |||
|
|||
private static DefaultSkinComponentsContainer? createDefaultHUDComponents(SkinComponentsContainerLookup containerLookup) | |||
{ | |||
switch (containerLookup.Ruleset?.ShortName) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So.. this hinges on the fact that there's guaranteed to be a SkinComponentsContainerLookup
request for null
(global) then per ruleset?
I'm sure you did already consider this, but would it be better or worse to put the ruleset version in OsuLegacySkinTransformer
etc.?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to be discussed before. ref
But I'm still have the preferred as put the legacy key per-ruleset.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So.. this hinges on the fact that there's guaranteed to be a
SkinComponentsContainerLookup
request fornull
(global) then per ruleset?
I'm not sure what you mean by "then" here. Both happen. Always. The legacy counter has been moved out of the legacy skin's all-rulesets HUD layer, into its per-ruleset layers where applicable.
As stated in the review conversation linked above, mania and taiko will have to receive their own special stuff anyway in the future, e.g. for combo counter. And I would intend that to be done in this exact same manner.
I'm not sure how a OsuLegacySkinTransformer
-based solution would be - would you be checking if the transformed skin is legacy or something? I think that is worse than this no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll make a diff proposal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
diff is gone
This seems to work well, and follow more closely to the expectations I'd have from the skinning structure (we already have these transformer classes for rulesets modification like this).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had to update the diff, accidentally shared a partial diff, sorry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just committed it, the diff is huge and whatever.
725dc4d Highly recommend hiding whitespace changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just committed it, the diff is huge and whatever.
725dc4d Highly recommend hiding whitespace changes.
Looks good, Yours approach looks similar to the original thought when I was trying to bring the legacy key counter to the default. But my approach is to instantiate the key counter globally, and disable them in taiko/mania, or whatever the ruleset doesn't compact with the legacy key counter. But seems like yours approach looks more clean and readable!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't buy that commit.
Why are legacy skin defaults being handled by skin-agnostic ruleset transformers?
I'm not even gonna comment on the code itself because it's basically illegible to me and breaks my entire mental model of how any of this is supposed to work. Ruleset transformers doing something for null ruleset, then some fallback to base, and then some manual operating on a skin that may or may not contain a legacy counter. How is that better than what I had?
I might just give up touching skinning altogether because everyone seems to be going in a common direction that makes no sense to me. I have no idea what anything is supposed to be. Transformers on transformers, stuff getting handled out-of-band in places three levels away. I don't know what a "ruleset-specific" transformer is supposed to do, nor what a "skin-specific" transformer is supposed to do. They basically seem to arbitrarily perform each other's purposes for what feels like no reason. (Previously.)
I'm also noticing the key overlay to display incorrectly when "beatmap skins" is enabled: CleanShot.2024-08-06.at.08.54.30.mp4Skin: - CK WhiteCat 2.0 _ new (cyperdark).osk.zip Happens on any beatmap as far as I'm aware. |
Looks like this config lookup needs to use Fixed in 90395ae. |
Adds a note about `GetConfig` being stupid.
5f69b74
to
1f6704b
Compare
1f6704b
to
8619bbb
Compare
@normalid-awa please refrain from committing. |
06aee1b
to
8619bbb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems probably okay now
Add the legacy key counter component, just like how the skinnable key counter in stable.
pr.demo.mp4