Skip to content

Conversation

Endaris
Copy link
Collaborator

@Endaris Endaris commented May 28, 2025

Work-in-Progress branch for overhauling our UI (again)

Goal

Move away from the 16:9 static global canvas and make it so that scenes and UI can be designed in a way that looks okay on mobile without compromising much on design for desktop.

Changes

Font handling

Font sizes used to be handled in numeric sizes and the way the size was set was inconsistent across the repository.

The new font handling has a range of string keys that refer to specific base sizes so that different text can be sized relatively to each other using those keys but without requiring explicit numbers.
Instead the GraphicsUtil font functions now access an extra parameter fontSizeDelta that is added to the standard font size for each key before fetching the font.
This has the advantage that

  1. Theme/Language fonts using off-standard sizes no longer suffer from divergent relative sizing when bigger/smaller fonts than the standard were sometimes addressed in absolute pt sizes.
  2. Font sizes can easily be increased on mobile without bringing the handling into the Label element.

FlexBox Layout

This is mostly described within the PR in the updated Understanding the Codebase.md doc so read there instead.

New Battle Room UI

This is under construction.
The idea is to move to a vertical layout that makes use of scrollable and wrappable elements to provide much more screen real estate to implement more sophisticated UI options going forward, in many cases UI options that cannot be properly fit into the current battle room UI.

TODO

  • Repair resolution-aware use of dpi scale for assets
  • Maybe rethink how player cursor focus is done on UIElements that are navigable by more than one player
  • Extract directly window related tasks into its own component

Endaris added 25 commits May 10, 2025 21:52
fix an issue where the top level children would not grow in the direction of the layout orientation
…n and automatically wraps for the given width
fix childGaps not being subtracted when calculating remaining width to distribute
fix annotations for ui/init.lua
…if the window is squeezed too small instead of the preferred width
Copy link
Contributor

@JamesVanBoxtel JamesVanBoxtel left a comment

Choose a reason for hiding this comment

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

What is your plan for brining back the black letter boxing border on desktop?

Maybe we add the navigation stack to a sub view that is centered and have the black background on the root view? Then eventually all these calls to canvas width can instead get the size of the appropriate parent element or use the new fill alignment layout stuff.

About half way done looking through code, still need to test.

end

function Game:handleResize(newWidth, newHeight)
local activeScene = GAME.navigationStack:getActiveScene()
Copy link
Contributor

Choose a reason for hiding this comment

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

There should probably be a root element that all scenes are parented from, that way we can draw overlays on it etc and it is always the root spot to update scale / height / width on.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yep!
This is still WIP and I did this quick and dirty to get a layout resize for window resizes so I could test the layout at all. I intend to come back to this.

@Endaris
Copy link
Collaborator Author

Endaris commented May 28, 2025

What is your plan for bringing back the black letter boxing border on desktop?

Maybe we add the navigation stack to a sub view that is centered and have the black background on the root view? Then eventually all these calls to canvas width can instead get the size of the appropriate parent element or use the new fill alignment layout stuff.

Letterboxing specifically exists to fill remaining space when the window size doesn't match the desired aspect ratio but with the new layout strategy it could technically just adapt to that size as we no longer have a specific desired aspect ratio.
Game:draw already clears the background to black so with some luck, some kind of "letterboxing" will naturally emerge where the background image does not reach.
I believe it will be easier to evaluate this once we have working prototypes for most scenes so it's easier to see how our scenes pan out and where/how letterboxing would be most desirable.

self.scale = math.min(self.width / self.imageWidth, self.height / self.imageHeight)
self.width = self.imageWidth * self.scale
self.height = self.imageHeight * self.scale
-- self.width = self.imageWidth * self.scale
Copy link
Contributor

Choose a reason for hiding this comment

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

Delete?

local go = ui.MenuItem.createButtonMenuItem("go_", nil, nil, function() self:goToCharacterSelect(garbagePatternStepper.value, widthSlider.value, heightSlider.value) end)
local back = ui.MenuItem.createButtonMenuItem("back", nil, nil, exitMenu)

self.menu = ui.VerticalMenu({
Copy link
Contributor

Choose a reason for hiding this comment

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

I still think we should have a constructor here that does "the right thing" for main menu menus so we can adjust in one spot.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I guess, to be fair this is really placeholderish.
Looking at my current idea I want to support in-room game mode adjustments so this particular one will most likely be embedded later but I get what you mean in general.
I'll keep that in mind for when I try to establish the general outline for the "split screen" idea.

Endaris added 8 commits June 10, 2025 17:25
apply some of Jam's feedback in comments / var renames
4-slice the image cursor and draw it with maintained aspect ratio
explicitly use cursors for Options/SoundTest
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants