Repository navigation
Conversation
… is shown on The host answered 4K for every docked game, whatever the screen. A docked Switch 2 answers with what its TV takes, and a game sizes its rendering from that answer. On a 1080p display, Fire Emblem Fortune's Weave rendered for a larger output than the screen shows, and the host then scaled that output down. hle_vi.c now answers as a Switch 2 does. In handheld mode it gives the 1080p screen. Docked, it gives the largest of 720p, 1080p, 1440p and 4K that the display holds. The front end reports the display's size through front_display_pixels: the Mac's main display in its current mode (front_mac.m), or an iPhone's or iPad's screen (front_ios.m). A weak default covers builds without a front end, and the answer is 1080p when the size is not known. The host logs the answer once. Checked: on a 3456x2234 MacBook Pro screen the answer is 1440p, and Fire Emblem Fortune's Weave renders 1024x576 into a 2048x1152 DLSS output, the same as with the 4K answer. With the front end reporting 1920x1080, it renders 960x540 into 1920x1080 at 30 fps (p95 33.7 ms). The host builds and boots the game with one takeover of the name. The iOS compile check (187 files) and test_docs pass. The services.md entry describes the new answer. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What and why
This is split out of #957, as offered in its closing comment.
mainanswersvi::QueryDisplayBufferMaxResolutionwith 4K for every docked game, whatever the screen. A docked Switch 2 answers with what its TV takes, and the game sizes its rendering from that answer. This change answers the same way: in handheld mode, the 1080p screen; docked, the largest of 720p / 1080p / 1440p / 4K that the display the game is shown on holds.The display's size comes from a new front-end call,
front_display_pixels:front_mac.m);nativeBounds, in landscape (front_ios.m);The host logs the answer once. The entry under The display's largest buffer now describes this answer.
Checked
make -C dm/host GAME=04007EF01F8AE000 dmhostbuilds.dm/ios/tools/compile_check.pypasses (187 files).dm/tools/tests/test_docs.pypasses.vi::QueryDisplayBufferMaxResolution: 2560x1440 (docked, display 3456x2234).04007EF01F8AE000, v131072):main's 4K answer, so nothing changes on this Mac.main's chain version.regress.py: not run. Only Switch 2 games call this query, and none is in the local harness.Docs
docs/reference/services.mdentry, andpython3 dm/tools/docs_symptoms.pywas run (no change to the index)🤖 Generated with Claude Code