CheezyEmu TEST build test-e7c327f (e7c327f)

Automatic build of test-e7c327f at e7c327f.

Warning

This is a test build for testers, not a release. It may have bugs the released build does not. The in-app updater does not offer it, and a test build does not update itself: download the next build by hand.

Important

Read README.txt (next to cheezyemu.exe after you unzip, or on GitHub): how to turn switches on and off, install and move shader packs, and use AMD FSR upscaling and AMD frame generation. Changes and credits: CHEEZYEMU.md.

💬 Join the CheezyEmu Discord for help, bug reports and new builds: https://discord.gg/vEK4ug6JD

What's new

Not released yet: this section grows as the work lands.

• AMD FSR on Linux and macOS (new, needs testing there). Ocarina's FSR path was only
  compiled into Windows builds (the status bar said "FSR (WINDOWS ONLY)"). It is in every desktop
  build now. Where AMD's own runtime is not there, which is every system but Windows, the FSR 3.1
  passes built into CheezyEmu do the upscale and anti-aliasing from the same inputs (the game's
  colour, depth and the camera and character motion). On Windows nothing changes: AMD's runtime
  (FSR 4 or 3.1) is still used, and the built-in one takes over when that cannot start. Frame
  generation stays Windows only. Tested on Windows by forcing it (EDEN_NX2_FSR_BUILTIN=1):
  standing and moving in Hyrule Field, 55 fps at Native AA on an RX 6750 XT. Not yet run on Linux.
• Ghosting on Link's arms and legs (walking, jumping, crawling) with FSR and frame
  generation. His bare forearms, hands and thighs smeared or tore whenever he moved against
  the background, while his body, hat and gear were fine. Cause: the motion CheezyEmu gives FSR
  for characters is rebuilt from the game's bones, and it blended every bone slot a mesh's
  vertices have room for. The limb mesh uses 7 of its 8 slots and keeps other data in the
  eighth, which put the limbs in the wrong place, so their pixels fell back to the scenery's
  motion. The game says how many slots each mesh uses, and that count is used now. Checked on
  captured frames: generated frames now show the arms and hands as the real frames do, running,
  strafing, side hops and a backflip. Not checked inside a crawl tunnel (no save near one), but
  it is the same mesh. EDEN_NX2_OOT_INFLUENCES=0 brings the old behaviour back, to compare.
• Sessions that ran slow for no visible reason. The same Hyrule Field walk ran at 44-47 fps
  in some sessions and 36-39 fps with 100-185 hitches in others. In the slow ones video memory
  use had crept up to the texture cache's limit (the game grows a 1 GB block of its memory a
  little, and other programs such as a browser or Discord lower the driver's budget), and from
  then on the cache deleted textures still on screen and re-created them a few frames later,
  about two a frame for the rest of the session. It now keeps textures used in the last 300
  frames unless the card is really out of memory. At the limit, same walk: 185 hitches before,
  15 to 31 after. EDEN_NX2_TC_MIN_AGE=0 brings the old rule back.
• Less hitching while walking around.
  • The buffer collector ran in emergency mode on every frame in Ocarina of Time: the game keeps
    about 1.5 GB of buffers in use, and "more than 1 GB of buffers" was the emergency. It threw
    away up to 64 buffers a frame that the game bound again a moment later (about 120 buffers
    created and deleted and 20 memory requests to the driver every second while walking). It now
    looks at how much is idle. Same PC, same routes, one run each way: 49.6 against 43.6 fps
    standing, 11 against 21 frames over 50 ms on one route and 2 against 4 on the other.
    EDEN_NX2_BUFFER_GC_TOTAL=1 brings the old rule back.
• Linux: the update check works. It failed before any request was sent ("returned null")
  on systems whose certificates are not where the build machine's are (SteamOS). It uses the
  system's certificate bundle now, and the log says why a request failed.
