openboe/oboe
2
0
Fork 0
Code Issues 146 Pull Requests 4 Actions Packages Projects Releases Wiki Activity

font misplaced on title screen #651

New Issue
Closed
opened 2025-02-22 11:20:01 +00:00 by bobbens · 9 comments
bobbens commented 2025-02-22 11:20:01 +00:00 (Migrated from github.com)
Copy Link

Just tried latest master and text seems to be misplaced on the main screen. tested on Arch Linux with wayland. See attached screenshot for reference. In-game stuff seems to be fine, but barely tested.

Furthermore, the menu stuff at the top is tiny, would be nice to have it scale too, but probably worth another issue.

Image

Just tried latest master and text seems to be misplaced on the main screen. tested on Arch Linux with wayland. See attached screenshot for reference. In-game stuff seems to be fine, but barely tested. Furthermore, the menu stuff at the top is tiny, would be nice to have it scale too, but probably worth another issue. ![Image](https://github.com/user-attachments/assets/a126c169-de66-4fec-b9cb-3aa58ad3d58b)
NQNStudios commented 2025-02-22 13:57:13 +00:00 (Migrated from github.com)
Copy Link

Thanks for reporting this! I must have not made the unblurred text offset properly in fullscreen window modes.

Thanks for reporting this! I must have not made the unblurred text offset properly in fullscreen window modes.
NQNStudios commented 2025-02-22 15:44:45 +00:00 (Migrated from github.com)
Copy Link

I found the fix and made a pull request. :)

I found the fix and made a pull request. :)
CelticMinstrel commented 2025-02-22 16:19:17 +00:00 (Migrated from github.com)
Copy Link

Furthermore, the menu stuff at the top is tiny, would be nice to have it scale too, but probably worth another issue.

This is drawn by the operating system, so I don't think we can do much about it. Maybe you can do something in System Preferences? I'm not really sure.

EDIT: Oh, I missed that you're on Linux, not Mac. I couldn't tell the difference from the scaled-down screenshot. In that case, sure, we could probably make the menubar scale on Linux. This makes me wonder what it's like on Windows, too…

> Furthermore, the menu stuff at the top is tiny, would be nice to have it scale too, but probably worth another issue. This is drawn by the operating system, so I don't think we can do much about it. Maybe you can do something in System Preferences? I'm not really sure. EDIT: Oh, I missed that you're on Linux, not Mac. I couldn't tell the difference from the scaled-down screenshot. In that case, sure, we could probably make the menubar scale on Linux. This makes me wonder what it's like on Windows, too…
bobbens commented 2025-02-23 09:06:46 +00:00 (Migrated from github.com)
Copy Link

Furthermore, the menu stuff at the top is tiny, would be nice to have it scale too, but probably worth another issue.

This is drawn by the operating system, so I don't think we can do much about it. Maybe you can do something in System Preferences? I'm not really sure.

EDIT: Oh, I missed that you're on Linux, not Mac. I couldn't tell the difference from the scaled-down screenshot. In that case, sure, we could probably make the menubar scale on Linux. This makes me wonder what it's like on Windows, too…

it's a bit of a mess with wayland now... kde/gtk tend to scale well, other libraries, not so well. Not sure what CBOE is using, but probably have to tell it to scale (or file a bug upstream if necessary).

> > Furthermore, the menu stuff at the top is tiny, would be nice to have it scale too, but probably worth another issue. > > This is drawn by the operating system, so I don't think we can do much about it. Maybe you can do something in System Preferences? I'm not really sure. > > EDIT: Oh, I missed that you're on Linux, not Mac. I couldn't tell the difference from the scaled-down screenshot. In that case, sure, we could probably make the menubar scale on Linux. This makes me wonder what it's like on Windows, too… it's a bit of a mess with wayland now... kde/gtk tend to scale well, other libraries, not so well. Not sure what CBOE is using, but probably have to tell it to scale (or file a bug upstream if necessary).
CelticMinstrel commented 2025-02-23 16:04:11 +00:00 (Migrated from github.com)
Copy Link

