Skip to content

Conversation

@DanielPower
Copy link
Contributor

@DanielPower DanielPower commented Dec 16, 2024

Resolves #6150
Related to ppy/osu#12098
Required by ppy/osu#31141

Description

Exposes new bindables OutputAreaSize and OutputAreaOffset, so that absoluteOutputMode.Output can be updated from osu.Game.

Includes new testing sliders for output area and rotation. Updated input area visualization to show rotation, and added a new visualization for output area.
Screenshot 2025-06-20 at 12 46 51 AM

@DanielPower DanielPower changed the title Initial proof of concept for tablet output scaling Allow modifying Tablet Output Area Dec 16, 2024
@DanielPower DanielPower changed the title Allow modifying Tablet Output Area Expose tablet OutputSize Dec 16, 2024

public Bindable<Vector2> AreaSize { get; } = new Bindable<Vector2>();

public Bindable<Vector2> OutputSize { get; } = new Bindable<Vector2>();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sold on this API design. I'd say this should be nullable, and if the output size is null, then it is presumed that the output area is the whole window (which would fall back to the old logic). Curious of other thoughts on this though @ppy/team-client

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OutputAreaSize now has a default value of Vector2(1f, 1f). So it behaves correctly on first launch.
OutputAreaPosition does not have a default value, but it's unused until the scaling mode is changed, at which point it will have been populated. I could give it a default of Vector2(0.5f, 0.5f) if that would be preferable.

I'm also open to making them nullable if that would be better.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at things in their current state, I think I'm fine with the proposed API? Better than nullable values IMHO.

@hwsmm
Copy link
Contributor

hwsmm commented Dec 16, 2024

Seems like a duplicate of #6166?

@DanielPower
Copy link
Contributor Author

DanielPower commented Dec 16, 2024

Seems like a duplicate of #6166?

That's a good catch. I can close this and instead use #6166 as a base for ppy/osu#31141 if that would be preferable. Their PR is more complete as it also includes the output position, which may be useful for future configurability.

…een-scaling-tablet-output

# Conflicts:
#	osu.Framework/Input/Handlers/Tablet/ITabletHandler.cs
#	osu.Framework/Input/Handlers/Tablet/OpenTabletDriverHandler.cs
@pull-request-size pull-request-size bot added size/M and removed size/S labels Dec 17, 2024
…een-scaling-tablet-output

# Conflicts:
#	osu.Framework/Input/Handlers/Tablet/ITabletHandler.cs
#	osu.Framework/Input/Handlers/Tablet/OpenTabletDriverHandler.cs
… screen-scaling-tablet-output

# Conflicts:
#	osu.Framework/Input/Handlers/Tablet/ITabletHandler.cs
@DanielPower
Copy link
Contributor Author

#6166 is too outdated to work off of directly due to conflicts with osu.Game. So I've:

  1. merged @Feodor0090's changes into this branch
  2. updated Scale tablet output size when UI Scaling mode is "Everything" osu#31141 accordingly
  3. Updated some wording and simplified logic

Apologies, this has made the commit history a little messy. I can rebase if desired, but I'll leave it as-is for now since CONTRIBUTING.md discourages rebasing.

@DanielPower DanielPower marked this pull request as ready for review December 17, 2024 01:06
@DanielPower DanielPower requested a review from bdach December 17, 2024 01:09
@DanielPower DanielPower marked this pull request as draft December 17, 2024 01:11
@DanielPower DanielPower marked this pull request as ready for review December 17, 2024 01:23
@DanielPower DanielPower marked this pull request as draft December 31, 2024 01:41
y => tabletHandler.OutputAreaOffset.Value = new Vector2(
tabletHandler.OutputAreaOffset.Value.X, y));

AddSliderStep("change rotation", 0, 360, 0f,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is out of scope, but I needed to test that my changes wouldn't break with rotation. I could break this into a separate PR if you'd like, but I figure it's a simple enough addition to include here.

@DanielPower
Copy link
Contributor Author

DanielPower commented Jun 18, 2025

Sorry it's taken so long to get back to this. It's much later than the "Shortly after New Years" that I promised 😅

Changes since the last review include:

  • Added testing sliders for output area size, output area offset, and rotation.
  • Addressed positioning bugs from the previous implementation.
  • Removed the unnecessary call to updateOutputArea.
  • Added default values for OutputAreaSize and OutputAreaOffset.
  • Merged in the latest master branch, since there were conflicts.

On the note of the default values, I found that when restarting the test framework, if there are no sliders for the values, the last used values will be used instead of the default values. I'm assuming there's a config file somewhere storing these values that I should be clearing when testing. I'm currently trying to figure out where that is, so I can validate that the default values will work correctly on a fresh or existing installation.

One thing this PR hasn't changed is the tablet area visualization. Output area and rotation are not reflected in the visualization.

Edit: I've now included a tablet area visualization for output area.

@DanielPower DanielPower requested review from bdach and peppy June 18, 2025 23:43
@DanielPower DanielPower marked this pull request as ready for review June 18, 2025 23:43
@DanielPower
Copy link
Contributor Author

DanielPower commented Jun 19, 2025

As a bit of a tangent, I implemented OutputAreaOffset so that the output area remains within the bounds of the screen. (0, 0) is aligned to the top-left, and (1, 1) is aligned to the bottom-right. This is different from the existing input area implementation, where you position the center of the area directly, allowing the input area to be partially outside the tablet.

Screenshot 2025-06-18 at 9 39 01 PM

I think it would make sense to adjust the input area to fix this behaviour. But it would cause differences for anyone who has changed their offset unless we could migrate saved config values. It's outside the scope of this PR, but figured I'd mention it.

@pull-request-size pull-request-size bot added size/L and removed size/M labels Jun 20, 2025
tabletInfo = new SpriteText(),
areaVisualizer = new TabletAreaVisualiser(),
inputAreaVisualizer = new TabletAreaVisualiser(Vector2.One, "Input area", false),
outputAreaVisualizer = new TabletAreaVisualiser(new Vector2(256, 144), "Output area", true),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

256x144 is just an arbitrary 16:9 scale size for visualization purposes.

}, true);
AreaSize.DefaultChanged += fullSize => fullArea.Size = fullSize.NewValue;
fullArea.Size = AreaSize.Default;
AreaSize.DefaultChanged += _ => updateVisualiser();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When the area is confined, position depends on size. Moving all calculations to a single function was simpler.

@DanielPower
Copy link
Contributor Author

@peppy This PR is ready for review.
The related PR ppy/osu#31141 is also ready for review, but I've left it in draft for now since it depends on the framework changes from this PR.

If there's anything further I can do in terms of documentation, testing, etc. that would help this get merged, please let me know.

peppy
peppy previously approved these changes Aug 22, 2025
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.

API seems probably fine now?

@peppy
Copy link
Member

peppy commented Aug 22, 2025

@bdach can you give this 5 minutes to check you're okay with it now?

Copy link
Collaborator

@bdach bdach left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems fine, probably squash this

@peppy peppy self-requested a review August 22, 2025 07:07
@peppy peppy merged commit 3fe1760 into ppy:master Aug 22, 2025
14 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.

Tablet input should have a property to allow adjusting the mapping target area

5 participants