• Shaders are built in: no shader pack needed for Ocarina of Time. CheezyEmu now ships a
  shader recipe for the game: a 3 MB list of 116,570 pipelines, with none of the game's code in
  it. The first 39,000 are the ones players' sessions drew; the other 77,600 come from
  Fritchii's recipe for the game (Fritchii v5.7, by Frizti), which also predicts pipelines
  nobody recorded yet. The first time you start the game, the loading screen reads
  your own copy of the game for its shader programs (about a minute, "Gathering this game's
  shaders"), puts the two together and builds every pipeline ("Building shaders N / M (once)",
  with the time left and a Skip button). After that, places you visit for the first time
  already have their shaders. It is done once per GPU driver, and an update of CheezyEmu
  does not start it over: what is built is remembered by driver and cache version, not by
  build, and a later, bigger recipe only builds what is new.
  • How long it takes depends on what you already have. Shaders saved by earlier builds are
    done in seconds. Ones never compiled on your PC take the time: an RX 6750 XT with a
    12-thread CPU compiles about 55 a second, so a PC with nothing saved needs half an hour or
    more for everything. The recorded pipelines come first, so pressing Skip after a while
    still leaves you with the ones that matter most.
  • Skip no longer throws the rest away: the game starts and the rest keeps building while
    you play, on one thread below normal priority (two cost about 4 fps of 46 on a 6-core
    CPU; EDEN_NX2_PRECACHE_AFTER_SKIP=2 allows them). It pauses while the game builds its
    own shaders and when the PC is short of memory (under 3 GB that Windows can still hand
    out), and what is not built when you quit is built on the next start.
    EDEN_NX2_PRECACHE_AFTER_SKIP=0 stops at Skip, as before.
  • macOS: the recipe is inside the app (Contents/Resources/recipes).
  • A crash right after the shader build on AMD cards is fixed. A few compute shaders
    (software matrix code) go to a separate slow-build thread on AMD; the shader build threw
    each one away while that thread still had to build it, and the emulator crashed a few
    seconds after "Building shaders" finished. The game builds those itself when it needs
    them, as before.
  • It needs about 2.2 GB of disk for the assembled file, next to your shader cache.
  • For any other game the same loading screen builds the compute programs found in the game
    files and the pipelines your earlier sessions saved ("Precache shaders before game
    start", now on by default; Off in Graphics > Advanced brings build 11's behaviour back).
  • Your old shader pack still works and is used too.
  • The shader finder, the recipe format and the assembler are Fritchii's (Frizti), built on
    zortos293/Lichii#895; program fingerprints follow nxnative's shader_split.py (seedds, MIT).
    CheezyEmu's part: recipes made straight from a recorded cache (CHEEZYEMU_MAKE_RECIPE),
    and building them through the loading screen's precache.
• Windows fit the screen. On a small laptop or handheld screen, or with a high Windows
  display scale, Configure and a game's Properties opened larger than the screen: settings were
  cut off until you dragged the window, and a window could end up stuck outside the screen.
  Their pages now scroll, the windows have no fixed minimum size, every window and dialog is
  made to fit the screen it opens on, and one that ends up off the screen is brought back.
• White flashes ("flashbang") and stretched, glowing geometry after changing areas: upstream
  Lichii found the cause and its fix is in (zortos293/Lichii#1199 and #1236, with 99ivs and
  PantACRO4life). Video memory the game had freed kept its old contents on the emulator's side,
  so when the game reused that address, meshes read other data as vertices until a restart. If
  you still see it, send the log of that session (eden_log.txt.old.txt if you have reopened
  CheezyEmu since).
• "Find Best Settings for This PC": one button at the bottom of Emulation > Configure (also
  in Help). It looks at your graphics card, its video memory and your RAM and sets the
  performance options, AMD FSR, frame generation and Ocarina of Time's render size to match,
  shows what it changed, and Help > Restore My Previous Settings undoes it. Settings made for a
  single game are not touched. Based on upstream's recommended settings (#1200).
• FSR presets: Balanced did not start FSR or frame generation (greyed out in the status
  bar), docked or handheld: the game's scene image is up to 12 pixels wider than the copy the
  upscaler reads and only 4 were allowed. Quality and Balanced were also slower than Native AA:
  the emulator copied the depth buffer about 200 times a frame for them. On the test PC
  (RX 6750 XT) Quality with frame generation went from 36 to 49 fps.
• FSR and frame generation "waiting" on cards short of video memory (an RX 9060 XT 8 GB at
  4K): when FSR 4 could not start, FSR stayed off for the whole session. It now frees memory,
  falls back to FSR 3.1 at once, and tries again later if nothing starts.
• Out of memory:
  • A card that ran out of video memory could end the emulator (RX 5600 XT 6 GB, 17 minutes
    into Ocarina): buffers now fall back to system memory the way images already did.
  • PCs with 16 GB of RAM: the texture cache stays within what Windows can still hand out
    (upstream #1210), half as many idle shaders are kept in memory (about 0.9 GB), and when
    Windows runs out of page file the game waits for it to grow instead of crashing, and the
    log says what to change. Frame generation alone keeps about 1.5 GB of RAM: turn it off on
    a 16 GB PC if memory is short, and leave the page file on "System managed size".
  • The log has a "Vulkan memory" line every 30 seconds (video and system memory in use).
• Less video memory on AMD with ASTC recompression on BC3 or BC1 (the default on cards under
  20 GB). Most of Ocarina's textures are ASTC, which AMD cards cannot read, so they are
  converted. AMD's driver draws the smallest mip levels of some converted textures wrong (dark
  lines on distant ground, zortos293/Lichii#448), so those textures were kept uncompressed
  instead: four times the memory, 3 to 3.5 GB of Ocarina's textures even with BC3 chosen. They
  now stay BC3 with only their few tiny levels (6x6 pixels and smaller) left out: 0.6 to 0.9 GB
  less video memory in the same walk, no lines seen, and no more hitching than before (10 boots
  compared). Two large terrain textures (1.7 GB) still stay uncompressed: leaving out their
  levels would blur the ground. EDEN_NX2_BC_TAIL_TRIM=0 brings the old rule back. If you chose
  Uncompressed yourself, nothing changes.
  • For reports: with EDEN_NX2_TC_LOG=1 the log says how much video memory textures really
    hold, how much of it is ASTC kept uncompressed and in which texture sizes;
    EDEN_NX2_BIG_ALLOC_LOG=<MiB> logs every larger video memory request and
    EDEN_NX2_VK_MEMORY_LOG_FRAMES=<n> the memory every n frames.
• New performance bar (View > Performance Overlay): one black strip with frame rate (with
  frame generation), frame time, a frame rate history, FSR and frame generation status, RAM and
  video memory. Drag it anywhere over the game; it snaps to the edges and remembers its place.
  Right-click it for corners, a compact mode, and the graphics choices of the status bar
  (upscaling filter, anti-aliasing, frame generation, docked or handheld), which fullscreen
  hides.
• A box to type the number in next to sliders (frame rate limit, sharpness, speed).
  Sharpness shows its percentage there too.
• Dialogs checked by picture: the "Use recommended settings" button of Find Best Settings
  was cut off ("Jse recommended setting"), and a game's Properties showed the end of long game
  and file names instead of their start. Both fixed.
• The status bar fits a small window: the renderer, accuracy, dock, filter, anti-aliasing
  and FX buttons are one GRAPHICS button that opens the same choices as a menu, the FSR button
  shows the name only (the sizes are in its tooltip and in the performance bar), and
  "Scale: 1x" is hidden.
• From upstream Lichii build 150: the ocarina crackle (#1196), a stand-in texture where the
  game dump's own texture is damaged (dark Water Temple walls and fairy fountain, #1197), Mario
  Kart World's dark characters and karts (#1231), changing settings while a game loads no
  longer freezes the window (#1168).
• When CheezyEmu fails to stop a game, the log now says what the graphics shutdown waited for.
• EDEN_NX2_MESH_EMULATION=0 (test): on a GPU without mesh shaders (Apple, older cards) the
  grass and props drawn with them are left out, as in builds up to 8, instead of drawn through
  compute. For a report of Ocarina freezing on an Apple M1 Pro while loading a save.

Tip

Ocarina of Time above 60 fps: press Ctrl+U (the Toggle Framerate Limit hotkey) to unlock the frame rate, or set Frame rate limit (Switch 2) under the game's Properties > Graphics (e.g. 120; applies when the game starts) to cap it there. The FPS Unlock (built-in) add-on, on by default, keeps animations and physics at normal speed at any frame rate; leave it enabled.

Linux

Linux packages come as an AppImage (self-contained, needs glibc 2.39 or newer: Ubuntu 24.04, Fedora 40, Debian 13, Arch) and a tar.gz (uses your system libraries, so Qt 6 and the usual libraries must be installed).

AMD on Linux / SteamOS: from build 11 CheezyEmu draws mesh shader geometry the safe way by itself (native mesh shaders hang or reset AMD GPUs on RADV). On older builds, or to force it on any GPU, add EDEN_NX2_FORCE_MESH_FALLBACK=1 %command% to the launch options.

Build Type	Standard	PGO (Recommended)	Notes
amd64	AppImage · tar.gz	AppImage · tar.gz	Make the AppImage executable (chmod +x) and run it
ARM (aarch64)	AppImage · tar.gz	AppImage · tar.gz

Windows

Windows packages are in-place zip files: extract and run cheezyemu.exe, or cheezyemu-cli.exe from a terminal.

Build Type	Standard	PGO (Recommended)	Notes
amd64 / x86_64	zip	PGO zip	Both built with clang-cl and ThinLTO; the PGO zip adds a profile trained on Ocarina of Time

macOS

Build Type	Standard	PGO (Recommended)	Notes
arm64 (Apple Silicon)	zip		macOS 15 or newer. Not notarized: right-click and choose Open the first time, or run xattr -dr com.apple.quarantine cheezyemu.app. cheezyemu-cli is inside the app, in Contents/MacOS

The PGO builds are the same programs compiled with profile-guided optimization. Linux uses clang with Eglantine's profile; Windows uses clang-cl and ThinLTO with a profile trained in CheezyEmu on Ocarina of Time, so other games gain less. Prefer them when your CPU supports it.