it's a bit of a mess with wayland now... kde/gtk tend to scale well, other libraries, not so well. Not sure what CBOE is using, but probably have to tell it to scale (or file a bug upstream if necessary).

I think that's possibly irrelevant? Since the menus on Linux are being drawn with SFML.

> it's a bit of a mess with wayland now... kde/gtk tend to scale well, other libraries, not so well. Not sure what CBOE is using, but probably have to tell it to scale (or file a bug upstream if necessary). I think that's possibly irrelevant? Since the menus on Linux are being drawn with SFML.
bobbens commented 2025-02-23 22:41:08 +00:00 (Migrated from github.com)
Copy Link

it's a bit of a mess with wayland now... kde/gtk tend to scale well, other libraries, not so well. Not sure what CBOE is using, but probably have to tell it to scale (or file a bug upstream if necessary).

I think that's possibly irrelevant? Since the menus on Linux are being drawn with SFML.

So they are fully implemented in SFML? Then support for high DPI would probably have to be added manually.

> > it's a bit of a mess with wayland now... kde/gtk tend to scale well, other libraries, not so well. Not sure what CBOE is using, but probably have to tell it to scale (or file a bug upstream if necessary). > > I think that's possibly irrelevant? Since the menus on Linux are being drawn with SFML. So they are fully implemented in SFML? Then support for high DPI would probably have to be added manually.
CelticMinstrel commented 2025-02-24 00:14:54 +00:00 (Migrated from github.com)
Copy Link

To be specific, they're drawn using TGUI, which is an SFML library that provides graphical widgets.

To be specific, they're drawn using TGUI, which is an SFML library that provides graphical widgets.
bobbens commented 2025-02-24 03:52:14 +00:00 (Migrated from github.com)
Copy Link

To be specific, they're drawn using TGUI, which is an SFML library that provides graphical widgets.

What I found about TGUI: https://tgui.eu/tutorials/latest-stable/dpi-scaling/

TLDR: You'll have to add something like:

// Sets 200% scaling
gui.setRelativeView({0, 0, 0.5f, 0.5f});
tgui::getBackend()->setFontScale(2.0f);

One issue is that SFML 2 does not seem to have any way to actually know the correct scaling factor though...

> To be specific, they're drawn using TGUI, which is an SFML library that provides graphical widgets. What I found about TGUI: https://tgui.eu/tutorials/latest-stable/dpi-scaling/ TLDR: You'll have to add something like: ```cpp // Sets 200% scaling gui.setRelativeView({0, 0, 0.5f, 0.5f}); tgui::getBackend()->setFontScale(2.0f); ``` One issue is that SFML 2 does not seem to have any way to actually know the correct scaling factor though...
CelticMinstrel commented 2025-02-24 04:20:10 +00:00 (Migrated from github.com)
Copy Link

One issue is that SFML 2 does not seem to have any way to actually know the correct scaling factor though...

That doesn't seem to be an issue – since we're allowing the user to choose the scaling factor in preferences, it makes sense to just use the same factor for TGUI.

> One issue is that SFML 2 does not seem to have any way to actually know the correct scaling factor though... That doesn't seem to be an issue – since we're allowing the user to choose the scaling factor in preferences, it makes sense to just use the same factor for TGUI.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
ASR
Specific to the A Small Rebellion scenario
BB
Specific to the Bandit Busywork scenario
bug
charedit
Affects the character editor
core
Affects core systems other than dialogs
dialogxml
Affects the dialog system
duplicate
enhancement
game
Affects the game, as opposed to the editors
important
A high priority task
invalid
linux
Specific to Linux builds
mac
Specific to Mac builds
meta
Related to the build system or other things other than the code
minor
A low priority task
Needs more info
question
replay
Affects the replay system
resources
Specific to the game's assets and resources
scenedit
Affects the scenario editor
Tutorial
Specific to the Tutorial scenario
unconfirmed
VoDT
Specific to the Valley of Dying Things scenario
windows
Specific to Windows builds
wontfix
work
Non coding related task
ZKR
Specific to the Za-Khazi Run scenario
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
CelticMinstrel NQN
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: openboe/oboe#651
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?