Skip to content
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

Merged
merged 29 commits into from
Aug 7, 2024

Conversation

normalid-awa
Copy link
Contributor

@normalid-awa normalid-awa commented Jul 23, 2024

Add the legacy key counter component, just like how the skinnable key counter in stable.

pr.demo.mp4

@bdach
Copy link
Collaborator

bdach commented Jul 24, 2024

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.

@normalid-awa
Copy link
Contributor Author

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
Is said that the input overlay is only available in std and catch, so it is good to just not display them in the other mode.

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.
@bdach
Copy link
Collaborator

bdach commented Jul 24, 2024

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.

@normalid-awa
Copy link
Contributor Author

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.
@Doxxz
Copy link

Doxxz commented Jul 24, 2024

Since it's possible to have 4 keybinds in osu, could this overlay show these four keys, similar to how it was in stable?
Captura de tela 2024-07-24 135109

@normalid-awa
Copy link
Contributor Author

Since it's possible to have 4 keybinds in osu, could this overlay show these four keys, similar to how it was in stable?
Captura de tela 2024-07-24 135109

Imo, Both bind are considered as one input (ie "z","m1" are both registered as left button"). implementing this will require a lot more changes to the base code, and would affect existing key counter.

@normalid-awa
Copy link
Contributor Author

I am done with this branch.

@normalid-awa please read through my changes and take note for the future. If anything is uncertain please ask.

@ppy/team-client requesting a review since I basically rewrote most of this. Stable code for your perusal at https://github.com/peppy/osu-stable-reference/blob/bb57924c1552adbed11ee3d96cdcde47cf96f2b6/osu!/Input/Drawable/InputOverlay.cs.

I only matched the things that were obvious/simple to match (colours, transitions), and left well alone things that were not (I don't even know where to even begin with the stable method of specifying sizings; also stable would always add four switches and just fade out the ones that aren't used to 50% opacity; I decided I'd rather not bother with this as it's not super trivial to support this, but can if there is insistence on it).

Oh, and c3dae81 probably deserves particular scrutiny because it is unprecedented.

@bdach May I ask about the progress of the review?

@bdach
Copy link
Collaborator

bdach commented Aug 6, 2024

I'm not the one to ask. I asked others for review. I'm not reviewing this myself because I changed too much.

@peppy peppy self-requested a review August 6, 2024 05:05
@@ -437,6 +388,84 @@ protected override void ParseConfigurationStream(Stream stream)
return null;
}

private static DefaultSkinComponentsContainer? createDefaultHUDComponents(SkinComponentsContainerLookup containerLookup)
{
switch (containerLookup.Ruleset?.ShortName)
Copy link
Member

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.?

Copy link
Contributor Author

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.

Copy link
Collaborator

@bdach bdach Aug 6, 2024

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 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?

Copy link
Member

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.

Copy link
Member

@peppy peppy Aug 6, 2024

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).

Copy link
Member

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.

Copy link
Member

@peppy peppy Aug 6, 2024

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.

Copy link
Contributor Author

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!

Copy link
Collaborator

@bdach bdach Aug 6, 2024

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.)

osu.Game/Skinning/LegacyKeyCounterDisplay.cs Show resolved Hide resolved
@frenzibyte
Copy link
Member

I'm also noticing the key overlay to display incorrectly when "beatmap skins" is enabled:

CleanShot.2024-08-06.at.08.54.30.mp4

Skin: - CK WhiteCat 2.0 _ new (cyperdark).osk.zip

Happens on any beatmap as far as I'm aware.

@peppy
Copy link
Member

peppy commented Aug 6, 2024

I'm also noticing the key overlay to display incorrectly when "beatmap skins" is enabled

Looks like this config lookup needs to use getCustomColour instead of legacySettingLookup. I'll take a quick look at fixing this too.

Fixed in 90395ae.

@peppy peppy force-pushed the feature/skin/legacy-input-overlay branch from 5f69b74 to 1f6704b Compare August 6, 2024 07:09
@peppy peppy force-pushed the feature/skin/legacy-input-overlay branch from 1f6704b to 8619bbb Compare August 6, 2024 07:12
@peppy
Copy link
Member

peppy commented Aug 6, 2024

@normalid-awa please refrain from committing.

@peppy peppy force-pushed the feature/skin/legacy-input-overlay branch from 06aee1b to 8619bbb Compare August 6, 2024 08:29
@pull-request-size pull-request-size bot added size/XL and removed size/L labels Aug 6, 2024
Copy link
Member

@peppy peppy left a 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

@peppy peppy requested a review from bdach August 6, 2024 13:10
@peppy peppy merged commit b1488fd into ppy:master Aug 7, 2024
9 of 13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants