Skip to content

Game User Settings: resolution, fullscreen, VSync, frame limit, scalability, and benchmark

At a glance

Lives on: the global UGameUserSettings object · Setters do: stage requested values; use an Apply function to make them live · Resolution/window preview: Apply Resolution Settings · Accept: Confirm Video Mode, then save · Reject/timeout: Revert Video Mode, then apply resolution again · Quality levels: 0 Low · 1 Medium · 2 High · 3 Epic · 4 Cinematic; overall returns -1 when groups are custom · Hardware benchmark: populates recommendations but does not apply them · Ordinary success output: none · Official page: UGameUserSettings

The one-minute version

  • Set Screen Resolution, Set Fullscreen Mode, Set VSync Enabled, frame limit setters, and quality setters change requested values on the settings object. A setter firing is not proof that the live display/render state changed.
  • Output resolution/window mode and resolution scale are different controls. Output resolution is the presented window/backbuffer size; resolution scale changes the 3D scene's internal render percentage before it is upscaled. User interface (UI) is normally drawn after that upscale.
  • Get Resolution Scale Information gives both the real scale value and a normalized 0–1 position for a Slider. Do not display the normalized number as though it were the actual percentage.
  • VSync is a requested on/off policy. Frame Rate Limit uses frames per second; 0 means no limit from that setting. VSync, platform frame pacing, smoothing, or another cap can still impose a lower effective rate.
  • Current UE 5.8 quality setters use 0–4 from Low through Cinematic. Set Overall changes the group values together; changing one group afterward makes Get Overall Scalability Level return -1 for a custom mix.
  • Apply Resolution Settings handles resolution/window mode only. Apply Non-Resolution Settings handles the other supported settings. Apply Settings runs the full path and saves.
  • Never apply a risky resolution and immediately trust it. Preview it, show a short real-time confirmation countdown, confirm only on explicit acceptance, and revert/apply on rejection or timeout.
  • Run Hardware Benchmark populates recommended scalability values and result fields; it does not make them live. Apply Hardware Benchmark Results applies and saves them.
  • Platforms, command-line recovery overrides, device profiles, display support, and frame pacing can overrule or constrain requested settings. Verify in a packaged build and read back what was accepted.

The four display states people accidentally collapse

One phrase—“the resolution”—can refer to four different values:

State Meaning Example
Requested output mode Values currently stored on UGameUserSettings 2560×1440, Windowed Fullscreen
Current live output What the window/display system is actually presenting desktop-sized borderless window
Last confirmed video mode Resolution/window pair accepted by the player 1920×1080, Fullscreen
Internal scene resolution 3D render size after resolution scale/upscaling policy about 67% of output before upscale

Setters change the first row. Apply requests a live change. Confirm copies the accepted video pair into the last-confirmed state. Resolution scale changes the fourth row, not the window size.

This page assumes you already have the correct global settings reference and understand requested/live/persisted state. See Get / Load / Apply / Save / Reset Game User Settings.

Resolution and window mode

Set Screen Resolution(FIntPoint) stores a requested width and height. Set Fullscreen Mode(EWindowMode) stores a requested window mode. The ordinary enum choices are:

  • Windowed — a movable desktop window with a client size;
  • Windowed Fullscreen — borderless presentation sized/managed like the desktop display; and
  • Fullscreen — an exclusive-style fullscreen request where the platform supports it.

These are requests, not cross-platform guarantees. A desktop window manager, console/mobile policy, remote session, multi-monitor setup, or command-line override can force a different result. Borderless modes commonly follow the desktop output rather than treating every arbitrary resolution like an exclusive display mode.

Offer supported choices, not invented dimensions

For fullscreen choices, Get Supported Fullscreen Resolutions returns an array of IntPoint values plus a Boolean saying whether the device query succeeded.

pseudocode — building the resolution draft list

Success, Resolutions = GetSupportedFullscreenResolutions()
if not Success or Resolutions is empty:
    keep current/known-safe choice
    disable the selector with an explanation
else:
    filter invalid sizes
    sort and deduplicate for presentation
    retain width + height as the typed value

Do not persist a label such as "1440p" and later parse it. Store the full IntPoint; multiple aspect ratios can share one vertical number. Preserve a current platform-accepted mode even if a transient enumeration did not return it, so opening the menu does not silently replace a working configuration.

Output resolution versus resolution scale

Output resolution sets the target the player sees—such as 1920×1080. Resolution scale changes how densely the 3D scene is rendered before an upscaler presents it at that output size. Epic's rendering path applies primary scene upscaling before normal UI drawing, so lowering 3D resolution does not normally mean the menu itself must render at the same low pixel count.

Example:

output resolution: 1920 × 1080
resolution scale:  83%
approximate 3D scene input: 1600 × 900
upscale target:    1920 × 1080
UI composition:    after the primary scene upscale

Actual render dimensions and image quality also depend on the active temporal or spatial upscaler, dynamic-resolution policy, minimum scale, and platform.

Use the Game User Settings API rather than assuming a hard-coded 10–100 range:

  • Get Resolution Scale Information returns current normalized position, current scale value, minimum scale value, and maximum scale value;
  • Set Resolution Scale Normalized accepts the Slider-friendly 0–1 position inside that current min/max range; and
  • Set Resolution Scale Value accepts the real scale value.

If the UI displays “83%,” use the real current scale value. The normalized position only says where that value sits between the engine's current minimum and maximum.

Resolution scale is not UMG DPI scaling. UI DPI rules change widget layout scale; render resolution scale changes the scene rendering workload.

VSync and frame limit

VSync

Set VSync Enabled(bool) stages whether presentation should synchronize to the display's vertical refresh. It is applied through the non-resolution/full Apply path. It does not promise a particular refresh rate or frame latency mode.

Platform presentation policy and the chosen display mode can constrain VSync. After Apply, use the relevant readback/dirty state and actual performance tools; do not treat the requested Boolean as measured behavior.

Frame Rate Limit

Set Frame Rate Limit(float) stages a frames-per-second cap. The stock contract uses 0 to disable this limiter.

“Unlimited” does not mean the process will present infinite frames. The effective rate can still be constrained by:

  • VSync and display refresh;
  • platform frame pacing;
  • frame-rate smoothing or project policy;
  • a device profile or console-variable override;
  • CPU/GPU performance; or
  • a custom UGameUserSettings subclass's effective-limit policy.

Give the UI a bounded, validated list such as 30, 60, 120, and Unlimited (0) based on project/platform policy. Reject negative, NaN, or absurd draft values before calling the setter rather than hoping another layer repairs them.

Scalability groups and custom quality

The current Game User Settings class exposes individual groups including view distance, anti-aliasing, shadows, global illumination, reflections, post processing, textures, visual effects, foliage, shading, and landscape.

For the standard integer quality setters:

Value Label
0 Low
1 Medium
2 High
3 Epic
4 Cinematic

The setters clamp unsupported integer values into their accepted range, but a platform/device profile can still make two labels look similar or force a different practical result. A project's BaseScalability.ini and platform overrides define what each level actually changes.

Set Overall Scalability Level sets the groups to one shared tier. It is a convenience, not a permanent parent value. If the player chooses Overall High and then sets Shadows Low, the state is a custom mixture; Get Overall Scalability Level can return -1 to say no single preset describes it.

Model that honestly in the Combo Box:

OverallQualityId
  Low | Medium | High | Epic | Cinematic | Custom

read GetOverallScalabilityLevel
-> -1: display Custom
-> 0..4: display matching preset

Do not coerce -1 to Low or automatically overwrite individual choices merely to make the combo show a named preset.

Resolution quality is a float/percentage policy rather than just another integer group. Keep it attached to the resolution-scale controls described above, especially when dynamic resolution or a modern upscaler participates.

Set versus apply versus save

Use the narrowest apply function that matches the interaction:

Function What it makes live Saves config
Apply Resolution Settings requested output resolution and window mode No general save contract
Apply Non-Resolution Settings supported quality, VSync, frame cap, dynamic resolution, and other non-resolution state No general save contract
Apply Settings both resolution and non-resolution paths Yes
Apply Hardware Benchmark Results benchmark-populated scalability values Yes

Every one of these ordinary calls returns no success Boolean. “The execution pin continued” means the request code completed, not that a monitor accepted the exact mode or a config write succeeded.

The full Apply function is correct for ordinary accepted changes. It is the wrong first step for a risky video preview because it persists the requested mode before the player has proved they can see and accept it.

The Confirm / Revert video-mode pattern

Use the settings object's last-confirmed video fields as the recovery anchor. The confirmation dialog owns a short deadline measured from real time so pause or time dilation cannot freeze the rollback.

pseudocode — Blueprint transaction, not engine source

PreviewVideoMode(RequestedResolution, RequestedWindowMode)
-> Settings.SetScreenResolution(RequestedResolution)
-> Settings.SetFullscreenMode(RequestedWindowMode)
-> Settings.ApplyResolutionSettings(CheckCommandLineOverrides = true)
-> show "Keep these settings?" dialog
-> Deadline = GetRealTimeSeconds() + 15

player selects Keep
-> Settings.ConfirmVideoMode()
-> Settings.SaveSettings()
-> close dialog

player selects Revert OR real-time deadline expires
-> Settings.RevertVideoMode()
-> Settings.ApplyResolutionSettings(CheckCommandLineOverrides = true)
-> Settings.SaveSettings()
-> close dialog after the known-good mode is requested

Important details:

  • Confirm Video Mode records the current requested resolution/window mode as last confirmed. It does not visually ask the player or return proof that the display is usable.
  • Revert Video Mode restores the last-confirmed resolution/window request. Apply Resolution Settings again so the restored request becomes live.
  • Use a real-time deadline, not a gameplay Timer that can stop with pause.
  • Keep keyboard/gamepad focus on the confirmation dialog and make Revert easy.
  • If the app closes/crashes before confirmation, startup should prefer a known good/validated configuration rather than trusting an unconfirmed preview.
  • Do not let two dialogs own overlapping video previews; serialize the request and ignore stale timeout callbacks by generation ID.

If other non-resolution options are part of the same draft, apply/persist them in a deliberate order after video acceptance or track their result separately. There is no engine-level atomic transaction spanning them.

Hardware benchmark: populate first, apply second

Run Hardware Benchmark(Work Scale, CPU Multiplier, GPU Multiplier) performs the benchmark and populates:

  • the settings object's ScalabilityQuality recommendations; and
  • the stored last CPU/GPU benchmark result and step fields.

It deliberately does not apply the recommendations. Epic pairs it with Apply Hardware Benchmark Results, which applies those quality values and saves settings.

That split supports two product patterns:

Auto button with review
-> Run Hardware Benchmark
-> read recommended groups into Draft
-> show the proposed result
-> player chooses Apply or Cancel

first-run automatic policy
-> Run Hardware Benchmark
-> validate recommendations
-> Apply Hardware Benchmark Results

The second pattern is only appropriate when the product has decided that Auto may apply immediately. Do not run a potentially visible performance workload every time the menu opens. Gate it behind a first-run/Auto action, show progress where practical, and keep sensible fallback values available through the benchmark-fallback API if the benchmark cannot complete reliably.

Neither Run nor Apply Hardware Benchmark Results returns a success Boolean. Read the populated result values, validate them, and retain a safe preset.

Safe startup and recovery

A display settings screen should assume that bad or externally forced state is possible:

  1. load/validate settings once during startup;
  2. retain a last-confirmed or project-safe windowed mode;
  3. let command-line recovery overrides win during normal Apply calls;
  4. offer only device-supported choices where enumeration succeeds;
  5. preview risky video changes behind a real-time rollback dialog;
  6. save only accepted/restored state; and
  7. test restart after accepting, reverting, timing out, and force-closing.

Do not make the only recovery path “open the same invisible menu.” A packaged desktop build should have a documented safe launch/config-reset route, and the game should validate stale settings after hardware/display changes.

PIE cannot prove this workflow. Test Standalone, then a packaged Development build on the target platform and more than one display/aspect ratio when those are supported.

When it fails (and what failure does)

Failure What happens Safe response
Resolution enumeration fails Boolean false and no trustworthy choice array retain current/safe mode; disable selector with explanation
Requested mode is unsupported/overridden no failure pin; live state may differ and dirty/readback may remain show the accepted state, not the requested label
New mode is unusable user cannot confirm before deadline Revert Video Mode → Apply Resolution Settings → save restored state
Config save fails Apply/Save exposes no ordinary Boolean use project-owned verification/reporting when persistence success matters
Benchmark yields unusable/no trusted result no success branch from Run validate results and use benchmark/project fallback values
Overall getter returns -1 groups are a custom mix, not an error display Custom and preserve individual values
PIE appears to ignore window mode editor viewport/window owns presentation verify Standalone/package before diagnosing shipped behavior

These calls do not throw gameplay exceptions or automatically show a fallback dialog. The settings coordinator owns user-visible recovery.

What these settings do not do

  • Output resolution does not directly specify internal 3D resolution scale.
  • Resolution scale does not replace UMG DPI/layout policy.
  • VSync does not guarantee a particular frame rate or latency.
  • Frame Rate Limit 0 does not disable every other frame-pacing constraint.
  • A named scalability tier does not guarantee identical visuals across platforms or project scalability config.
  • Run Hardware Benchmark does not apply or save by itself.
  • Confirm Video Mode does not test visibility for you.
  • Local graphics preferences do not replicate and are irrelevant to gameplay authority on the server.

Lookalikes — which one do I want?

Control / function Use it for Not the same as
Screen Resolution Output/window presentation dimensions Resolution Scale / screen percentage
Resolution Scale Internal 3D render percentage before upscale UMG DPI Scale or output resolution
Fullscreen Mode Windowed, borderless-style, or exclusive-style request Monitor/display selection or resolution
Apply Resolution Settings Temporary or confirmed video-mode request Full Apply + save
Apply Non-Resolution Settings Quality/VSync/frame-cap state without changing video mode Persistence
Apply Settings Apply all accepted settings and save Safe unconfirmed video preview
Confirm Video Mode Mark current video pair as accepted Apply it or ask the user
Revert Video Mode Restore last-confirmed video request Apply the restored request
Set Overall Scalability Level One preset across groups Permanent lock preventing custom groups
Run Hardware Benchmark Populate recommendations/results Apply Hardware Benchmark Results

Going deeper