spaceship/tests/test_hud_scales_to_screen.gd
Claude f1292db40a #228: shrink the HUD on a screen the canvas is short on
The layout is authored in CANVAS units. With stretch "canvas_items" and
aspect "expand" over a 1920x1080 base, a 720x1280 phone scales by 0.375 and
gets 1920x3413 canvas units - while ANY 16:9-or-wider screen lands on
1920x1080 units however many pixels it really has. The canvas is three times
shorter, so a 148-unit button went from 4.3% of the screen's height to
13.7%. Measured at 3.16x, and confirmed twice: once by hand off the scene
file, once by the test failing with the rule disabled.

Nothing collided. That was checked pair by pair on both canvases and the
same six pairs overlap on each, all of them same-slot alternatives. The
fault was only that everything was enormous.

HudScale captures each HUD control's authored offsets once, then moves it
toward the edge it hangs off and scales the NODE. Scaling the rect alone was
tried first and was wrong: half the HUD draws its own contents at fixed
sizes - ResourceReadout lays its rows out in code, Labels carry their own
font size - so shrunken boxes kept full-size content and the build button
slid up underneath the resource list. Scaling the node takes content and
children with it.

The cost is that position (parent space) and size (local space) now differ
by that scale, and a lot of code here assumed they did not. Five places:

  ResourceReadout.content_bottom() added a scaled position to an unscaled
  height, overstating itself by more than a button - so _seat_hud_columns
  pushed the whole column down to clear space nothing occupied. A live bug,
  not just a bad measurement.
  HUD_COLUMN_MARGIN would have been the one gap still phone-sized.
  _layout_context_buttons wrote its stride and pitch unscaled, landing the
  action row on the building-action row - which is the second of the two
  regressions test_hud_layout was written for, in a new disguise.
  test_hud_layout and test_hangar_management compared authored rects.

And HudScale reapplies on resize, which wiped the two layouts BuildController
writes at runtime - so dragging a desktop window left the context row where
it was. Both re-run on size_changed now, deferred, because which of two
siblings connected first is not a thing to depend on.

test_hud_layout ran at one window shape, which happened to be the desktop
canvas. It now runs every check at both, so this cannot hide at whichever
shape was not being exercised.

Rejected: scaling the UI CanvasLayer does not work at all - Control anchors
resolve against the viewport rect, so bottom-anchored elements land
mid-screen. A single scaled wrapper Control with the HUD reparented under it
is the genuinely clean shape and would need no scale-aware arithmetic
anywhere, but it changes every node path and would break every get_node in
the controllers and tests.

MIN_SCALE floors the shrink at 0.45 rather than the proportional 0.316: a
landscape phone gets the same short canvas as a desktop, and there the
sticks are still thumb targets. That leaves the HUD at 1.42x its phone share
on a PC rather than 1.0x.

177/177 at JOBS=3.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019AJMdB7iuHuLFZM1aBu3GD
2026-09-12 18:04:00 +02:00

118 lines
4.4 KiB
GDScript

extends SceneTree
# Forgejo #228: the HUD must not be three times larger on a PC than on a
# phone.
#
# The layout is authored in CANVAS units. With stretch "canvas_items" and
# aspect "expand" over a 1920x1080 base, a 720x1280 phone scales by 0.375 and
# gets 1920x3413 canvas units, while ANY 16:9-or-wider screen lands on
# 1920x1080 units however many pixels it really has. The canvas is three
# times shorter, so an unscaled 148-unit button goes from 4.3% of the
# screen's height to 13.7% of it.
#
# Nothing collides - that was checked pair by pair on both canvases and the
# same six pairs overlap on each, all of them same-slot alternatives. The
# fault is purely that everything is enormous.
#
# Covers:
# A. on a phone the HUD is left exactly as authored
# B. on a desktop canvas a control takes a similar FRACTION of the screen
# rather than three times more
# C. the shrink is bounded, so a landscape phone keeps thumb-sized targets
# D. it follows a resize rather than only applying once at startup
const PHONE: Vector2i = Vector2i(720, 1280)
const DESKTOP: Vector2i = Vector2i(1920, 1080)
const BIG_DESKTOP: Vector2i = Vector2i(2560, 1440)
var scene: Node
var hud: Node
var button: Control
var frames: int = 0
var stage: int = 0
var phone_fraction: float = 0.0
func _initialize() -> void:
var gs: Node = root.get_node("GameState")
gs.buildings.clear()
gs.reset_new_game()
gs.intro_active = false
scene = load("res://world/Main.tscn").instantiate()
root.add_child(scene)
current_scene = scene
hud = scene.get_node("UI/HudScale")
button = scene.get_node("UI/MapButton")
func _fraction() -> float:
# Height of a HUD control as a share of the screen's height - the number
# that actually differs between the two, and the one a player sees.
# Rendered height, not the layout rect: the rect keeps its authored size
# and the node is scaled, so scale is where the shrink actually lives.
return (button.size.y * button.scale.y) / button.get_viewport_rect().size.y
func _process(_delta: float) -> bool:
frames += 1
if frames < 10:
return false
frames = 0
match stage:
0:
root.size = PHONE
stage = 1
return false
1:
# --- A. authored size on the shape it was authored for -------
var k: float = hud.hud_scale()
if not is_equal_approx(k, 1.0):
return _fail("the phone HUD is being scaled by %.3f, but it is the authored shape" % k)
phone_fraction = _fraction()
print("phone %s: canvas %.0f tall, scale %.2f, control is %.1f%% of the screen" % [
PHONE, button.get_viewport_rect().size.y, k, phone_fraction * 100.0])
root.size = DESKTOP
stage = 2
return false
2:
# --- B. a similar share of a desktop screen ------------------
var pc_fraction: float = _fraction()
var ratio: float = pc_fraction / maxf(phone_fraction, 0.0001)
print("desktop %s: canvas %.0f tall, scale %.2f, control is %.1f%% of the screen (%.2fx the phone)" % [
DESKTOP, button.get_viewport_rect().size.y, hud.hud_scale(),
pc_fraction * 100.0, ratio])
if ratio > 1.75:
return _fail("a HUD control is %.2fx its phone share on a desktop screen - that is the bug" % ratio)
# --- C. and not shrunk into uselessness ----------------------
if hud.hud_scale() < 0.4:
return _fail("the HUD shrank to %.2f, past anything pressable" % hud.hud_scale())
root.size = BIG_DESKTOP
stage = 3
return false
3:
# --- D. follows the resize -----------------------------------
var big: float = _fraction()
print("big desktop %s: control is %.1f%% of the screen" % [BIG_DESKTOP, big * 100.0])
if absf(big - phone_fraction) / maxf(phone_fraction, 0.0001) > 0.75:
return _fail("a bigger desktop screen did not keep the control proportional (%.1f%% vs %.1f%%)" \
% [big * 100.0, phone_fraction * 100.0])
# Back to the phone: the HUD must return, not stay shrunk.
root.size = PHONE
stage = 4
return false
4:
if not is_equal_approx(hud.hud_scale(), 1.0):
return _fail("returning to the phone shape left the HUD at %.3f" % hud.hud_scale())
if absf(_fraction() - phone_fraction) > 0.001:
return _fail("the HUD did not come back to its authored size on resize")
print("resizing back to the phone restored the authored size")
print("TEST_HUD_SCALES_TO_SCREEN: PASS")
quit(0)
return true
return false
func _fail(message: String) -> bool:
print("TEST_HUD_SCALES_TO_SCREEN: FAIL (%s)" % message)
quit(1)
return true