Skip to content

Game options for 120 FPS, button layout and screen fill; faster builds - #1

Open
imnotsharingmyname wants to merge 2 commits into
Bium23:mainfrom
imnotsharingmyname:fc26-game-options
Open

imnotsharingmyname wants to merge 2 commits into
Bium23:mainfrom
imnotsharingmyname:fc26-game-options

Conversation

@imnotsharingmyname

Copy link
Copy Markdown

Summary

Two changes, both small and gated so existing games and apps behave as before.

1. Game options read extra choices from the app's launcher.json

When a game's app lists these in its Contents/Resources/dm/launcher.json, Game options shows:

  • Frame rate: 30 / 60 / 120 FPS. Shown instead of the 60 FPS switch only when DM_FPS_TARGET offers 120.
  • Button layout: Switch positions / Xbox labels (DM_PAD_LAYOUT).
  • Screen fill: Keep aspect ratio / Fill screen (DM_PRESENT_FILL).

Other games keep the existing 60 FPS switch and see no new rows. GameRuntimeConfig gains highFrameRate, buttonLayout and screenFill. They decode with defaults, so saved configs keep working, and a layout or fill choice is written to env.txt only once it is made.

Note: the pinned nxnative 65501fbb lists only 30/60 and neither of the other two settings, so with apps built from the pinned engine these rows stay hidden. They appear for apps built with an engine that offers them. I built EA SPORTS FC 26 with a local nxnative change that adds 120 FPS, an Xbox-label button layout and screen fill. Before this change, NX Library's 60 FPS switch overwrote that app's 120 FPS setting at every launch.

2. Faster builds

Measured on an 8-core M1 Pro while a 65,047-shader game compiled (Metal 32023.922, certified, no untested-toolchain override):

  • The animated background holds still while a build runs. The moving backdrop cost NXLibrary plus WindowServer close to a core during the shader step.
  • J defaults to the core count plus two, unless the user already set J. Each Metal compile also waits on its process start and file writes, so two extra workers keep every core busy. With the background still, shaders went from 3.7 to 4.4 per second.
  • BuildService starts a user-initiated activity (no App Nap, no idle sleep) for the build's length, next to the existing IOPM assertion, and runs the build at user-initiated QoS.

Checks

  • python3 scripts/check_publication.py: passed
  • python3 -m unittest discover -s Tests/PublicationChecks: OK
  • swift test: 780 tests, 0 failures, including new tests for the frame rate, layout and fill values, decoding of old configs, the rows shown per app, and the worker count
  • bash scripts/build_app.sh with codesign --verify --deep --strict: OK
  • Not checked yet: the new Game options rows in the running app, and a full build started from NX Library with these changes. The 3.7 → 4.4 figure comes from running the same shader compile with these settings, not from a build started in the app.

🤖 Generated with Claude Code

imnotsharingmyname and others added 2 commits November 2, 2026 23:22
Game options: a game whose app lists DM_FPS_TARGET 120, DM_PAD_LAYOUT or
DM_PRESENT_FILL in its launcher.json gets Frame rate (30/60/120), Button
layout and Screen fill rows. Other games keep the 60 FPS switch, and a choice
is written to env.txt only once it is made.

Builds: the animated background holds still while a build runs (it cost close
to a core), J defaults to the core count plus two so Metal compiles waiting on
process start and file writes keep every core busy, and BuildService keeps
App Nap off with a user-initiated activity for the build's length.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.

1 participant