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 w...

CheezyEmu TEST build test-4cd8240 (4cd8240)

Automatic build of test-4cd8240 at 4cd8240.

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 w...

CheezyEmu TEST build test-c1eecfd (c1eecfd)

Automatic build of test-c1eecfd at c1eecfd.

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

• Upstream Lichii's newest GPU work is merged (zortos293/Lichii nx2 up to #1056, without its
  shader cache v2, which would not carry over saved AMD pipelines and means a 30+ minute first
  boot). The two GPU threads take turns less: macros that read memory run on the second thread,
  command lists wait only for the work the console would wait for, and read-backs no longer hold
  the GPU thread. Ocarina of Time, Hyrule Field, i5-12600K + RX 6750 XT, no upscaler: about 45 to
  49-50 FPS, and the slowest frames drop from 42-51 ms to 24-29 ms (far fewer hitches).

• White flashes and huge glowing triangles after playing a while (Ocarina of Time): cause
  found, fix not on yet. A compute shader's writes are tracked only as far as an analysis proves
  it writes; a few shaders write further now and then, the game reads stale particle data back and
  draws giant bright triangles from it, which the bloom turns into a flash that stays until a
  restart. A check that catches those shaders is in this build (after Frizti/Fritchii v5.6's
  write extent check) but off by default: tracking a caught shader's whole memory window can
  overwrite values the game is waiting for, and with several shaders caught the game froze on a
  black screen. EDEN_NX2_EXTENT_CHECK=1 turns it on for testing (it logs "Compute write extent
  too small" for each shader it catches). It needs narrower tracking before it can be the default.

• White flashes ("flashbang") in Ocarina of Time: the game sizes its glare from occlusion
  query reports, and a report could reach it before the graphics card had finished the work it
  measures. Upstream's fix for that (#337) had been taken out of the line this fork is built on,
  for speed; it is back, with the upstream work above paying for it. Not yet confirmed over a long
  play session: please report a flash with the log.

• Frame generation: Link no longer tears while he moves. Generated frames doubled and broke
  his limbs, sword and middle (ghost hands, torn boots) because only part of him was given
  motion of his own; the rest got the scenery's. Three causes, found by saving the generated
  frames and the motion they were made from: parts bound to a single bone per vertex (sword,
  scabbard, hat) were not recognised; his largest mesh keeps its pose in another slot than the
  rest; and two of his 282 bones and, in busy scenes, any character past the 64th were left out.
  Still open: his bare forearms and thighs in a fast sideways run.

• Fewer freezes on new ground. A shader the game needs for the first time was built with the
  whole frame held whenever its draw went to a target the game never clears, which is most of
  them: 8 to 51 ms each, and now and then over a second. Draws into targets used every frame are
  now left out for the few frames the shader takes instead (as was already done for cleared
  targets). Same fresh route in Hyrule Field: worst frame 97 ms instead of 1.1 to 1.7 s, no
  frame over 100 ms instead of three. Tiny targets (brightness measurement) always wait.
  EDEN_NX2_TRANSIENT_TARGETS=0 brings the old rule back.

• AMD GPU hangs and resets on Linux, and the handheld black screen after the opening
  cutscene: the mesh shader fallback is now used by itself on every AMD GPU under Linux's RADV
  driver, and on integrated Radeons under AMD's Windows driver. Native mesh shader draws reset
  RX 6000, 7000 and 9000 cards on RADV and time out the Radeon 780M (zortos293/Lichii#871, as in
  Fritchii v5.6; a player's Xbox Ally X fix first showed it here). Desktop Radeons on Windows keep
  the native path, which runs there. The first boot with the fallback builds its own shaders.
  EDEN_NX2_FORCE_MESH_FALLBACK=0 turns it off, =1 forces it on any GPU.

• About 1 GB less RAM in Ocarina: memory the game cleared to zero is given back to the system
  sooner (zortos293/Lichii#961 with Fritchii v5.6's faster page check).

• Ocarina runs faster: zortos293/Lichii#1161 by Lucas Borges is in (the game's GPU command
  stream waits less for itself, images are reused, reports are cheaper). On the test PC
  (i5-12600K, RX 6750 XT, no upscaler) Hyrule Field went from about 51 to 59 fps standing and
  from 43 to about 50 fps running around.

• Linux, AMD (RADV): GPU reset with "Illegal opcode in command stream" when the first
  tessellated terrain was drawn. The primitive topology set at draw time did not match the
  tessellation pipeline's patch list; Windows drivers let it pass. Not yet confirmed fixed on the
  reporter's machine.

• From the sister fork: Ocarina's periodic texture stalls on 10+ GB cards (#1129), the Castle
  Town guard house freeze (#976), the Song of Time crackle (#1073).

• .nx game archives load (upstream #923, #1078, #1127); right-click a game in the list and
  pick "Convert to NX..." to make one.

• A texture made where the memory collector had dropped an older one could start without its
  data (upstream #818's last fix): candidate for shadows and textures going wrong after a while.

• CheezyEmu has its own data folder: %APPDATA%\cheezyemu on Windows, and cheezyemu
  under ~/.config, ~/.local/share and ~/.cache on Linux. Eden, Lichii and Fritchii all share
  the eden folder, so their settings overwrote each other. The first start offers to import the
  old folder: "Keep Old Data" copies it (saves, settings, keys, mods and saved shaders), "Clear Old
  Data" moves it, "Link Old Directory" keeps sharing it. Saved shaders are kept unless you tick
  "Clear Shader Cache". (GitHub issue #1)

• Frame generation works again on AMD's newer drivers (docked and handheld). When AMD's
  FSR 4 frame generation started without all the functions CheezyEmu needs, build 10 gave up and
  frame generation stayed off; now it carries on, or falls back to the FSR 3.1 version.

• FSR presets work docked too. Docked (4K output) the sizes double: Native AA 3840x2160,
  Quality 2560x1440, Balanced 2250x1266, Performance 1920x1080, Ultra Performance 1280x720. In
  build 10 a docked preset turned FSR and frame generation off.

• Frame generation's Auto setting picks FSR 3.1 on cards that can't run FSR 4's (everything
  but the RX 9000 series). AMD's runtime offered FSR 4 frame generation to other cards too, where
  it never made a frame, so players had to pick FSR 3.1 by hand.

• No more blinding white lighting in Link's house and Kokiri Forest with "Switch 2 draws with
  unbuilt pipelines" on Skip or Bounded: those modes dropped the game's brightness measurement
  while its shader built, and the exposure stayed stuck until a reset. Draws like that always
  wait now.

• No more red flickering (an upstream change build 10 had taken out is back).

• Fewer freezes and black screens after cutscenes: two fixes from Lichii build 130 (GPU
  wait handling and its 32-region limit).

• "Closing software..." no longer freezes CheezyEmu. When a game gets stuck closing,
  CheezyEmu used to kill the stuck part, which could freeze the whole window until Task Manager
  ended it. Now it restarts itself instead (or just exits when you're quitting) and says so.

• FSR 4 black screen: when FSR 4 draws black (older AMD drivers), CheezyEmu notices sooner
  and switches to FSR 3.1. Updating the AMD driver fixes the cause.

• Crash reports: a crash now writes a crash dump to crash_dumps in the data folder and a
  line in the log saying where it happened. In Ocarina the log also says why FSR or frame
  generation didn't turn on.

• AMD FSR in the status bar and the performance overlay: an FSR button shows the version
  running (FSR 4.1.2, FSR 3.1.6) or why it isn't (OOT ONLY, RES 1X, WAITING, WINDOWS ONLY), like
  the frame generation one. The overlay shows both, so they're visible in fullscreen.

• Tools > Switch 2 Switches: checkboxes for the nx2_switches.txt switches players use most
  (semaphore mirror, GPU thread split, keep ASTC, build every shader at boot...).

• FSR presets fixed and docked output: Quality, Balanced and Ultra Performance start FSR and
  frame generation now (only Performance and Native did). Docked, "Ocarina of Time docked output"
  picks 4K or 1440p (lighter), and presets render a fraction of that output, as in PC games.

• FSR camera jitter (test): Tools > Switch 2 Switches > "FSR camera jitter". FSR rebuilds fine
  detail from a camera nudged by less than a pixel every frame; without it low presets look
  blocky. Off by default while it is tested: turn it off again if the picture shakes.

• Graphics that broke after a few minutes: a shader thrown out after 9,000 unused frames could
  be rebuilt wrong when it was needed again (from Lichii, not merged there yet).

• Performance: cheaper per-draw work on the GPU thread and fewer pointless texture uploads
  (Lichii #858, #910, #921, #1079).

• New icon (vector, sharp at any size).

• More fixes from Lichii build 130.

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 ...

CheezyEmu TEST build test-8a88c39 (8a88c39)

Automatic build of test-8a88c39 at 8a88c39.

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

• Upstream Lichii's newest GPU work is merged (zortos293/Lichii nx2 up to #1056, without its
  shader cache v2, which would not carry over saved AMD pipelines and means a 30+ minute first
  boot). The two GPU threads take turns less: macros that read memory run on the second thread,
  command lists wait only for the work the console would wait for, and read-backs no longer hold
  the GPU thread. Ocarina of Time, Hyrule Field, i5-12600K + RX 6750 XT, no upscaler: about 45 to
  49-50 FPS, and the slowest frames drop from 42-51 ms to 24-29 ms (far fewer hitches).

• White flashes and huge glowing triangles after playing a while (Ocarina of Time): a second
  cause is closed. A compute shader's writes were tracked only as far as an analysis proved it
  writes; one shader writes further, the game read stale particle data back and drew giant bright
  triangles from it, which the bloom turns into a flash. Every compute shader is now checked
  against what it really wrote, and tracked in full if it wrote further (port of Frizti/Fritchii
  v5.6's write extent check, made stricter here: these shaders write far only now and then, so a
  shader needs four clean checks before it is trusted and is checked again every 30 seconds; the
  three shaders caught so far in Kakariko Village are tracked in full from the first frame, and
  any shader your PC catches is remembered for later sessions in shader/extent_distrust.txt).
  No fps cost measured. The log says "Compute write extent too small" when it catches one.
  EDEN_NX2_EXTENT_CHECK=0 turns the check off. If you still see a flash, please send the log.

• White flashes ("flashbang") in Ocarina of Time: the game sizes its glare from occlusion
  query reports, and a report could reach it before the graphics card had finished the work it
  measures. Upstream's fix for that (#337) had been taken out of the line this fork is built on,
  for speed; it is back, with the upstream work above paying for it. Not yet confirmed over a long
  play session: please report a flash with the log.

• Frame generation: Link no longer tears while he moves. Generated frames doubled and broke
  his limbs, sword and middle (ghost hands, torn boots) because only part of him was given
  motion of his own; the rest got the scenery's. Three causes, found by saving the generated
  frames and the motion they were made from: parts bound to a single bone per vertex (sword,
  scabbard, hat) were not recognised; his largest mesh keeps its pose in another slot than the
  rest; and two of his 282 bones and, in busy scenes, any character past the 64th were left out.
  Still open: his bare forearms and thighs in a fast sideways run.

• Fewer freezes on new ground. A shader the game needs for the first time was built with the
  whole frame held whenever its draw went to a target the game never clears, which is most of
  them: 8 to 51 ms each, and now and then over a second. Draws into targets used every frame are
  now left out for the few frames the shader takes instead (as was already done for cleared
  targets). Same fresh route in Hyrule Field: worst frame 97 ms instead of 1.1 to 1.7 s, no
  frame over 100 ms instead of three. Tiny targets (brightness measurement) always wait.
  EDEN_NX2_TRANSIENT_TARGETS=0 brings the old rule back.

• AMD GPU hangs and resets on Linux, and the handheld black screen after the opening
  cutscene: the mesh shader fallback is now used by itself on every AMD GPU under Linux's RADV
  driver, and on integrated Radeons under AMD's Windows driver. Native mesh shader draws reset
  RX 6000, 7000 and 9000 cards on RADV and time out the Radeon 780M (zortos293/Lichii#871, as in
  Fritchii v5.6; a player's Xbox Ally X fix first showed it here). Desktop Radeons on Windows keep
  the native path, which runs there. The first boot with the fallback builds its own shaders.
  EDEN_NX2_FORCE_MESH_FALLBACK=0 turns it off, =1 forces it on any GPU.

• About 1 GB less RAM in Ocarina: memory the game cleared to zero is given back to the system
  sooner (zortos293/Lichii#961 with Fritchii v5.6's faster page check).

• Ocarina runs faster: zortos293/Lichii#1161 by Lucas Borges is in (the game's GPU command
  stream waits less for itself, images are reused, reports are cheaper). On the test PC
  (i5-12600K, RX 6750 XT, no upscaler) Hyrule Field went from about 51 to 59 fps standing and
  from 43 to about 50 fps running around.

• Linux, AMD (RADV): GPU reset with "Illegal opcode in command stream" when the first
  tessellated terrain was drawn. The primitive topology set at draw time did not match the
  tessellation pipeline's patch list; Windows drivers let it pass. Not yet confirmed fixed on the
  reporter's machine.

• From the sister fork: Ocarina's periodic texture stalls on 10+ GB cards (#1129), the Castle
  Town guard house freeze (#976), the Song of Time crackle (#1073).

• .nx game archives load (upstream #923, #1078, #1127); right-click a game in the list and
  pick "Convert to NX..." to make one.

• A texture made where the memory collector had dropped an older one could start without its
  data (upstream #818's last fix): candidate for shadows and textures going wrong after a while.

• CheezyEmu has its own data folder: %APPDATA%\cheezyemu on Windows, and cheezyemu
  under ~/.config, ~/.local/share and ~/.cache on Linux. Eden, Lichii and Fritchii all share
  the eden folder, so their settings overwrote each other. The first start offers to import the
  old folder: "Keep Old Data" copies it (saves, settings, keys, mods and saved shaders), "Clear Old
  Data" moves it, "Link Old Directory" keeps sharing it. Saved shaders are kept unless you tick
  "Clear Shader Cache". (GitHub issue #1)

• Frame generation works again on AMD's newer drivers (docked and handheld). When AMD's
  FSR 4 frame generation started without all the functions CheezyEmu needs, build 10 gave up and
  frame generation stayed off; now it carries on, or falls back to the FSR 3.1 version.

• FSR presets work docked too. Docked (4K output) the sizes double: Native AA 3840x2160,
  Quality 2560x1440, Balanced 2250x1266, Performance 1920x1080, Ultra Performance 1280x720. In
  build 10 a docked preset turned FSR and frame generation off.

• Frame generation's Auto setting picks FSR 3.1 on cards that can't run FSR 4's (everything
  but the RX 9000 series). AMD's runtime offered FSR 4 frame generation to other cards too, where
  it never made a frame, so players had to pick FSR 3.1 by hand.

• No more blinding white lighting in Link's house and Kokiri Forest with "Switch 2 draws with
  unbuilt pipelines" on Skip or Bounded: those modes dropped the game's brightness measurement
  while its shader built, and the exposure stayed stuck until a reset. Draws like that always
  wait now.

• No more red flickering (an upstream change build 10 had taken out is back).

• Fewer freezes and black screens after cutscenes: two fixes from Lichii build 130 (GPU
  wait handling and its 32-region limit).

• "Closing software..." no longer freezes CheezyEmu. When a game gets stuck closing,
  CheezyEmu used to kill the stuck part, which could freeze the whole window until Task Manager
  ended it. Now it restarts itself instead (or just exits when you're quitting) and says so.

• FSR 4 black screen: when FSR 4 draws black (older AMD drivers), CheezyEmu notices sooner
  and switches to FSR 3.1. Updating the AMD driver fixes the cause.

• Crash reports: a crash now writes a crash dump to crash_dumps in the data folder and a
  line in the log saying where it happened. In Ocarina the log also says why FSR or frame
  generation didn't turn on.

• AMD FSR in the status bar and the performance overlay: an FSR button shows the version
  running (FSR 4.1.2, FSR 3.1.6) or why it isn't (OOT ONLY, RES 1X, WAITING, WINDOWS ONLY), like
  the frame generation one. The overlay shows both, so they're visible in fullscreen.

• Tools > Switch 2 Switches: checkboxes for the nx2_switches.txt switches players use most
  (semaphore mirror, GPU thread split, keep ASTC, build every shader at boot...).

• FSR presets fixed and docked output: Quality, Balanced and Ultra Performance start FSR and
  frame generation now (only Performance and Native did). Docked, "Ocarina of Time docked output"
  picks 4K or 1440p (lighter), and presets render a fraction of that output, as in PC games.

• FSR camera jitter (test): Tools > Switch 2 Switches > "FSR camera jitter". FSR rebuilds fine
  detail from a camera nudged by less than a pixel every frame; without it low presets look
  blocky. Off by default while it is tested: turn it off again if the picture shakes.

• Graphics that broke after a few minutes: a shader thrown out after 9,000 unused frames could
  be rebuilt wrong when it was needed again (from Lichii, not merged there yet).

• Performance: cheaper per-draw work on the GPU thread and fewer pointless texture uploads
  (Lichii #858, #910, #921, #1079).

• New icon (vector, sharp at any size).

• More fixes from L...

CheezyEmu TEST build test-2e700f5 (2e700f5)

Automatic build of test-2e700f5 at 2e700f5.

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

• Upstream Lichii's newest GPU work is merged (zortos293/Lichii nx2 up to #1056, without its
  shader cache v2, which would not carry over saved AMD pipelines and means a 30+ minute first
  boot). The two GPU threads take turns less: macros that read memory run on the second thread,
  command lists wait only for the work the console would wait for, and read-backs no longer hold
  the GPU thread. Ocarina of Time, Hyrule Field, i5-12600K + RX 6750 XT, no upscaler: about 45 to
  49-50 FPS, and the slowest frames drop from 42-51 ms to 24-29 ms (far fewer hitches).

• White flashes ("flashbang") and glowing triangles in Ocarina of Time: still open. One
  possible cause is closed: the game sizes its glare from occlusion query reports, and a report
  could reach it before the graphics card had finished the work it measures; upstream's fix for
  that (#337) is back. Players still see flashes after playing a while (restarting the game
  clears them), and the cause is not known yet. A second suspect, compute shaders writing past
  what the emulator tracks, was checked with an exact test over a thousand shader runs and not
  found; that test stays in as EDEN_NX2_EXTENT_CHECK=1. To help: set EDEN_NX2_FLASH_WATCH to
  a folder, play until it happens, and send that folder with the log.

• Out of video memory on 8 GB cards no longer ends in a crash (reports from an RX 5700 XT
  at 4K and 1440p with frame generation): when an image can't get memory, the 512 MiB of recycled
  images are released first and it is tried again, and a draw whose render target got no memory
  is skipped instead of crashing in the driver. Memory still runs short on those cards at high
  output sizes: use VRAM Usage Mode Conservative and a lower docked output if it happens.

• Status bar: Optical Flow and LSFG frame generation show the frames that reach the screen
  ("Game: 90 FPS (45 + FG)"), as AMD frame generation already did.

• FSR and frame generation switching off and on ("FSR (NO CAMERA)"): the log now says how
  many frames had no scene camera and why, so a report can be traced.

• Frame generation: Link no longer tears while he moves. Generated frames doubled and broke
  his limbs, sword and middle (ghost hands, torn boots) because only part of him was given
  motion of his own; the rest got the scenery's. Three causes, found by saving the generated
  frames and the motion they were made from: parts bound to a single bone per vertex (sword,
  scabbard, hat) were not recognised; his largest mesh keeps its pose in another slot than the
  rest; and two of his 282 bones and, in busy scenes, any character past the 64th were left out.
  Still open: his bare forearms and thighs in a fast sideways run.

• Fewer freezes on new ground. A shader the game needs for the first time was built with the
  whole frame held whenever its draw went to a target the game never clears, which is most of
  them: 8 to 51 ms each, and now and then over a second. Draws into targets used every frame are
  now left out for the few frames the shader takes instead (as was already done for cleared
  targets). Same fresh route in Hyrule Field: worst frame 97 ms instead of 1.1 to 1.7 s, no
  frame over 100 ms instead of three. Tiny targets (brightness measurement) always wait.
  EDEN_NX2_TRANSIENT_TARGETS=0 brings the old rule back.

• AMD GPU hangs and resets on Linux, and the handheld black screen after the opening
  cutscene: the mesh shader fallback is now used by itself on every AMD GPU under Linux's RADV
  driver, and on integrated Radeons under AMD's Windows driver. Native mesh shader draws reset
  RX 6000, 7000 and 9000 cards on RADV and time out the Radeon 780M (zortos293/Lichii#871, as in
  Fritchii v5.6; a player's Xbox Ally X fix first showed it here). Desktop Radeons on Windows keep
  the native path, which runs there. The first boot with the fallback builds its own shaders.
  EDEN_NX2_FORCE_MESH_FALLBACK=0 turns it off, =1 forces it on any GPU.

• About 1 GB less RAM in Ocarina: memory the game cleared to zero is given back to the system
  sooner (zortos293/Lichii#961 with Fritchii v5.6's faster page check).

• Ocarina runs faster: zortos293/Lichii#1161 by Lucas Borges is in (the game's GPU command
  stream waits less for itself, images are reused, reports are cheaper). On the test PC
  (i5-12600K, RX 6750 XT, no upscaler) Hyrule Field went from about 51 to 59 fps standing and
  from 43 to about 50 fps running around.

• Linux, AMD (RADV): GPU reset with "Illegal opcode in command stream" when the first
  tessellated terrain was drawn. The primitive topology set at draw time did not match the
  tessellation pipeline's patch list; Windows drivers let it pass. Not yet confirmed fixed on the
  reporter's machine.

• From the sister fork: Ocarina's periodic texture stalls on 10+ GB cards (#1129), the Castle
  Town guard house freeze (#976), the Song of Time crackle (#1073).

• .nx game archives load (upstream #923, #1078, #1127); right-click a game in the list and
  pick "Convert to NX..." to make one.

• A texture made where the memory collector had dropped an older one could start without its
  data (upstream #818's last fix): candidate for shadows and textures going wrong after a while.

• CheezyEmu has its own data folder: %APPDATA%\cheezyemu on Windows, and cheezyemu
  under ~/.config, ~/.local/share and ~/.cache on Linux. Eden, Lichii and Fritchii all share
  the eden folder, so their settings overwrote each other. The first start offers to import the
  old folder: "Keep Old Data" copies it (saves, settings, keys, mods and saved shaders), "Clear Old
  Data" moves it, "Link Old Directory" keeps sharing it. Saved shaders are kept unless you tick
  "Clear Shader Cache". (GitHub issue #1)

• Frame generation works again on AMD's newer drivers (docked and handheld). When AMD's
  FSR 4 frame generation started without all the functions CheezyEmu needs, build 10 gave up and
  frame generation stayed off; now it carries on, or falls back to the FSR 3.1 version.

• FSR presets work docked too. Docked (4K output) the sizes double: Native AA 3840x2160,
  Quality 2560x1440, Balanced 2250x1266, Performance 1920x1080, Ultra Performance 1280x720. In
  build 10 a docked preset turned FSR and frame generation off.

• Frame generation's Auto setting picks FSR 3.1 on cards that can't run FSR 4's (everything
  but the RX 9000 series). AMD's runtime offered FSR 4 frame generation to other cards too, where
  it never made a frame, so players had to pick FSR 3.1 by hand.

• No more blinding white lighting in Link's house and Kokiri Forest with "Switch 2 draws with
  unbuilt pipelines" on Skip or Bounded: those modes dropped the game's brightness measurement
  while its shader built, and the exposure stayed stuck until a reset. Draws like that always
  wait now.

• No more red flickering (an upstream change build 10 had taken out is back).

• Fewer freezes and black screens after cutscenes: two fixes from Lichii build 130 (GPU
  wait handling and its 32-region limit).

• "Closing software..." no longer freezes CheezyEmu. When a game gets stuck closing,
  CheezyEmu used to kill the stuck part, which could freeze the whole window until Task Manager
  ended it. Now it restarts itself instead (or just exits when you're quitting) and says so.

• FSR 4 black screen: when FSR 4 draws black (older AMD drivers), CheezyEmu notices sooner
  and switches to FSR 3.1. Updating the AMD driver fixes the cause.

• Crash reports: a crash now writes a crash dump to crash_dumps in the data folder and a
  line in the log saying where it happened. In Ocarina the log also says why FSR or frame
  generation didn't turn on.

• AMD FSR in the status bar and the performance overlay: an FSR button shows the version
  running (FSR 4.1.2, FSR 3.1.6) or why it isn't (OOT ONLY, RES 1X, WAITING, WINDOWS ONLY), like
  the frame generation one. The overlay shows both, so they're visible in fullscreen.

• Tools > Switch 2 Switches: checkboxes for the nx2_switches.txt switches players use most
  (semaphore mirror, GPU thread split, keep ASTC, build every shader at boot...).

• FSR presets fixed and docked output: Quality, Balanced and Ultra Performance start FSR and
  frame generation now (only Performance and Native did). Docked, "Ocarina of Time docked output"
  picks 4K or 1440p (lighter), and presets render a fraction of that output, as in PC games.

• FSR camera jitter (test): Tools > Switch 2 Switches > "FSR camera jitter". FSR rebuilds fine
  detail from a camera nudged by less than a pixel every frame; without it low presets look
  blocky. Off by default while it is tested: turn it off again if the picture shakes.

• Graphics that broke after a few minutes: a shader thrown out after 9,000 unused frames could
  be rebuilt wrong when it was needed again (from Lichii, not merged there yet).

• Performance: cheaper per-draw work on the GPU thread and fewer pointless texture uploads
  (Lichii #858, #910, #921, #1079).

• New icon (vecto...

CheezyEmu main build 11 (58ff7fb)

Automatic build of main at 58ff7fb.

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

• Upstream Lichii's newest GPU work is merged (zortos293/Lichii nx2 up to #1056, without its
  shader cache v2, which would not carry over saved AMD pipelines and means a 30+ minute first
  boot). The two GPU threads take turns less: macros that read memory run on the second thread,
  command lists wait only for the work the console would wait for, and read-backs no longer hold
  the GPU thread. Ocarina of Time, Hyrule Field, i5-12600K + RX 6750 XT, no upscaler: about 45 to
  49-50 FPS, and the slowest frames drop from 42-51 ms to 24-29 ms (far fewer hitches).

• White flashes ("flashbang") and glowing triangles in Ocarina of Time: still open. One
  possible cause is closed: the game sizes its glare from occlusion query reports, and a report
  could reach it before the graphics card had finished the work it measures; upstream's fix for
  that (#337) is back. Players still see flashes after playing a while (restarting the game
  clears them), and the cause is not known yet. A second suspect, compute shaders writing past
  what the emulator tracks, was checked with an exact test over a thousand shader runs and not
  found; that test stays in as EDEN_NX2_EXTENT_CHECK=1. To help: set EDEN_NX2_FLASH_WATCH to
  a folder, play until it happens, and send that folder with the log.

• Out of video memory on 8 GB cards no longer ends in a crash (reports from an RX 5700 XT
  at 4K and 1440p with frame generation): when an image can't get memory, the 512 MiB of recycled
  images are released first and it is tried again, and a draw whose render target got no memory
  is skipped instead of crashing in the driver. Memory still runs short on those cards at high
  output sizes: use VRAM Usage Mode Conservative and a lower docked output if it happens.

• Status bar: Optical Flow and LSFG frame generation show the frames that reach the screen
  ("Game: 90 FPS (45 + FG)"), as AMD frame generation already did.

• FSR and frame generation switching off and on ("FSR (NO CAMERA)"): the log now says how
  many frames had no scene camera and why, so a report can be traced.

• Frame generation stuck on "waiting" (reports from an RX 5700 XT): not fixed yet. The log
  now says once when the game's own upscaler can't be replaced on a card and what didn't fit,
  which is what frame generation waits for. Please send the log if you see it.

• Known issue: blocky, stair-stepped edges in water haze and in the shards of broken pots
  around Link in Ocarina of Time on AMD cards. It comes from the game's water and particle
  pass, not from FSR or frame generation; no fix yet.

• Frame generation: Link no longer tears while he moves. Generated frames doubled and broke
  his limbs, sword and middle (ghost hands, torn boots) because only part of him was given
  motion of his own; the rest got the scenery's. Three causes, found by saving the generated
  frames and the motion they were made from: parts bound to a single bone per vertex (sword,
  scabbard, hat) were not recognised; his largest mesh keeps its pose in another slot than the
  rest; and two of his 282 bones and, in busy scenes, any character past the 64th were left out.
  Still open: his bare forearms and thighs in a fast sideways run.

• Fewer freezes on new ground. A shader the game needs for the first time was built with the
  whole frame held whenever its draw went to a target the game never clears, which is most of
  them: 8 to 51 ms each, and now and then over a second. Draws into targets used every frame are
  now left out for the few frames the shader takes instead (as was already done for cleared
  targets). Same fresh route in Hyrule Field: worst frame 97 ms instead of 1.1 to 1.7 s, no
  frame over 100 ms instead of three. Tiny targets (brightness measurement) always wait.
  EDEN_NX2_TRANSIENT_TARGETS=0 brings the old rule back.

• AMD GPU hangs and resets on Linux, and the handheld black screen after the opening
  cutscene: the mesh shader fallback is now used by itself on every AMD GPU under Linux's RADV
  driver, and on integrated Radeons under AMD's Windows driver. Native mesh shader draws reset
  RX 6000, 7000 and 9000 cards on RADV and time out the Radeon 780M (zortos293/Lichii#871, as in
  Fritchii v5.6; a player's Xbox Ally X fix first showed it here). Desktop Radeons on Windows keep
  the native path, which runs there. The first boot with the fallback builds its own shaders.
  EDEN_NX2_FORCE_MESH_FALLBACK=0 turns it off, =1 forces it on any GPU.

• About 1 GB less RAM in Ocarina: memory the game cleared to zero is given back to the system
  sooner (zortos293/Lichii#961 with Fritchii v5.6's faster page check).

• 1 to 2 GB less RAM on AMD cards: the file of saved compiled shaders
  (vulkan_binaries) was read into memory whole and kept there for the session, 1.8 GB on the
  test PC; now each shader's part is read from the file when it is built. Same boot time. PCs
  with 16 GB of RAM are still tight in Ocarina at 4K: a large page file helps (a report of the
  whole PC freezing on the load from Castle Town to Hyrule Field came from one).

• Ocarina runs faster: zortos293/Lichii#1161 by Lucas Borges is in (the game's GPU command
  stream waits less for itself, images are reused, reports are cheaper). On the test PC
  (i5-12600K, RX 6750 XT, no upscaler) Hyrule Field went from about 51 to 59 fps standing and
  from 43 to about 50 fps running around.

• Linux, AMD (RADV): GPU reset with "Illegal opcode in command stream" when the first
  tessellated terrain was drawn. The primitive topology set at draw time did not match the
  tessellation pipeline's patch list; Windows drivers let it pass. Not yet confirmed fixed on the
  reporter's machine.

• From the sister fork: Ocarina's periodic texture stalls on 10+ GB cards (#1129), the Castle
  Town guard house freeze (#976), the Song of Time crackle (#1073).

• .nx game archives load (upstream #923, #1078, #1127); right-click a game in the list and
  pick "Convert to NX..." to make one.

• A texture made where the memory collector had dropped an older one could start without its
  data (upstream #818's last fix): candidate for shadows and textures going wrong after a while.

• CheezyEmu has its own data folder: %APPDATA%\cheezyemu on Windows, and cheezyemu
  under ~/.config, ~/.local/share and ~/.cache on Linux. Eden, Lichii and Fritchii all share
  the eden folder, so their settings overwrote each other. The first start offers to import the
  old folder: "Keep Old Data" copies it (saves, settings, keys, mods and saved shaders), "Clear Old
  Data" moves it, "Link Old Directory" keeps sharing it. Saved shaders are kept unless you tick
  "Clear Shader Cache". (GitHub issue #1)

• Frame generation works again on AMD's newer drivers (docked and handheld). When AMD's
  FSR 4 frame generation started without all the functions CheezyEmu needs, build 10 gave up and
  frame generation stayed off; now it carries on, or falls back to the FSR 3.1 version.

• FSR presets work docked too. Docked (4K output) the sizes double: Native AA 3840x2160,
  Quality 2560x1440, Balanced 2250x1266, Performance 1920x1080, Ultra Performance 1280x720. In
  build 10 a docked preset turned FSR and frame generation off.

• Frame generation's Auto setting picks FSR 3.1 on cards that can't run FSR 4's (everything
  but the RX 9000 series). AMD's runtime offered FSR 4 frame generation to other cards too, where
  it never made a frame, so players had to pick FSR 3.1 by hand.

• No more blinding white lighting in Link's house and Kokiri Forest with "Switch 2 draws with
  unbuilt pipelines" on Skip or Bounded: those modes dropped the game's brightness measurement
  while its shader built, and the exposure stayed stuck until a reset. Draws like that always
  wait now.

• No more red flickering (an upstream change build 10 had taken out is back).

• Fewer freezes and black screens after cutscenes: two fixes from Lichii build 130 (GPU
  wait handling and its 32-region limit).

• "Closing software..." no longer freezes CheezyEmu. When a game gets stuck closing,
  CheezyEmu used to kill the stuck part, which could freeze the whole window until Task Manager
  ended it. Now it restarts itself instead (or just exits when you're quitting) and says so.

• FSR 4 black screen: when FSR 4 draws black (older AMD drivers), CheezyEmu notices sooner
  and switches to FSR 3.1. Updating the AMD driver fixes the cause.

• Crash reports: a crash now writes a crash dump to crash_dumps in the data folder and a
  line in the log saying where it happened. In Ocarina the log also says why FSR or frame
  generation didn't turn on.

• AMD FSR in the status bar and the performance overlay: an FSR button shows the version
  running (FSR 4.1.2, FSR 3.1.6) or why it isn't (OOT ONLY, RES 1X, WAITING, WINDOWS ONLY), like
  the frame generation one. The overlay shows both, so they're visible in fullscreen.

• Tools > Switch 2 Switches: checkboxes for the nx2_switches.txt switches players use most
  (semaphore mirror, GPU thread split, keep ASTC, build every shader at boot...).

• FSR presets fixed and docked output: Quality, Balanced and Ultra Performance start FSR and
  frame generation now (only Performance and Native did). Docked, "Ocarina of Time dock...

CheezyEmu main build 10 (99e727d)

Automatic build of main at 99e727d.

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

• Now its own emulator: CheezyEmu. New name, new cheese icon, cheezyemu.exe. Saves, settings
  and shader caches stay where they were. In-app updates from build 9 can't find build 10 (the
  files have new names): download it once from the releases page.
• New look: the CheezyEmu theme (warm charcoal and cheese yellow, rounded buttons, yellow
  headers, menu and status bar lines) is the default. Players on the old default theme move to it
  once; any theme picked in Configure > General > UI sticks.
• Game pictures for every Switch 2 game, automatically: CheezyEmu downloads a picture list
  (dist/game_pictures.json, one SteamGridDB picture per Switch 2 title ID) and shows each game's
  picture with nothing to set up. Matching is by title ID, so it's the right game. The list is
  rebuilt every Monday by the game-pictures workflow from switchbrew's title list; a wrong
  picture is fixed in tools/game_pictures/overrides.json. A player's own SteamGridDB key (right-click
  a game > Game Picture > Find Picture Online) also finds pictures for games the list lacks.
  Right-click > Game Picture picks another picture, uses your own image or resets it.
• Handheld PCs (Steam Deck, ROG Ally): no more black screen in Ocarina when its anti-aliasing
  network can't be built on the GPU: CheezyEmu draws the game without it (as "No sharpening") and
  says so in the log.
• "What's new" after an update: the first start of a new build shows its changes once.
• AMD FSR & Frame Generation box at the top of Graphics (and in each game's settings): FSR 4,
  Ocarina's anti-aliasing and every frame generation option in one place.
• Stopping a game: each shutdown step is logged, so a stuck stop shows where it hung. If the
  game still has to be forced to stop, CheezyEmu asks you to restart it before playing again (a
  stuck game kept its memory and broke the next launch).
• GPU crash reports: when the GPU crashes, the log now says what CheezyEmu was doing (4K mode,
  FSR version and sizes, frame generation), and on Linux how to capture the hang (RADV_DEBUG=hang).
• Updates install themselves from now on: when a newer build is out, CheezyEmu offers it at
  startup, downloads it, closes, installs and restarts (Windows zip and Linux AppImage).
• FSR presets for Ocarina of Time (Properties > Graphics > AMD FSR & Frame Generation): Native
  AA (the 3D scene at 1920x1080, FSR as anti-aliasing), Native (the game's 1440x810), Quality
  1280x720, Balanced 1125x633, Performance 960x540 and Ultra Performance 640x360, at 1080p. The
  game itself renders at that size (its own resolution code, patched at load), FSR upscales it and
  frame generation works on every preset. The HUD stays sharp and saved shaders still apply.
• First start of build 10 takes longer once: the white-fog fix changes about 2,500 of
  Ocarina's shaders, which are compiled again and saved (around 15 minutes on an RX 6750 XT).
  Later starts are as fast as before.
• White fog fixed (Hyrule Field drawbridge solid white, lines in Kokiri Forest's fog): reverts
  the perspective-correct interpolation of zortos293/Lichii#820, as Fritchii v5.1 did. It was also
  suspected in an RX 6600 crash at boot. The faint red line in the Royal Family's Tomb may return.
• No more stale vertices (glowing or misplaced geometry in Hyrule Field and the graveyard):
  reverts the 32-byte rounding half of zortos293/Lichii#700, as Fritchii v5.1 did.
• FSR 4 that draws black switches to FSR 3.1 by itself. For a few seconds after a game starts,
  CheezyEmu checks FSR 4's output against the game's picture; if FSR 4 keeps drawing black (seen on
  an RX 9070 XT with driver 2.0.406), it changes to FSR 3.1 for the session and says so in the log.
  Updating the graphics driver should bring FSR 4 back.
• Less memory while shaders precache: a compute shader's IR is freed before the driver compiles
  it (zortos293/Lichii#878).
• Faster NUP loading: NUP archives are decoded only as far as the game reads
  (zortos293/Lichii#885).
• Microphone: a microphone that can't open no longer breaks the game; it hears silence
  (zortos293/Lichii#881).
• In-app updates retry a download up to three times on a GitHub server error (from Fritchii).
• The "Available VRAM" log line names Conservative mode's cap only when it lowered the figure.
• The game list no longer offers "Submit compatibility report" (that website is the upstream
  project's).

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).

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.