This is the whole MacLauncher website (https://procrastinine.github.io/maclauncher/) as Markdown. https://procrastinine.github.io/maclauncher/llms.txt lists every page and the reference documentation. --- # MacLauncher > Play games on macOS through native runtimes, with a Metal graphics and effects layer and tools for tinkering. MacLauncher is a native runtime system, graphics/effects layer, and tinker tool for playing games on macOS. Web page: https://procrastinine.github.io/maclauncher/ - [Get started](https://procrastinine.github.io/maclauncher/getting-started.md) - [MacLauncher for Apple Silicon Macs](https://github.com/procrastinine/maclauncher/releases/latest/download/MacLauncher.app.zip) - [MacLauncher for Intel Macs](https://github.com/procrastinine/maclauncher/releases/latest/download/MacLauncher-Intel.app.zip) - [Whole site as Markdown](https://procrastinine.github.io/maclauncher/llms-full.txt) The demo below runs the launcher's interface in your browser, with a library of example games. Each button shows what it would do, along with the article that explains it. [Try the interactive demo](https://procrastinine.github.io/maclauncher/demo/): the real launcher interface on example games, where every button explains what it would do. ## What it does **[Native runtimes](https://procrastinine.github.io/maclauncher/games.md)** Many Windows games are built on engines that also run on macOS. MacLauncher detects the engine and version, fetches a macOS runtime for it, and plays the game natively. It also runs Android, iOS, PS5 and Switch games without emulation. **[Graphics and effects](https://procrastinine.github.io/maclauncher/graphics.md)** Upscalers, frame generation, neural models and any ReShade, RetroArch or mpv shader, stacked in any order and changed live, for every runtime. **[Tinker tools](https://procrastinine.github.io/maclauncher/tools.md)** Download any version you own from Steam, GOG, Epic, itch.io and Google Play. Snapshot and edit saves, use cheats, and decompile most engines. **[Files and network](https://procrastinine.github.io/maclauncher/help/faq.md#does-it-change-my-game-files)** Original files are never modified, every runtime is versioned, and nothing goes online unless you ask. *Image: The MacLauncher library with a game selected, its inspector showing runtime and graphics settings.* ## Start exploring - [What is MacLauncher?](https://procrastinine.github.io/maclauncher/introduction.md): The longer introduction. - [How games run on a Mac](https://procrastinine.github.io/maclauncher/background/how-games-run.md): VMs, emulators, WINE and native runtimes, explained. - [Games and runtimes](https://procrastinine.github.io/maclauncher/games.md): Everything MacLauncher can play, by game type, and the runtimes that play it. - [Graphics and effects](https://procrastinine.github.io/maclauncher/graphics.md): Shaders, upscaling and frame generation, with examples. --- # What is MacLauncher? > A native runtime system, a graphics and effects layer, and a tinker tool for playing games on macOS. Web page: https://procrastinine.github.io/maclauncher/introduction/ MacLauncher plays games on macOS. It has three parts: a native runtime system, a graphics and effects layer, and a set of tools for tinkering with your games. Each part can be used on its own or with the others. *Image: The MacLauncher library with a game selected, its inspector showing runtime and graphics settings.* *The Android version of [Shattered Pixel Dungeon](https://github.com/00-Evan/shattered-pixel-dungeon), running with [CRT Royale](https://github.com/akgunter/crt-royale-reshade) shaders.* ## A native runtime system Many games packaged for Windows don't need Windows at all. They are built on engines such as [Ren'Py](https://www.renpy.org/), [RPG Maker](https://www.rpgmakerweb.com/), [Godot](https://github.com/godotengine/godot) or [GameMaker](https://gamemaker.io/), and those engines, or faithful open-source reimplementations of them, run natively on macOS. The Mac version of the engine can read the game's data directly, so the game runs without [WINE](https://www.winehq.org/) and without emulation. Doing that by hand means identifying the engine, finding a build of the exact version the game needs and configuring it. MacLauncher automates these steps. When you drag in a game folder or `.exe`, it detects the engine and its version, picks the runtime most likely to work, downloads it when you press Play, and launches the game. You can always choose a different runtime or version yourself. Even if you have [CrossOver](https://www.codeweavers.com/crossover/), a native runtime is usually the better way to play. No translation layer sits between the game and your Mac, so it runs faster and uses less power. Windows, fullscreen, mouse input and audio behave the way macOS expects, without the occasional oddities of WINE. A game whose own Mac build fails to open because of signing or packaging problems can often still be played, because a working runtime reads the same game data. Runtimes aren't limited to Windows games. Android and iOS apps, PlayStation 5 and Nintendo Switch games, DOS games, 32-bit Mac apps, Flash, Java and dozens of visual-novel engines have them too. For Windows games with no native option, MacLauncher manages [Sikarugir](https://github.com/Sikarugir-App/Sikarugir), a free distribution of WINE, and can also use your own copy of CrossOver. Ports of individual games from [decompilation and recompilation projects](https://procrastinine.github.io/maclauncher/help/faq.md#what-about-decompilation-and-recompilation-ports), mostly older console games, are a different kind of project, and their macOS builds can be dragged in like any other Mac app. [How games run on a Mac](https://procrastinine.github.io/maclauncher/background/how-games-run.md) explains the ideas behind these runtimes, and [Games and runtimes](https://procrastinine.github.io/maclauncher/games.md) shows what's supported. ## A graphics and effects layer MacLauncher has its own graphics pipeline, built natively on [Metal](https://developer.apple.com/metal/), and it works with every runtime: native engines, WINE games, Android apps, consoles, videos and ordinary Mac apps. You can stack effects in any order and change them while the game runs. The effects include: - spatial and temporal upscalers, from [MetalFX](https://developer.apple.com/documentation/metalfx) and [AMD FSR](https://github.com/GPUOpen-LibrariesAndSDKs/FidelityFX-SDK) to neural upscalers such as [Real-ESRGAN](https://github.com/xinntao/Real-ESRGAN); - frame generation, including a macOS port of [Lossless Scaling](https://store.steampowered.com/app/993090/Lossless_Scaling/)'s, which uses your own copy of the app; - neural reconstruction and restoration; - any [ReShade](https://reshade.me/), [RetroArch](https://www.retroarch.com/), [mpv](https://mpv.io/)/[libplacebo](https://libplacebo.org/), [Magpie](https://github.com/Blinue/Magpie) or [ISF](https://isf.video/) shader you import, such as CRT effects, color grading, anti-aliasing and depth effects. A single chain can render a game at 720p, pass it through a neural model, upscale it to 4K, add frame generation and finish with a CRT filter, and you can edit every step while you play. [Graphics and effects](https://procrastinine.github.io/maclauncher/graphics.md) has examples of each kind of effect. ## A tinker tool MacLauncher also has tools for working with the games on your disk: - Keep several versions of any runtime and choose one for each game. - Download the games you own from [Steam](https://store.steampowered.com/), [Epic](https://store.epicgames.com/), [GOG](https://www.gog.com/), [itch.io](https://itch.io/) and [Google Play](https://play.google.com/store/games) in the platform and version you choose, such as the Windows build of a Steam game or an older release. - Use save snapshots and editors, cheats for RPG Maker and Ren'Py, and decompilers and extractors for most game types. - Change any runtime option, add your own launch arguments, and turn network access on or off for each game. MacLauncher doesn't phone home or make requests in the background; every network request comes from something you did. The one exception is opt-in: turn on **Check for updates at launch** in Settings and it looks for a new version each time it starts. That setting is off by default. [Tinker tools](https://procrastinine.github.io/maclauncher/tools.md) describes all of these. ## Open source MacLauncher is open source under the [MIT license](https://github.com/procrastinine/maclauncher/blob/master/LICENSE), and it builds on many other open-source projects, which are credited in the [attributions](https://procrastinine.github.io/maclauncher/reference/ATTRIBUTIONS.md). Runtime builds that need adapting for macOS live in the companion project [MacLauncher Builds](https://github.com/procrastinine/maclauncher-builds). To install MacLauncher and play your first game, see [Getting started](https://procrastinine.github.io/maclauncher/getting-started.md). --- # Getting started > Download MacLauncher for an Apple Silicon or Intel Mac, get it past Gatekeeper, import your first game and press Play. Web page: https://procrastinine.github.io/maclauncher/getting-started/ MacLauncher needs a Mac running macOS 13 or later, with either Apple Silicon or an Intel processor. Some runtimes need more: Android and iOS games need Apple Silicon, and a few runtimes need a newer macOS (the PlayStation 5 runtime and some Android runtimes need macOS 26, for example). MacLauncher tells you when that's the case, and [Macs and macOS versions](https://procrastinine.github.io/maclauncher/macs-and-macos.md) lists what works where. > **Look around first:** > The [interactive demo](https://procrastinine.github.io/maclauncher/demo/) runs the real MacLauncher interface in your browser, with a library of example games. Every button explains what it would do and links to the article about it. ## 1. Download MacLauncher comes in two builds, one for each kind of Mac processor: [Apple Silicon](https://github.com/procrastinine/maclauncher/releases/latest/download/MacLauncher.app.zip) and [Intel](https://github.com/procrastinine/maclauncher/releases/latest/download/MacLauncher-Intel.app.zip). **Apple menu → About This Mac** shows which one your Mac has: a Chip line means Apple Silicon, and a Processor line means Intel. Both links always download the latest release. Unzip the download and drag MacLauncher.app into your **Applications** folder. Earlier versions and release notes are on the [Releases page](https://github.com/procrastinine/maclauncher/releases). Both versions of the app share one library, one set of settings and the same installed runtimes, and each downloads runtimes built for its own processor. The Intel app keeps choosing Intel builds even when it runs on an Apple Silicon Mac through Rosetta. If you need a runtime built for the other processor, [Runtimes](https://procrastinine.github.io/maclauncher/tools/versions-and-settings.md#processor-builds) has it. There's no separate download for each macOS version. On an older macOS, or on a GPU that lacks a feature, MacLauncher switches off only the graphics effects that need it, and the rest keep working. The app is small because game engines aren't bundled with it; MacLauncher downloads the ones you need when you need them. ## 2. Allow it through Gatekeeper [Gatekeeper](https://support.apple.com/guide/security/gatekeeper-and-runtime-protection-sec5599b66df/web) is the part of macOS that checks apps before they open. MacLauncher is ad-hoc signed rather than signed with a paid Apple Developer ID, so the first time you open it, macOS refuses and says it can't verify the developer. To allow it: 1. Double-click MacLauncher.app once and dismiss the warning. 2. Open **System Settings → Privacy & Security**. 3. Scroll down to the message about MacLauncher and click **Open Anyway**. 4. Confirm with your password or Touch ID. After that it opens like any other app. Apple's guide [Open a Mac app from an unknown developer](https://support.apple.com/en-us/102445) shows the same steps with screenshots. > **Note:** > MacLauncher also runs from source and behaves the same way. The [development guide](https://procrastinine.github.io/maclauncher/reference/development/DEVELOPMENT.md) explains how to build it. ## 3. Add a game There are three ways to bring a game into your library: - Drag a game folder or file onto the library window. - Use **File → Open…** (`⌘O`) or **Add game…** in the toolbar. - In Finder, right-click a game and choose **Open With → MacLauncher**. Usually you add the whole game folder or the game's main executable. MacLauncher also accepts packages directly: `.exe`, `.app`, `.apk`, `.ipa`, `.jar`, `.swf`, `.love`, Switch `.nsp`/`.xci` files, PS5 game folders, DOS programs, videos and more. Installers and self-extracting archives often work too, because MacLauncher can unpack the common ones. On import, MacLauncher reads the files to work out the game's [game type](https://procrastinine.github.io/maclauncher/background/choosing-a-runtime.md#game-types-and-runtimes) (the engine or platform it was made for), the engine version, and which runtime can play it on macOS. Your original files stay where they are. ## 4. Look around the inspector Click a game to open its **inspector** on the right, where everything about that game lives: - **Runtime and version** show what will run the game and which installed version it uses. The default is usually the right one; [Choosing a runtime](https://procrastinine.github.io/maclauncher/background/choosing-a-runtime.md) explains when to change it. - **Runtime Settings** holds options for that runtime, such as window size, language, controls or launch flags. These override the global defaults from **Settings** for this game only. - **Graphics** adds shaders, upscaling, frame generation and more. See [Graphics and effects](https://procrastinine.github.io/maclauncher/graphics.md). - **Tools** has saves, cheats, decompilers and extractors, depending on the game type. See [Tinker tools](https://procrastinine.github.io/maclauncher/tools.md). - **Network access** is a per-game switch that can cut the game off from the Internet and your local network. ## 5. Press Play Click **Play**. If the game's runtime isn't installed yet, MacLauncher asks before downloading it, installs it, and then prepares and launches the game without further clicks. Some games take longer the first time while MacLauncher prepares them, for example by converting files, compiling shaders or setting up a private Windows environment. Later launches reuse that work. **Stop** ends the game from the launcher if you need to. ## Good to know - **Runtimes**, **Settings**, **External** and **Credits** each open in their own window, so you can keep them next to the library or the game. - **Create shortcut…** in the inspector saves a small launcher file. Double-click it to start that game with its current settings, without opening the library. - **Forget** removes a game from the library and deletes MacLauncher's private data for it: generated files, caches and the saves it keeps in its own storage. The game's original files are never touched. - MacLauncher's own data, including installed runtimes, lives in `~/Library/Application Support/maclauncher/`. To learn more, read [how games run on a Mac](https://procrastinine.github.io/maclauncher/background/how-games-run.md), browse the [supported games and runtimes](https://procrastinine.github.io/maclauncher/games.md), or go straight to [graphics and effects](https://procrastinine.github.io/maclauncher/graphics.md). --- # Macs and macOS versions > Which Macs and macOS versions MacLauncher runs on, which features need Apple Silicon or a newer macOS, and how MacLauncher picks Apple Silicon or Intel builds. Web page: https://procrastinine.github.io/maclauncher/macs-and-macos/ This page explains which Macs MacLauncher runs on and what differs from one Mac to another. MacLauncher runs on any Mac with macOS 13 or later, whether it has an Apple Silicon or an Intel processor, and almost all of it works the same on every one of them. A few runtimes need Apple Silicon, and some graphics features need a newer macOS or a particular graphics chip. On a Mac without them, MacLauncher switches off only what can't run and explains why, while everything else keeps working. ## Two kinds of processor Every Mac has one of two kinds of processor. Apple Silicon Macs, from the first M1 models on, run programs built for ARM64 processors, and Intel Macs run programs built for Intel's x86-64 processors. An Apple Silicon Mac can also run Intel programs through [Rosetta](https://support.apple.com/en-us/102527), Apple's translator, at some cost in speed. A program that contains both versions is called universal, and it runs natively on either kind of Mac. MacLauncher therefore comes as two apps, one for each kind of processor. The download buttons on this site offer the right one for the Mac that's visiting, and [Getting started](https://procrastinine.github.io/maclauncher/getting-started.md#1-download) links both. The two apps share one library, one set of settings and the same installed runtimes, so moving from one to the other loses nothing. ## How MacLauncher picks a build Many runtimes are published for both processors, and MacLauncher picks between them automatically. Each app downloads the builds made for its own processor, and a universal build serves either app. When a runtime version has no Apple Silicon or universal build, the Apple Silicon app uses its Intel build through Rosetta, and **Play** offers to install Rosetta if it isn't there yet. The Intel app keeps choosing Intel builds even when it runs on an Apple Silicon Mac through Rosetta. The automatic choice can be changed in **Runtimes**: - When a runtime has builds for both processors and the Mac can run both, a **Build** menu above its version list shows the other processor's versions. An Intel Mac lists only Intel builds, since it can't run the others. - Builds for both processors can be installed side by side. One made for the other processor carries an **Intel** or **Apple Silicon** tag. - **Set default** on such a build makes it that runtime's default, so games that don't ask for anything else use it. Some code has to match the game it works with, whatever the default. A library that MacLauncher loads into a game, such as part of the graphics layer, always matches the game's own processor. Separate helper programs can differ: neural effects, for example, run in an Apple Silicon helper even for an Intel game running through Rosetta. [Versions and settings](https://procrastinine.github.io/maclauncher/tools/versions-and-settings.md#processor-builds) shows the Runtimes window, and [Processor builds](https://procrastinine.github.io/maclauncher/reference/runtimes/README.md#processor-builds) in the reference documentation describes these rules in full. ## Runtimes that care about the processor Many runtimes have builds for both processors, or a universal build, and work the same on any Mac. Some depend on the processor: - [Android, iPhone and iPad, and Nintendo Switch games](https://procrastinine.github.io/maclauncher/games/mobile-and-consoles.md) run their original ARM code directly on the Mac's processor, so they need an Apple Silicon Mac. - The WINE runtimes, [Sikarugir and CrossOver](https://procrastinine.github.io/maclauncher/games/windows.md), run Windows games as Intel programs, which use Rosetta on Apple Silicon. - The [32-bit Mac runtime](https://procrastinine.github.io/maclauncher/games/more.md#32-bit-mac-apps), the [HashLink](https://procrastinine.github.io/maclauncher/games/more.md#hashlink-and-haxe) virtual machine, PlayStation 5 games and Java 8 also run Intel code, through Rosetta on Apple Silicon. Each runtime version also has its own minimum macOS version. MacLauncher learns it, together with the processors a version supports, from the publisher's release information or from the downloaded files themselves, and a version that a Mac can't run stays in the list with the reason. Because versions come from each runtime's own publisher, a newer release can need a newer macOS than an older one. ## Graphics features by macOS version The [graphics layer](https://procrastinine.github.io/maclauncher/graphics.md) runs on Apple Silicon and Intel Macs from macOS 13. Some of its features rely on technology that Apple added in later macOS versions or offers only on Apple Silicon, so they become available as a Mac's macOS gets newer: - [MetalFX](https://developer.apple.com/documentation/metalfx) is Apple's own upscaling, denoising and frame interpolation. MacLauncher asks each Mac's graphics chip which MetalFX operations it supports, including Intel and AMD GPUs. - [VideoToolbox interpolation](https://procrastinine.github.io/maclauncher/graphics/frame-generation.md#videotoolbox-interpolation) is a frame-generation method built into macOS. macOS reports on each Mac whether it supports it, and Apple doesn't publish a list of the Macs that do. - [Metal 4](https://developer.apple.com/metal/) is the newest version of Apple's graphics interface, which some effects build on. - [MLX](https://github.com/ml-explore/mlx) runs neural models on Apple Silicon, for neural restoration and interpolation, and [FSR 4.1](https://procrastinine.github.io/maclauncher/graphics/upscaling.md#fsr-temporal) is AMD's machine-learning upscaler. - [libplacebo](https://libplacebo.org/) and [ISF](https://isf.video/) are shader formats that MacLauncher prepares and runs on Metal. - DXMT and D3DMetal translate the Direct3D graphics of Windows games to Metal, and KosmicKrisp is a Vulkan driver for Apple Silicon. All three serve [WINE games](https://procrastinine.github.io/maclauncher/games/windows.md#runtime-settings). This table lists each feature under the earliest macOS version that supports it, and every later macOS keeps it. Features under **Macs that report support** run where the Mac's graphics chip or macOS reports that it can run them: | macOS | Every Mac | Macs that report support | Apple Silicon only | | --- | --- | --- | --- | | 13 | Shared graphics effects, libplacebo filters and shader compilation, ISF shaders | MetalFX spatial scaling, MetalFX temporal scaling | None | | 14 | Video export | DXMT, Sikarugir DXMT | MLX neural restoration and interpolation, D3DMetal, Temporal upscaling in Windows games, MLX neural processing | | 15 | None | None | FSR 4.1 | | 15.2 | Window graphics | Window graphics | None | | 26 | None | MetalFX denoised scaling, MetalFX frame interpolation, MetalFX image interpolation, VideoToolbox low-latency interpolation | Metal 4, KosmicKrisp, Vulkan renderers for Windows games, Neural video decoding and encoding | | 26.4 | None | None | Sikarugir D3DMetal | | 27 | None | MetalFX distortion and previous-color inputs | None | A selected package can need a newer macOS than its feature's minimum, and effects such as temporal upscaling also need information from the game's renderer. When a feature can't run, MacLauncher switches off only the effects that use it, and the rest of an effect chain keeps working. [System requirements](https://procrastinine.github.io/maclauncher/reference/runtimes/SYSTEM_REQUIREMENTS.md) is the complete reference, including the processor and macOS version of each component that ships with the app. --- # The launcher > MacLauncher's game library on the Mac: search, filters and sorting, selecting several games, and every part of a game's inspector. Web page: https://procrastinine.github.io/maclauncher/launcher/ MacLauncher is a Mac app with one main window, the **library**, which holds a list of your games on the left and the **inspector** for the selected game on the right. Settings, Runtimes, External and Credits each open in their own window. ## The library The library opens straight away with the details MacLauncher saved last time, and each game is checked again in the background. A game whose files haven't changed reuses what MacLauncher already knows about it, and a slow game doesn't hold up the list or other imports. Selecting a game moves its checks to the front of the queue, and its last known details stay on screen until the new result arrives. [Library loading](https://procrastinine.github.io/maclauncher/reference/library/GAME_PREPARATION.md#library-loading) describes how those updates work. ### Adding games **Add game…** opens a file picker for game folders and launchable files such as `.app`, `.exe`, `.jar`, `.swf` and `.love`. You can also drag folders and files onto the window, including Android `.apk` packages and iOS `.ipa` archives. MacLauncher detects what kind of game each one is and adds it to the library. Several games dragged in at once import as one batch, with **Adding N of M** and a progress bar. A failed item doesn't stop the rest. The summary lists each item that didn't import with the reason, a **Choose game file…** button and **Retry**. The same drop target accepts shaders (`.fx`, `.glsl`, `.hook`, `.slang`, `.slangp`) and neural models (`.dlssmodel`). Shaders join the [shader library](https://procrastinine.github.io/maclauncher/graphics/shaders.md#the-shader-library) and models join the [model library](https://procrastinine.github.io/maclauncher/graphics/neural-restoration.md#getting-models) instead of the game list. ### Search, filters and sorting A toolbar above the list filters and sorts it: - **Search** (Cmd+F) matches titles and paths as you type. - **Game types** shows or hides whole kinds of game, such as [RPG Maker](https://www.rpgmakerweb.com/) MV, [Ren'Py](https://www.renpy.org/) or Nintendo Switch. A game is listed under its game type whichever runtime plays it, so Prosper games, for example, appear under PlayStation 5. - **Show games** picks All games, Favorites or Running. - **Sort** orders the list by Default, Last played, Date added, Alphabetical or Game type, with a button to reverse the direction. Your sort and favorites are remembered between launches. Searching and filtering never change the order you've arranged by hand. ### Favorites and order A star beside each game marks it as a favorite. In the **Default** sort, favorites sit together at the top, and you can drag games into any order with the handle or move the selected game with Option-Up and Option-Down. New games arrive at the top of the list, just below the favorites, and playing a game doesn't move it. ### Selecting several games **Select** turns the list into checkboxes. Shift-click selects a range, and Cmd+A selects every visible game. A selection offers these actions: - **Forget selected** removes the games from the library and deletes MacLauncher's own data for them. The game files stay where they are. - **Move to Trash…** also moves the games' files to the Trash. - **Select all missing** checks the visible games on disk and selects the ones whose files are gone, ready to forget. **Detect all missing** marks them without selecting them. Games on an unplugged drive count as missing too, so connect your drives first if you only want to clear out games you've deleted. Both removals ask once in a macOS dialog first. ### Each row Every row shows the game's name, game type, last-played time and path. A **runtime** tag appears when the game uses a runtime other than its game type's default, and **Modified** appears when that runtime's settings differ from the defaults. A save label shows whether the game uses a custom save folder. **Play**/**Stop**, **Shortcut** and **Forget** work directly from the row, without opening the inspector. When a game's files can't be found, its row says **Unavailable** and its icon is dimmed; hover over the label to see why. When looking for a Windows game's icon in a folder, MacLauncher skips installers and crash reporters and tries the game before configuration tools or launchers. A packaged game whose file name looks like an installer's can still supply its own artwork. ### Games on an external drive Games are big, so many people keep them on an external drive that isn't always plugged in. When a game's files aren't on disk, because the drive is disconnected or the folder has moved, MacLauncher leaves the game exactly as it was. It stays in the library with its saves, settings, runtime versions, snapshots and effects. Nothing is detected again, rebuilt or deleted, and MacLauncher doesn't go looking through the missing folder. An icon kept in a game's folder appears once MacLauncher has checked that the files are available. While a game is unavailable, **Play** explains why it can't start, and patches and tools that need the game's files are switched off. Favorites, notes, launch arguments, runtime choices and settings, network access, effects and **Forget** still work. Saves that MacLauncher keeps in its own storage stay usable, while saves stored inside the game folder wait for the drive. When the drive comes back at the same location, the game is ready again, with no restart or new import. MacLauncher notices the next time you switch to its window, press **Play** or use **Detect all missing**, and then refreshes the game's details as it does at startup. If the drive disappears while a game is running and the game stops, MacLauncher keeps running and tells you the game's files became unavailable. If a game has moved for good, to another folder or another drive, press **Locate…** beside the **Files unavailable** notice in the game's inspector and choose the new location. MacLauncher checks that the game there is the same kind of game, then points the library entry at it. The game keeps its saves, snapshots, settings, notes, favorite, runtime choices and effects, and shortcuts you saved for it keep opening it. A location without a game of the same kind, or one that another library entry already uses, is refused with the reason, and the entry stays as it was. [Unavailable game files](https://procrastinine.github.io/maclauncher/reference/library/GAME_PREPARATION.md#unavailable-game-files) has the full rules, including [what Locate… updates](https://procrastinine.github.io/maclauncher/reference/library/GAME_PREPARATION.md#locating-moved-files). ## The inspector Click a game to open its inspector, and click it again to close it. The inspector's sections always come in the same order, and a section appears only when the game has something to show in it. ### Files - **Game** shows where the game is, with a folder button that reveals it in Finder. - Some game types add a launch choice here. Videos, for example, have **Video**, which picks the playlist entry that plays first. - **Saves** shows the save folder, with **Change** to point the game at another folder and **Reset** to go back to the default. Saves kept inside MacLauncher's own storage read **Managed by MacLauncher**. - **Remove quarantine** appears for imported Mac apps that macOS refuses to open because they were downloaded. - **Detection** holds the detected format, where the version came from, how confident the detection is, and the full detection trace. ### Launch This section holds the runtime, its version and settings, launch arguments, network access and, for [Steam](https://store.steampowered.com/) games, whether to start the Steam client. [Per-game choices](https://procrastinine.github.io/maclauncher/tools/versions-and-settings.md#per-game-choices) describes each one. **Play** prepares and starts the game. While it prepares, **Cancel** stops the launch, and **Stop** is available as soon as the game's process starts. If the selected runtime can only inspect a game, the inspector explains why in place of Play and keeps the inspection tools. ### Patches Some game types support reversible patches to the game's files. RPG Maker MV games can swap in an updated graphics library, and games with in-game cheat tools can have those tools injected. Each patch shows its status (Not patched, Patched or Partial) with **Patch** and **Unpatch** buttons, and asks before changing anything. ### Tools This section holds the game type's own tools, such as extractors, decompilers, plugin installers, app builders and video export. Each group shows its main action first, with related actions under **More…**, and results appear right below. See [Decompilers and extractors](https://procrastinine.github.io/maclauncher/tools/decompilers-and-extractors.md) and [Saves and cheats](https://procrastinine.github.io/maclauncher/tools/saves-and-cheats.md). ### Graphics This section holds the game's effect chain. While the section is closed, its heading summarizes the active effects. See [Graphics and effects](https://procrastinine.github.io/maclauncher/graphics.md). ### Notes Notes are plain text of your own, kept with the game in the library. **Save notes** or Cmd-S saves them, and so does clicking elsewhere. Notes are deleted when the game is forgotten. ## Windows and menus - **Settings** (Cmd+,) holds preferences: appearance, defaults and each game type's runtime settings. See [Settings](https://procrastinine.github.io/maclauncher/tools/versions-and-settings.md#settings). - **Runtimes** installs and manages versions of every runtime, tool and graphics component. See [Runtimes](https://procrastinine.github.io/maclauncher/tools/versions-and-settings.md#the-runtimes-window). - **External** finds games installed from stores and downloads ones you own. See [Stores and downloads](https://procrastinine.github.io/maclauncher/tools/stores-and-downloads.md). - **Credits** lists every project MacLauncher builds on, with links. See [Credits](https://procrastinine.github.io/maclauncher/about/credits.md). Each window opens once, and opening it again brings the existing window forward. Closing the library leaves the other windows open, and the Dock icon or **View → Library** brings it back. **Help → Show Log in Finder** reveals MacLauncher's log for troubleshooting. The [UI guide](https://procrastinine.github.io/maclauncher/reference/development/UI_GUIDE.md) describes every control in full, including the [library](https://procrastinine.github.io/maclauncher/reference/development/UI_GUIDE.md#library) and the [inspector](https://procrastinine.github.io/maclauncher/reference/development/UI_GUIDE.md#inspector). --- # How games run on a Mac > Virtual machines, emulators, compatibility layers like WINE, and native runtimes on a Mac: what each one does, and why MacLauncher prefers the last two. Web page: https://procrastinine.github.io/maclauncher/background/how-games-run/ If you have tried to play a Windows game on a Mac, you have probably met a pile of terms: *[virtual machine](https://en.wikipedia.org/wiki/Virtual_machine)*, *[emulator](https://en.wikipedia.org/wiki/Emulator)*, *[WINE](https://www.winehq.org/)*, *[CrossOver](https://www.codeweavers.com/crossover/)*, *[Rosetta](https://support.apple.com/en-us/102527)*, *port*. They all get a game running somewhere it wasn't built for, but they work in very different ways, and those differences decide how fast the game runs, how well it behaves and what can go wrong. There are four main approaches, from the heaviest to the lightest, plus a fifth that rebuilds the game itself. MacLauncher uses the lightest approach that works for each game, which explains most of its design. ## What a game actually needs A game is a program, and a program expects three things from the machine it runs on. The first is a CPU that understands its instructions. Compiled code is a list of instructions for one processor family: [x86-64](https://en.wikipedia.org/wiki/X86-64) for most Windows PCs and the PlayStation 5, and [ARM64](https://en.wikipedia.org/wiki/AArch64) for [Apple Silicon](https://en.wikipedia.org/wiki/Apple_silicon), phones and the Nintendo Switch. Macs come with either kind: older ones with Intel x86-64 processors, newer ones with Apple Silicon. Both can run native engines, and Apple's Rosetta translator lets Apple Silicon run many Intel programs as well. Runtimes that run the ARM64 code of Android, iOS or Switch games directly need Apple Silicon. A Universal Mac download contains code for both processors, though some graphics features still work on only one of them. The [requirements reference](https://procrastinine.github.io/maclauncher/reference/runtimes/SYSTEM_REQUIREMENTS.md) gives these details for each component. The second is an operating system. Games ask the OS to open windows, read files, play sounds and read the controller. Windows, macOS, Linux, Android and the consoles all offer these services, each through different interfaces ([APIs](https://en.wikipedia.org/wiki/API)). The third is a graphics API. Drawing goes through [DirectX](https://en.wikipedia.org/wiki/DirectX) on Windows, [Metal](https://developer.apple.com/metal/) on macOS, and [Vulkan](https://www.vulkan.org/) or [OpenGL](https://www.khronos.org/opengl/) elsewhere. Each approach below deals differently with a mismatch in one or more of these. ## Virtual machines: bring the whole computer A **virtual machine** (VM), such as [Parallels Desktop](https://www.parallels.com/products/desktop/), VMware Fusion or [UTM](https://getutm.app/), runs a complete second operating system inside a window. If you install Windows in a VM, the game sees real Windows, with real Windows drivers, and doesn't know it's on a Mac. That makes VMs very compatible, but the cost is high. A whole second OS uses memory and disk, and graphics have to cross the boundary between the VM and the Mac, which is usually the slowest part. On Apple Silicon a VM can only run an ARM operating system, so Windows on ARM then has to translate x86 games a second time. For games, a VM usually works, but not well. MacLauncher doesn't use virtual machines. ## Emulators: pretend to be the hardware An **emulator** recreates a different machine's hardware in software: its CPU, its graphics chip, its sound chip and its memory map. The original program runs unchanged, as if it were on the original hardware. This is the classic way to play old consoles and old computers, and a good emulator is very faithful. It is also expensive, because every instruction of the original machine has to be imitated, often with many real instructions for each one. For a 1990s DOS game that cost doesn't matter, because a modern Mac has power to spare. For a modern 3D game, full hardware emulation is usually far too slow. MacLauncher uses one emulator on purpose: [DOSBox Staging](https://www.dosbox-staging.org/) for DOS games, because those games are tiny and the machine they expect no longer exists. ## Compatibility layers: translate the conversation A **[compatibility layer](https://en.wikipedia.org/wiki/Compatibility_layer)** doesn't imitate a whole computer. It lets the game's code run on the real CPU and *translates the game's requests to the operating system*. When a Windows game asks Windows to open a file or create a window, the compatibility layer does the equivalent thing on macOS. The best-known compatibility layer is WINE, whose name stands for "Wine Is Not an Emulator". WINE reimplements the Windows APIs on top of macOS and Linux. CrossOver is a commercial, polished distribution of WINE, and [Sikarugir](https://github.com/Sikarugir-App/Sikarugir) is a free one that MacLauncher can download and manage for you. Graphics are translated too: DirectX calls become Metal calls, either directly, as Apple's D3DMetal (part of its [Game Porting Toolkit](https://developer.apple.com/games/game-porting-toolkit/)) and [DXMT](https://github.com/3Shain/dxmt) do, or through Vulkan with [DXVK](https://github.com/doitsujin/dxvk) on top of [MoltenVK](https://github.com/KhronosGroup/MoltenVK). Apple Silicon adds one more step. Windows games are x86-64 code, and an M-series chip runs ARM64. Apple's Rosetta 2 translates x86-64 instructions into ARM64, both ahead of time and while the program runs. On a modern Mac, a Windows game in CrossOver therefore goes through two translations: Rosetta for the CPU and WINE for the operating system. Compatibility layers are much lighter than VMs and much faster than emulators, which is why they are the usual way to play Windows games on a Mac. The translation is never perfect, though. Some Windows behavior has no exact macOS equivalent, and you can notice it in window handling, mouse input, audio or fullscreen switching. ### Not just Windows: consoles and phones The same idea works for other platforms, and several of MacLauncher's runtimes for consoles and phones are compatibility layers in exactly this sense. PlayStation 5 games are x86-64 programs, like PC games. [AnyPS5](https://github.com/boykopovar/AnyPS5) converts the game's executable and modules into macOS programs and supplies its own versions of the PS5's system libraries, much as WINE supplies Windows DLLs. An Intel Mac runs the x86-64 code directly and Apple Silicon runs it through Rosetta, while Vulkan, running on Metal, handles graphics. No part of this imitates PlayStation hardware. The Nintendo Switch has an ARM64 CPU, the same instruction family as Apple Silicon, so once a Switch game has been prepared, its code runs directly on your Mac's processor. [nxnative](https://github.com/seedds/nxnative) provides the system services the game expects and turns its graphics into Metal, compiling the shaders ahead of time. That compilation is the preparation step you see the first time you launch a Switch game. An Android app is mostly Java or Kotlin bytecode, often with native ARM64 libraries. MacLauncher's Android runtimes, MacLauncher Android, [AIM](https://github.com/hahnlee/aim) and [Mac.apk](https://github.com/kksimp/Mac.apk), don't boot an Android phone in a VM. They run the Android *platform* on macOS. MacLauncher Android, for example, runs the real [Android 16](https://developer.android.com/about/versions/16) framework on Java, executes native ARM64 libraries directly on Apple Silicon, and maps windows, input, audio and graphics to their macOS equivalents. AIM stays closer to a real device by running Android's own [ART runtime](https://source.android.com/docs/core/runtime) with Android services, still without a Linux kernel or a virtual machine. iPhone and iPad apps are already ARM64 programs for an Apple operating system, so Apple Silicon Macs can run them almost as they are. [PlayCover](https://github.com/PlayCover/PlayCover)'s [PlayTools](https://github.com/PlayCover/PlayTools) framework adds the missing pieces, such as keyboard and mouse mapping. When this site calls these runtimes "like WINE", it means that the game's own code runs on your real CPU (directly, or through Rosetta), and a layer translates what the game asks of its home platform into macOS. ## Native runtimes: use the engine that already runs on macOS The lightest approach skips translation entirely. Most games aren't written from scratch. They are built on an **[engine](https://en.wikipedia.org/wiki/Game_engine)** such as [Ren'Py](https://www.renpy.org/), [RPG Maker](https://www.rpgmakerweb.com/), [Godot](https://github.com/godotengine/godot), [GameMaker](https://gamemaker.io/), [Unity](https://unity.com/), [LÖVE](https://love2d.org/) or KiriKiri. The engine is the program, and the game is largely *data* that the engine reads: scripts, maps, images and sounds. A Windows release of a game usually bundles the Windows build of its engine next to that data. Many engines also exist for macOS, either from their authors or as open-source reimplementations. If you point the macOS engine at the game's data, the game runs natively, with no WINE, no Rosetta and no emulation. Some examples: - A Ren'Py visual novel runs on the Ren'Py SDK for macOS. - An RPG Maker MV or MZ game is a web app, so it runs on [Electron](https://www.electronjs.org/) or [NW.js](https://nwjs.io/). - An RPG Maker XP, VX or VX Ace game runs on [MKXP-Z](https://github.com/mkxp-z/mkxp-z), an open-source reimplementation of the RPG Maker player. - A GameMaker game such as [UNDERTALE](https://undertale.com/) can run on [Butterscotch](https://github.com/ButterscotchRunner/Butterscotch) or on the official GameMaker macOS runner. - A KiriKiri visual novel runs on [krkrsdl2](https://github.com/krkrsdl2/krkrsdl2), and a Siglus one runs on [siglus_rs](https://github.com/xmoezzz/siglus_rs). MacLauncher calls this a **native runtime**, and most of the project is built around it. Native runtimes usually run faster, use less power and behave like proper Mac apps: windows, fullscreen, mouse and audio work the way macOS expects. The difficulty is matching. The engine has to be the right one, often in the *exact* version the game was made with (Godot 4.5 data usually won't load in Godot 4.6), and it has to be configured correctly. That's tedious by hand, and doing it automatically is most of what MacLauncher does when you import a game. ## Decompilation and recompilation: rebuild the game itself One more approach has taken off in the last few months. Instead of translating a game while it runs, fans rebuild it as a native program. This is almost always done for older games, mostly console games from the N64 to the Xbox 360 era, rather than modern releases. There are two ways to get there. A **decompilation** project reverse-engineers a game's machine code back into readable source code, function by function, until that source compiles into a byte-for-byte copy of the original. [Super Mario 64](https://github.com/n64decomp/sm64) and [The Legend of Zelda: Ocarina of Time](https://github.com/zeldaret/oot) are the landmark examples. Once the source exists, the game can be ported like any other program: [Ship of Harkinian](https://github.com/HarbourMasters/Shipwright) is a PC port of Ocarina of Time built on its decompilation. A **static recompilation** is faster. A tool translates the console's machine code into C or C++ automatically, ahead of time, and the result is compiled for the new platform. [N64Recomp](https://github.com/N64Recomp/N64Recomp) produced [Zelda 64: Recompiled](https://github.com/Zelda64Recomp/Zelda64Recomp) for Majora's Mask, and [XenonRecomp](https://github.com/hedge-dev/XenonRecomp) did the same for the Xbox 360 version of Sonic Unleashed with [Unleashed Recompiled](https://github.com/hedge-dev/UnleashedRecomp). Either way, the result is a true native program, as fast and well-behaved as anything built for the Mac, and these projects often add widescreen, high frame rates and mods along the way. None of them ship the game itself; you supply the data from your own copy. Early projects took dedicated people years. AI models now do much of the decompiling and porting, so a new game no longer takes months or years, which is why so many have appeared recently. A decomp or recomp project is a native runtime for exactly one game, where a native runtime is usually an engine shared by many. MacLauncher focuses on shared runtimes and doesn't package individual decomp and recomp games, because there are too many of them. The [awesome-decomp-games](https://github.com/SubmitGame/awesome-decomp-games) list tracks them, and some publish their own macOS builds, Ship of Harkinian and Zelda 64: Recompiled among them. ## Putting it together | Approach | What runs the game's code | What it costs | In MacLauncher | | --- | --- | --- | --- | | Virtual machine | A whole second operating system | Memory, disk, slow graphics; ARM-only guests on Apple Silicon | Not used | | Emulator | Software imitating the original hardware | A lot of CPU time | DOSBox Staging for DOS games | | Compatibility layer | Your real CPU (directly or through Rosetta), with OS calls translated | Translation gaps, some odd behavior | Sikarugir and CrossOver for Windows; AnyPS5, nxnative, the Android runtimes and PlayCover for consoles and phones | | Native runtime | The engine's own macOS build | Needs the right engine and version | Ren'Py, RPG Maker, Godot, GameMaker, Unity, LÖVE, visual-novel engines and many more | | Decompilation / recompilation | The game itself, rebuilt as a native program | A separate project for each game, almost always an older one | Not packaged: one project per game | MacLauncher tries native runtimes first, falls back to compatibility layers when there is no native option, and keeps both available so you can switch. In MacLauncher's terms, every game belongs to a *game type*, and each runtime is one way to play a game type. [Choosing a runtime](https://procrastinine.github.io/maclauncher/background/choosing-a-runtime.md) explains those terms and how to pick between runtimes, and [Games and runtimes](https://procrastinine.github.io/maclauncher/games.md) lists what's supported. ## Further reading - [Wine](https://en.wikipedia.org/wiki/Wine_(software)) on Wikipedia: where WINE came from and how it reimplements Windows. - [Rosetta](https://en.wikipedia.org/wiki/Rosetta_(software)) on Wikipedia: Apple's translators for the PowerPC-to-Intel and Intel-to-Apple-Silicon transitions. - [Game Porting Toolkit](https://developer.apple.com/games/game-porting-toolkit/): Apple's tools for bringing Windows games to the Mac, including D3DMetal. - [Game engine](https://en.wikipedia.org/wiki/Game_engine) and [runtime system](https://en.wikipedia.org/wiki/Runtime_system) on Wikipedia: the general ideas behind "engine" and "runtime". - [Android runtime (ART) and Dalvik](https://source.android.com/docs/core/runtime): how Android runs app bytecode. > **Full reference:** > The [game type pages](https://procrastinine.github.io/maclauncher/reference/game-types/README.md) in the repository document the formats, settings, tools and runtimes of every game type. --- # Choosing a runtime > How MacLauncher picks a runtime for a game on macOS, when to use a native engine, Sikarugir or CrossOver for Windows games, which Android runtime to pick, and how versions fit in. Web page: https://procrastinine.github.io/maclauncher/background/choosing-a-runtime/ Most of the time you don't need to choose a runtime to play a game on your Mac. When you import a game, MacLauncher works out what it is, which engine version it uses and which runtime should play it, and selects that runtime for you. Many games can run in more than one way, though, and sometimes the second choice works better. This page explains the trade-offs, so you know when switching is worth trying. If terms such as *compatibility layer* are new, [How games run on a Mac](https://procrastinine.github.io/maclauncher/background/how-games-run.md) covers the background. ## Game types and runtimes MacLauncher sorts every game it imports into a **game type**: the engine or platform the game was made for, such as Ren'Py, RPG Maker MV, Unity, Android or PlayStation 5. The game type decides how MacLauncher reads the game's files, which settings apply and which tools appear in the inspector. A **runtime** is one way to play a game type: an engine, a player or a compatibility layer. Every game type has a default runtime, and many have several. The PlayStation 5 game type, for example, can run on AnyPS5 or on Prosper. Ren'Py games can run in the Ren'Py SDK, through Ren'Py Patch, or as the game's own Mac app. Some runtimes serve many game types: Electron and NW.js play all the web-based game types, and Sikarugir and CrossOver can play the Windows executable of almost any game. Tools belong to the game type, not the runtime. A Unity game keeps its Unity decompiler and asset tools when you switch it to CrossOver, because the tools read the game's own data. MacLauncher also picks the right processor build of each runtime for you. Some engines need a newer macOS than MacLauncher itself, or run on only one kind of processor; the [requirements table](https://procrastinine.github.io/maclauncher/reference/runtimes/SYSTEM_REQUIREMENTS.md) lists them, and [Processor builds](https://procrastinine.github.io/maclauncher/tools/versions-and-settings.md#processor-builds) explains how Intel and Apple Silicon builds work together. ## Where the choice lives Select a game in your library to open its **inspector**. Its runtime selector lists every runtime that can play this game, with the installed versions of each, and a change there is saved for that game alone and can be undone at any time. **Runtimes** in the toolbar is where you install, update and remove runtime versions, and **Settings** sets the default runtime for each game type. ## Windows games A game made with an engine MacLauncher recognizes keeps that engine's game type, even when you import its Windows `.exe`. If the game includes a compatible Windows executable, its runtime list has two kinds of choices: the engine's native runtime, which is the default, and the two WINE runtimes, Sikarugir and CrossOver. That works for every game type, however you imported the game; [Games made with other engines](https://procrastinine.github.io/maclauncher/games/windows.md#games-made-with-other-engines) covers the details, including the one exception, a game that lives inside a Mac `.app`. A Windows executable whose engine isn't recognized becomes a *Windows Game*, a game type whose only runtimes are Sikarugir and CrossOver. ### Native runtimes If MacLauncher recognizes the engine ([Ren'Py](https://www.renpy.org/), [RPG Maker](https://www.rpgmakerweb.com/), [Godot](https://github.com/godotengine/godot), [GameMaker](https://gamemaker.io/), [Unity](https://unity.com/) Mono, [LÖVE](https://love2d.org/), [XNA](https://en.wikipedia.org/wiki/Microsoft_XNA)/[FNA](https://fna-xna.github.io/), KiriKiri, Siglus and [many more](https://procrastinine.github.io/maclauncher/games.md)), it defaults to a native macOS runtime for that engine. This is the option to prefer. It's usually faster and easier on the battery, and it behaves like a real Mac app: mouse input feels right, fullscreen works the macOS way, and the graphics layer has the most information to work with. How well it works depends on the engine. Engines whose games are mostly data, such as Ren'Py, all generations of RPG Maker, HTML5 games, most visual-novel engines and LÖVE, run with few problems. Godot and GameMaker usually work well with the right version, which matters a lot for them; MacLauncher reads the version from the game files for you. Unity depends on the game. Unity games built with [Mono](https://docs.unity.com/en-us/engine/current/manual/programming-environment/scripting-backends) can run on the macOS Unity player, but not when they rely on a lot of Windows-specific code or ship only Direct3D shaders. Unity games built with IL2CPP are compiled to Windows machine code, so they need a compatibility layer. ### Sikarugir [Sikarugir](https://github.com/Sikarugir-App/Sikarugir) is a free distribution of [WINE](https://www.winehq.org/). MacLauncher downloads its engines on request, keeps several versions side by side, and sets up a private Windows environment for each game automatically. Sikarugir is the default runtime for Windows Game entries, and it's offered as an alternative for recognized engines too. Its requirements are on the [Windows games](https://procrastinine.github.io/maclauncher/games/windows.md#sikarugir) page. Try it when: - the game uses an engine with no native runtime (a custom engine, [Unreal](https://www.unrealengine.com/), Unity IL2CPP, and so on); - the native runtime has a problem with this particular game; - you want the game to behave as it does on Windows, including Windows-only mods or plugins. ### CrossOver [CrossOver](https://www.codeweavers.com/crossover/) is CodeWeavers' commercial WINE. If it's installed, MacLauncher finds it and offers it as another runtime. You can register several copies of CrossOver, such as a preview build, and pick a different one for each game. CodeWeavers keeps CrossOver current with fixes for newer games, so if you own it, it's usually the better WINE to use. Sikarugir stays the default because it's free and always available. To use CrossOver, pick it in a game's inspector, or make it the default runtime for Windows Game in **Settings**. A few game types have tools but no Mac player: BGI / Ethornell, CatSystem2 and Haxe native builds. These games play their Windows executable through a registered CrossOver application when there is one, and through Sikarugir otherwise. > **Rule of thumb:** > Use the native runtime first. If the game won't start or misbehaves, switch to WINE: CrossOver if you have it, otherwise Sikarugir. Each runtime has its own settings in the inspector, so check those too, for example the graphics backend or locale for WINE. ## Android games The Android game type has three runtimes, and they make different trade-offs. All three run on Apple Silicon without an Android emulator or virtual machine; [How games run on a Mac](https://procrastinine.github.io/maclauncher/background/how-games-run.md#not-just-windows-consoles-and-phones) explains why they work like WINE. ### MacLauncher Android MacLauncher Android is MacLauncher's own runtime and the default. It runs the complete [Android 16](https://developer.android.com/about/versions/16) framework, executes the app's native ARM64 libraries directly on your Mac's CPU, and supports Google accounts and installed Google services. That makes it the most compatible choice for complex commercial games. Because it's built on [Klepton](https://github.com/shinyquagsire23/Klepton), it also runs ARM64 VR/XR titles. The **Execution** setting chooses between two modes: - **JVM**, the default, converts the app's Android bytecode to run on [Java 21](https://openjdk.org/projects/jdk/21/). - **ART** runs Android's original [runtime](https://source.android.com/docs/core/runtime) instead, using a genuine Android system image, which MacLauncher downloads separately. Both modes come in one MacLauncher Android download and share its installed files. ART installations from earlier MacLauncher versions, which were a separate download, stay available with their saved version choices and can be removed in **Runtimes**. If a game crashes or misbehaves in one mode, try the other. ### Mac.apk [Mac.apk](https://github.com/kksimp/Mac.apk) is an independent project that runs Android apps on macOS. MacLauncher downloads its releases and lets you choose its graphics backend for each game: [Metal](https://developer.apple.com/metal/), or [Vulkan](https://www.vulkan.org/) through [MoltenVK](https://github.com/KhronosGroup/MoltenVK). Each release states the macOS version it needs, which MacLauncher reads from the download. Network access is off by default and can be turned on per game, and Google sign-in is available through its own account panel. It's a good alternative when a lighter game doesn't get along with the default runtime. ### AIM [AIM](https://github.com/hahnlee/aim) runs apps with Android's original ART runtime and Android services, still without a Linux kernel or a VM. MacLauncher manages an adapted build and the matching Android system image. AIM requires macOS 26 or later and runs apps offline, without Google account integration. Try it when you want the behavior closest to stock Android and the game doesn't need online services. | | MacLauncher Android | Mac.apk | AIM | | --- | --- | --- | --- | | Best for | Complex commercial games, Google sign-in, VR/XR | Lighter games, choice of Metal or Vulkan | Stock Android behavior, offline games | | How it runs apps | Android framework on Java (JVM) or original ART | Its own Java-based Android host | Original ART with Android services | | Google accounts | Yes | Yes, turned on per game | No | | Requirements | Apple Silicon, macOS 13+ | Apple Silicon, macOS set by each release | Apple Silicon, macOS 26+ | The [Android guide](https://procrastinine.github.io/maclauncher/reference/game-types/ANDROID.md) has the full details. You can get APKs from [Google Play](https://play.google.com/store/games), [F-Droid](https://f-droid.org/) and [IzzyOnDroid](https://apt.izzysoft.de/fdroid/) inside MacLauncher; see [Stores and downloads](https://procrastinine.github.io/maclauncher/tools/stores-and-downloads.md). ## Other game types with a choice | Game type | Runtimes | How they differ | | --- | --- | --- | | [Flash](https://en.wikipedia.org/wiki/Adobe_Flash) | Adobe Flash Player (default), [Ruffle](https://ruffle.rs/) | Adobe's Flash Player projector is the most faithful. Ruffle is an open-source reimplementation that keeps improving. | | Web games: RPG Maker MV and MZ, Construct, Tyrano, GameMaker HTML5 and Web | [Electron](https://www.electronjs.org/) (default, included with MacLauncher), [NW.js](https://nwjs.io/), NW.js (Patched) | Electron works for most games. NW.js is closer to what many of these games were built for, and NW.js (Patched) adds optional compatibility settings. RPG Maker MV and MZ switch to NW.js (Patched) automatically once an NW.js version is installed. | | GameMaker | [Butterscotch](https://github.com/ButterscotchRunner/Butterscotch) (default), the official GameMaker runners, [OpenGMK](https://github.com/OpenGMK/OpenGMK) | Butterscotch and the official runners play GameMaker Studio games. OpenGMK plays classic GameMaker 8 games. | | NScripter | [ONScripter-Yuri](https://github.com/YuriSizuku/OnscripterYuri) (default), [ONScripter-EN](https://github.com/Galladite27/ONScripter-EN), ONScripter-Yuri Web | ONScripter-Yuri and ONScripter-EN differ in the script features and save locations they support. ONScripter-Yuri Web runs the game in a browser window. | | Siglus / RealLive | [siglus_rs](https://github.com/xmoezzz/siglus_rs) (default), [RLVM](https://github.com/eglaysher/rlvm) | siglus_rs plays Siglus, RealLive and AVG32 games. RLVM is an alternative for RealLive games. | | PlayStation 5 | [AnyPS5](https://github.com/boykopovar/AnyPS5) (default), [Prosper](https://github.com/mattias800/prosper) | AnyPS5 converts the game into macOS programs. Prosper runs the original PS5 programs; Runtimes offers MacLauncher Builds packages and accepts local builds. | | Ren'Py | Ren'Py SDK (default), Ren'Py Patch | The SDK runs the game from a private copy of its scripts. Ren'Py Patch copies the macOS runtime files from the matching SDK into the game. | Many game types can also run a working Mac build that ships with the game. That runtime is called **Game's macOS app**. Graphics effects still apply. ## Versions Every runtime in MacLauncher is versioned, and you can keep as many versions installed as you like. When a game starts, MacLauncher picks the version in this order: 1. Your choice for this game, if you picked one in its inspector. 2. The version the game asks for, when MacLauncher can read it from the game files. Godot, Unity, GameMaker and Ren'Py games care about this a lot. 3. Your default for that runtime, set in **Runtimes**. A version you pick is used exactly: if it isn't installed, MacLauncher offers to download it instead of falling back to another version. Without any of these, MacLauncher uses the newest version the project has published, and a saved default that the project has since withdrawn is replaced by the newest one unless you have it installed. --- # Games and runtimes > The game types MacLauncher plays on macOS, from RPG Maker, Ren'Py and Godot games to visual novels, Android apps and Windows games, and the runtimes behind each one. Web page: https://procrastinine.github.io/maclauncher/games/ Many games built for Windows can run without it, because their engine also exists for macOS or an open-source reimplementation can read the same data. MacLauncher collects those runtimes, picks the right one when you import a game, and manages their versions for you. Every game in MacLauncher has a game type, such as Ren'Py, Unity or PlayStation 5, and each game type has one or more runtimes that can play it. [Choosing a runtime](https://procrastinine.github.io/maclauncher/background/choosing-a-runtime.md#game-types-and-runtimes) explains the two terms. The pages in this section group related game types and describe what runs them. In the repository, the [game type reference](https://procrastinine.github.io/maclauncher/reference/game-types/README.md) has a page for every game type with its exact formats, versions, settings, tools and runtimes. ## The game types | Page | Game types | | --- | --- | | [Desktop engines](https://procrastinine.github.io/maclauncher/games/desktop-engines.md) | [RPG Maker](https://www.rpgmakerweb.com/) (MV and MZ, XP/VX/VX Ace, 2000/2003), WOLF RPG Editor, [Ren'Py](https://www.renpy.org/), [Godot](https://github.com/godotengine/godot), [GameMaker](https://gamemaker.io/), [Unity](https://unity.com/), [LÖVE](https://love2d.org/), [XNA](https://en.wikipedia.org/wiki/Microsoft_XNA)/[FNA](https://fna-xna.github.io/), Java, Flash, and the web game types: Construct, Tyrano, GameMaker HTML5 and Web | | [Visual novels](https://procrastinine.github.io/maclauncher/games/visual-novels.md) | KiriKiri, Siglus / RealLive, NScripter, AliceSoft, MAGES., Nitroplus, Minori, FAVORITE / FVP, AI5WIN, VNDS, BGI / Ethornell, CatSystem2 | | [Windows games through WINE](https://procrastinine.github.io/maclauncher/games/windows.md) | Windows Game, plus the Windows executables of other game types, played with [Sikarugir](https://github.com/Sikarugir-App/Sikarugir) ([WINE](https://www.winehq.org/)) or [CrossOver](https://www.codeweavers.com/crossover/) | | [Mobile and consoles](https://procrastinine.github.io/maclauncher/games/mobile-and-consoles.md) | Android, iOS / iPadOS, PlayStation 5, Nintendo Switch | | [Mac apps, retro and more](https://procrastinine.github.io/maclauncher/games/more.md) | macOS Game (including 32-bit apps), DOS, ScummVM, Infinity Engine, Half-Life (Xash3D FWGS), MUGEN / Ikemen GO, [HashLink](https://hashlink.haxe.org/), Haxe native build, Video | ## How a game finds its runtime MacLauncher identifies a game by reading its files on import: a `Game.ini` with RPG Maker scripts, a Ren'Py `game/` folder, a Godot `.pck`, a GameMaker `data.win`, an `.apk` manifest or a PS5 `param.json`. From those it works out the game type and, where it matters, the engine *version*, which often decides whether a game runs at all. Godot 4.5 and 4.6 projects, for instance, usually aren't interchangeable, and Unity games want the exact player version they were built with. The game's inspector then shows the runtime MacLauncher picked, along with the alternatives, and pressing **Play** downloads anything missing and starts the game. ## Native first Wherever there's a native runtime, MacLauncher prefers it. Speed and battery life are part of the reason, since no translation layer sits between the game and your Mac. A native runtime also behaves like a Mac app: window management, fullscreen, mouse and audio work the way macOS expects, and those are the areas where WINE can be erratic. A game whose own Mac `.app` fails to open because of signing or packaging problems can still run on a native runtime, which plays the same game data. When there is no native runtime, Sikarugir and CrossOver are always available as a fallback, and you can switch at any time. [Choosing a runtime](https://procrastinine.github.io/maclauncher/background/choosing-a-runtime.md) talks through the trade-offs. ## Runtimes come from catalogs MacLauncher itself stays small, because engines and tools are downloaded on demand from two kinds of catalog: the upstream projects' own releases, and [MacLauncher Builds](https://procrastinine.github.io/maclauncher-builds/), a companion project with ready-to-run macOS builds of engines that need adapting or have no official Mac release. Either way, you pick versions in the **Runtimes** window. ## Runtimes built for MacLauncher Most runtimes are existing open-source projects that MacLauncher manages. A few exist only in MacLauncher: - [MacLauncher Android](https://github.com/procrastinine/maclauncher-android), a game-focused Android runtime that also handles ARM64 VR/XR titles. - A macOS port of [OpenGMK](https://github.com/OpenGMK/OpenGMK), the only native way to play classic GameMaker 8 games on a Mac. - macOS ports of [AnyPS5](https://github.com/boykopovar/AnyPS5), [ONScripter-EN](https://github.com/Galladite27/ONScripter-EN), [AI5-SDL2](https://github.com/nunuhara/ai5-sdl2), [KAG3](https://github.com/krkrsdl2/kag3) and [ReMinori](https://github.com/luoyily/ReMinori). - [Offline Steam API support](https://procrastinine.github.io/maclauncher/reference/runtimes/STEAM_API.md), for games that expect Steam to be running before they'll start. --- # Desktop engines > RPG Maker, Ren'Py, Godot, GameMaker, Unity, LÖVE, XNA/FNA, Java, Flash and HTML5 games on macOS, through native engine runtimes that usually play a game's Windows release without WINE. Web page: https://procrastinine.github.io/maclauncher/games/desktop-engines/ RPG Maker, Ren'Py, Godot, GameMaker, Unity and the other engines on this page are behind a large share of indie games, and each one has a native macOS runtime. A game's Windows release can therefore usually run on a Mac without [WINE](https://www.winehq.org/): MacLauncher pairs the game's data with the right engine build, and the game behaves like a Mac app. Each section below covers one game type, or a few closely related ones, and says what to expect. The linked guides describe every format and setting. ## Web games Many games are web apps in a box. [RPG Maker](https://www.rpgmakerweb.com/) MV and MZ, [Construct](https://www.construct.net/) 2 and 3, [TyranoBuilder](https://tyranobuilder.com/) and TyranoScript, and [GameMaker](https://gamemaker.io/)'s HTML5 export all produce HTML and JavaScript, and a Windows release wraps that in a Windows copy of a browser engine. MacLauncher recognizes each of these as its own game type: RPG Maker MV, RPG Maker MZ, Construct, Tyrano and GameMaker HTML5. The Web game type covers any other HTML game. All of them run in the same hosts: **[Electron](https://www.electronjs.org/)**, which is included with the app, so there's nothing to download, or **[NW.js](https://nwjs.io/)**, whose versions are downloaded on demand. There's also **NW.js (Patched)**, which uses the same NW.js versions and adds a patch layer with optional compatibility settings; GameMaker HTML5 doesn't offer it. RPG Maker MV and MZ games use NW.js (Patched) when an NW.js version is installed, and Electron otherwise. Most of these games work well in either host. RPG Maker MV and MZ games also get a structured save editor and cheats; see [Saves and cheats](https://procrastinine.github.io/maclauncher/tools/saves-and-cheats.md). **Example games:** OMORI (RPG Maker MV). Guides: [RPG Maker MV and MZ](https://procrastinine.github.io/maclauncher/reference/game-types/RPGMAKER_MV_MZ.md), [Construct](https://procrastinine.github.io/maclauncher/reference/game-types/CONSTRUCT.md), [Tyrano](https://procrastinine.github.io/maclauncher/reference/game-types/TYRANO.md), [GameMaker HTML5](https://procrastinine.github.io/maclauncher/reference/game-types/GAMEMAKER_HTML5.md), [Web](https://procrastinine.github.io/maclauncher/reference/game-types/WEB.md), [Web runtimes](https://procrastinine.github.io/maclauncher/reference/runtimes/WEB_RUNTIMES.md) ## RPG Maker XP, VX and VX Ace The Ruby-based RPG Makers run on [MKXP-Z](https://github.com/mkxp-z/mkxp-z), an open-source reimplementation of the RPG Maker player. MacLauncher offers its own MKXP-Z builds, which add fixes for Unicode file names, as well as upstream builds. It also handles the [RPG Maker RTP](https://www.rpgmakerweb.com/run-time-package), the shared asset packs that many games expect, and downloads the official pack when a game needs it. Encrypted archives can be extracted, and the Ruby scripts can be exported and repacked. **Example games:** To the Moon and OneShot (XP), The Witch's House (VX). Guide: [RPG Maker XP/VX/VX Ace](https://procrastinine.github.io/maclauncher/reference/game-types/RPGMAKER_XP_VX.md) ## RPG Maker 2000/2003 The older RPG Makers run on [EasyRPG Player](https://easyrpg.org/), a mature open-source reimplementation of the RPG Maker 2000/2003 engine. MacLauncher can also export a game's database, maps and dialogue as JSON or text, for example for translation. **Example games:** Yume Nikki and Ib. Guide: [RPG Maker 2000/2003](https://procrastinine.github.io/maclauncher/reference/game-types/RPGMAKER_2000_2003.md) ## WOLF RPG Editor [WOLF RPG Editor](https://www.silversecond.com/WolfRPGEditor/) games run on [Browser Woditor](https://frostyhowl.com/browser-woditor/), a browser port of the engine. MacLauncher converts archives that use the standard WOLF encryption into a form Browser Woditor can read, without changing the original files. Games that use Windows-specific system functions, native DLLs, WOLF RPG Pro features or MP4 video can run in [Sikarugir or CrossOver](https://procrastinine.github.io/maclauncher/games/windows.md) instead. **Example games:** Mad Father. Guide: [WOLF RPG Editor](https://procrastinine.github.io/maclauncher/reference/game-types/WOLFRPG.md) ## Ren'Py [Ren'Py](https://www.renpy.org/) visual novels run on the matching Ren'Py SDK for macOS. MacLauncher reads which Python generation and Ren'Py version a game was built with and picks a compatible SDK. The other runtime, **Ren'Py Patch**, copies the macOS runtime files from the matching SDK into the game instead. Ren'Py has its own toolbox too: RPA archive extraction, script decompilation, a developer console and cheat add-ons. **Example games:** Slay the Princess, Doki Doki Literature Club!, Katawa Shoujo. Guide: [Ren'Py](https://procrastinine.github.io/maclauncher/reference/game-types/RENPY.md) ## Godot [Godot](https://godotengine.org/) games run on the official macOS engine of the *same version*. That matters, because a project made with one Godot version often won't load in another (4.5 and 4.6, for example). MacLauncher detects the version from the game, and it also chooses between Godot's two builds of each version. A game written in C# needs the .NET build and gets it automatically; other games use the Standard build, or the .NET build when only that one is installed. The inspector's **Variant** menu shows which build a game will use and can change it. **Example games:** Brotato, Dome Keeper, Cassette Beasts, Buckshot Roulette. Guide: [Godot](https://procrastinine.github.io/maclauncher/reference/game-types/GODOT.md) ## GameMaker GameMaker has a few generations, and each uses a different runtime. GameMaker Studio games, such as [UNDERTALE](https://undertale.com/), run on [Butterscotch](https://github.com/ButterscotchRunner/Butterscotch), an open-source runner and the default, or on the official GameMaker runners at the exact version the game needs. Classic GameMaker 8.0 and 8.1 games run on MacLauncher's macOS port of [OpenGMK](https://github.com/OpenGMK/OpenGMK), the only way to play them natively on a Mac. HTML5 exports are a separate game type, GameMaker HTML5, and run like the other [web games](#web-games). **Example games:** UNDERTALE, Hyper Light Drifter and Hotline Miami (GameMaker Studio); the original freeware Spelunky (classic GameMaker). Guide: [GameMaker](https://procrastinine.github.io/maclauncher/reference/game-types/GAMEMAKER.md) ## Unity [Unity](https://unity.com/) games use one of two [scripting backends](https://docs.unity.com/en-us/engine/current/manual/programming-environment/scripting-backends), and the backend decides how a game can run on a Mac. Mono games ship their code as [.NET](https://github.com/dotnet/runtime) assemblies, and MacLauncher can run them on the macOS Unity player of the exact version they were built with. Many work well, but games that rely on Windows-specific libraries, or that ship only Direct3D shaders, won't. IL2CPP games are compiled to Windows machine code, so they need [Sikarugir or CrossOver](https://procrastinine.github.io/maclauncher/games/windows.md). **Example games:** Hollow Knight, Cuphead. Guide: [Unity](https://procrastinine.github.io/maclauncher/reference/game-types/UNITY.md) ## XNA and FNA Games built on Microsoft's [XNA](https://en.wikipedia.org/wiki/Microsoft_XNA) framework, a big part of the 2010s indie scene, belong to the FNA / XNA 4 game type. They run on [FNA](https://fna-xna.github.io/), a reimplementation of XNA, together with [FNA3D](https://github.com/FNA-XNA/FNA3D), [FAudio](https://github.com/FNA-XNA/FAudio) and .NET. **Example games:** Terraria, Celeste, Fez. Guide: [FNA / XNA 4](https://procrastinine.github.io/maclauncher/reference/game-types/FNA.md) ## LÖVE [LÖVE](https://love2d.org/) games, including `.love` archives, Windows "fused" executables and Linux AppImages, run on the matching LÖVE release. If a game ships compiled [Lua](https://www.lua.org/) or [LuaJIT](https://luajit.org/) bytecode, MacLauncher's tools can turn it back into readable source. **Example games:** [Balatro](https://www.playbalatro.com/), Mari0. Guide: [LÖVE](https://procrastinine.github.io/maclauncher/reference/game-types/LOVE.md) ## Java Java games run on [Eclipse Temurin](https://adoptium.net/), with the Java version chosen to match what the game was compiled for. Java games that use Steam get [steamworks4j](https://github.com/code-disaster/steamworks4j) support, and [Vineflower](https://vineflower.org/) can decompile their code. In **Runtimes**, each long-term support (LTS) release of Java, from 8 to 25, has its own section, and Adoptium's other releases are listed under **Other**. A game's inspector offers the same releases, and an exact version chosen for a game stays selected even before its version list has been loaded. **Example games:** Slay the Spire. Guide: [Java](https://procrastinine.github.io/maclauncher/reference/game-types/JAVA.md) ## Flash [Flash](https://en.wikipedia.org/wiki/Adobe_Flash) games (`.swf`) can run on Adobe's own Flash Player projector, the default, or on [Ruffle](https://ruffle.rs/), the open-source Flash reimplementation. The projector gives the most faithful playback, and Ruffle is the alternative. **Example games:** the original Meat Boy. Guide: [Flash](https://procrastinine.github.io/maclauncher/reference/game-types/FLASH.md) ## When a game ships its own Mac build When a game includes a working macOS build, most game types on this page can run it directly. That runtime is called **Game's macOS app**. You still get the [graphics layer](https://procrastinine.github.io/maclauncher/graphics.md), version management and tools. --- # Visual novels > Windows visual novels on macOS through native interpreters for KiriKiri, Siglus and RealLive, NScripter, AliceSoft, MAGES., Nitroplus, Minori, FAVORITE, AI5WIN and VNDS. Web page: https://procrastinine.github.io/maclauncher/games/visual-novels/ [Visual novels](https://en.wikipedia.org/wiki/Visual_novel) that were only ever released for Windows can often run natively on a Mac, because most visual-novel engines are interpreters: the game is a set of script and asset archives, and the engine reads them. Fan and preservation communities have written open-source interpreters for many of these engines, and MacLauncher builds and manages them for macOS, with proper fonts, audio and fullscreen. [Ren'Py](https://procrastinine.github.io/maclauncher/games/desktop-engines.md#renpy), the most popular modern engine, is covered on the desktop engines page, and Tyrano runs with the other [web games](https://procrastinine.github.io/maclauncher/games/desktop-engines.md#web-games) there. ## Game types and runtimes Each engine below is its own game type, linked to its guide. | Game type | Runtime on macOS | | --- | --- | | [KiriKiri](https://procrastinine.github.io/maclauncher/reference/game-types/KIRIKIRI.md) (KAG) | [krkrsdl2](https://github.com/krkrsdl2/krkrsdl2) with [KAG3](https://github.com/krkrsdl2/kag3) | | [Siglus / RealLive](https://procrastinine.github.io/maclauncher/reference/game-types/SIGLUS.md) (Key, Visual Arts) | [siglus_rs](https://github.com/xmoezzz/siglus_rs), or [RLVM](https://github.com/eglaysher/rlvm) for RealLive | | [NScripter](https://procrastinine.github.io/maclauncher/reference/game-types/NSCRIPTER.md) | [ONScripter-Yuri](https://github.com/YuriSizuku/OnscripterYuri), or MacLauncher's port of [ONScripter-EN](https://github.com/Galladite27/ONScripter-EN) | | [AliceSoft](https://procrastinine.github.io/maclauncher/reference/game-types/ALICESOFT.md) (System 1–4) | [System3](https://github.com/kichikuou/system3-sdl2), [xsystem35](https://github.com/kichikuou/xsystem35-sdl2) or [xsystem4](https://github.com/nunuhara/xsystem4), depending on the engine generation | | [MAGES.](https://procrastinine.github.io/maclauncher/reference/game-types/MAGES.md) | [Impacto](https://github.com/CommitteeOfZero/impacto) | | [Nitroplus](https://procrastinine.github.io/maclauncher/reference/game-types/NITROPLUS.md) | [NPengine](https://github.com/FGRE/libnpengine) with [libnpa](https://github.com/FGRE/libnpa) | | [Minori](https://procrastinine.github.io/maclauncher/reference/game-types/MINORI.md) | MacLauncher's port of [ReMinori](https://github.com/luoyily/ReMinori) | | [FAVORITE / FVP](https://procrastinine.github.io/maclauncher/reference/game-types/FVP.md) | [RFVP](https://github.com/xmoezzz/rfvp) | | [AI5WIN](https://procrastinine.github.io/maclauncher/reference/game-types/AI5.md) (elf) | MacLauncher's port of [AI5-SDL2](https://github.com/nunuhara/ai5-sdl2) | | [VNDS](https://procrastinine.github.io/maclauncher/reference/game-types/VNDS.md) (Nintendo DS conversions) | [VNDS-LOVE](https://github.com/ajusa/VNDS-LOVE) | | [BGI / Ethornell](https://procrastinine.github.io/maclauncher/reference/game-types/BGI.md) | No native interpreter; see [below](#engines-without-a-native-interpreter) | | [CatSystem2](https://procrastinine.github.io/maclauncher/reference/game-types/CATSYSTEM2.md) | No native interpreter; see [below](#engines-without-a-native-interpreter) | When a game includes a compatible Windows executable, its game type also offers [Sikarugir and CrossOver](https://procrastinine.github.io/maclauncher/games/windows.md) as runtimes. Support depends on the engine and its format, and the same game can use different engines or formats across platforms and re-releases. To find out which engine a release uses, [VNDB](https://vndb.org/), the visual novel database, lists the engine on many release pages. Each interpreter supports the formats its own project supports, and some engines changed formats over the years, so the guides list exactly which variants work. ## What to expect ### Saves Interpreters such as siglus_rs and RFVP keep their own save files, separate from the original Windows engine's. Your Windows saves stay where they were, and MacLauncher's save tools show where the new ones are. ### Fonts and languages Many visual novels are Japanese and expect Japanese system fonts. The native interpreters handle text shaping and fonts themselves, and fan translations and patches that the engine supports keep working. ### Script tools Most of these game types come with tools for reading the script. KiriKiri scripts export as readable TJS and KAG, AliceSoft and Siglus scenarios can be decompiled, and RealLive, NScripter, Nitroplus, Minori and CatSystem2 scripts can be exported. BGI, FAVORITE and MAGES. games have message and text exporters. See [Decompilers and extractors](https://procrastinine.github.io/maclauncher/tools/decompilers-and-extractors.md#visual-novels). ### Engines without a native interpreter BGI (also called Ethornell) and CatSystem2 have no native interpreter. MacLauncher still recognizes their games and offers their archive and script tools, and it plays the original Windows executable through [CrossOver or Sikarugir](https://procrastinine.github.io/maclauncher/games/windows.md). --- # Windows games through WINE > Windows games on macOS through WINE: Sikarugir and CrossOver run the games that have no native engine runtime, with a private Windows environment and graphics settings for each game. Web page: https://procrastinine.github.io/maclauncher/games/windows/ Not every Windows game is built on an engine with a Mac runtime. Custom engines, [Unreal](https://www.unrealengine.com/) games, Unity [IL2CPP](https://docs.unity.com/en-us/engine/current/manual/programming-environment/scripting-backends) builds and countless older titles need Windows itself, or at least something that speaks its language. For those, MacLauncher uses **[WINE](https://www.winehq.org/)**, the compatibility layer that answers a game's Windows API calls with macOS equivalents. [How games run on a Mac](https://procrastinine.github.io/maclauncher/background/how-games-run.md#compatibility-layers-translate-the-conversation) explains how it works. MacLauncher has two WINE runtimes, Sikarugir and CrossOver. A Windows executable whose engine MacLauncher doesn't recognize is imported as the Windows Game type, and these two are its runtimes. They also serve other game types: any game with a compatible Windows executable offers them next to its native runtime, as [Games made with other engines](#games-made-with-other-engines) explains, and BGI, CatSystem2 and Haxe native builds, which have no Mac player, play through them. ## Sikarugir [Sikarugir](https://github.com/Sikarugir-App/Sikarugir) is a free WINE distribution for macOS. Used on its own, it means installing its Creator app, building a "wrapper" for each game and setting it up yourself. MacLauncher skips all of that. It downloads Sikarugir's WINE engines directly, keeps as many versions as you like, and builds a private Windows environment (a ["prefix"](https://gitlab.winehq.org/wine/wine/-/wikis/FAQ) or "bottle") for each game the first time you press Play. Sikarugir is the default runtime for Windows Game entries, and games of other types offer it as an alternative. MacLauncher reads each engine's macOS requirement and identifies the renderers in its matching Template package during installation. Graphics libraries have separate requirements: DXMT starts at macOS 14 on a compatible GPU, while D3DMetal needs Apple Silicon and a macOS version supported by the installed framework and its dependencies. If an installation is ever incomplete, **Install** in Runtimes replaces it, or Play offers to download it again before the game starts, and either way each game's private Windows environment and saves are kept. [Sikarugir's runtime reference](https://procrastinine.github.io/maclauncher/reference/runtimes/SIKARUGIR.md) describes the renderers and their graphics requirements. ## CrossOver If you own [CrossOver](https://www.codeweavers.com/crossover/), MacLauncher finds it in your Applications folder and offers it alongside Sikarugir. You can register more than one copy, such as a preview build or an older version you want to keep, and choose a different one for each game. CodeWeavers keeps CrossOver current with fixes for newer games, so if you own it, it's usually the better choice, and you can make it the default runtime for Windows Game in **Settings**. CrossOver's updates and licensing stay with CodeWeavers; MacLauncher only points games at the copy you pick. Its **Graphics** selector shows only the renderers that your Mac and that CrossOver version can run. ## Games made with other engines Plenty of games made with a recognized engine, such as Ren'Py, RPG Maker, Unity, Godot, GameMaker or Construct, also ship a Windows build. Any game with a working x86 or x64 Windows executable offers Sikarugir and CrossOver next to its native runtime, whatever its engine, and keeps its engine's game type, default runtime and tools. It doesn't matter whether you imported the folder, the Windows `.exe` or another launcher file, such as a Ren'Py `.sh` script. When it imports a game, MacLauncher picks out the main executable and ignores uninstallers, setup programs, redistributables and crash reporters. A game that lives inside a Mac `.app` runs as that app and doesn't get the WINE runtimes. An app that merely sits beside a Windows build changes nothing, so a Ren'Py release with a Windows `.exe`, a Linux `.sh` script and a Mac `.app` side by side still offers both. The chosen executable is saved with the game, and the runtime list reads that record instead of the game's files. A game on an unplugged drive therefore keeps its WINE choices. If an update renames the executable, MacLauncher records the new one the next time it refreshes the game's details, at startup or when the drive comes back. ## What MacLauncher handles ### Original game files and separate Windows environments Play uses the original working directory and reads the game's files there directly. The original Windows executable runs directly unless an app-adjacent DLL adapter requires an executable view; Play does not prepare a private copy of the whole game folder. Each game gets its own Windows environment for its registry, Windows profile and DLL overrides. Camera and XeSS compatibility adapters can require a small executable and DLL view, while the working directory stays original. Files a game writes specifically beside the adapted executable remain in that view. The [runtime reference](https://procrastinine.github.io/maclauncher/reference/runtimes/CROSSOVER.md) describes the adapters' file handling. ### Runtime settings **Runtime Settings** in each game's inspector gather the useful options in one place. The most important ones are: | Setting | What it does | | --- | --- | | Graphics | Chooses how [DirectX](https://en.wikipedia.org/wiki/DirectX) becomes [Metal](https://developer.apple.com/metal/): Automatic, [DXMT](https://github.com/3Shain/dxmt), [DXVK](https://github.com/doitsujin/dxvk), D3DMetal (from Apple's [Game Porting Toolkit](https://developer.apple.com/games/game-porting-toolkit/)) or WineD3D. When a game renders wrongly, try another backend first. | | Language locale | Sets a locale such as `ja_JP.UTF-8`, for Japanese games that otherwise show garbled text. | | Windows version | Chooses which Windows version to report: 10, 11, 7 or XP. | | DirectDraw compatibility | Adds a compatibility wrapper for old 32-bit games that draw with DirectDraw (Sikarugir only). | | DLL overrides, environment variables, game arguments and WINE debug channels | Advanced tuning, plus an option that lets [BepInEx](https://github.com/BepInEx/BepInEx) mods load. | ### Rosetta WINE on the Mac runs Intel code, so on Apple Silicon it needs [Rosetta 2](https://support.apple.com/en-us/102527). If Rosetta isn't installed yet, MacLauncher asks and installs it through the normal macOS prompt. ### Graphics effects MacLauncher's [graphics layer](https://procrastinine.github.io/maclauncher/graphics.md) works on WINE games just as it does on native ones. On Apple Silicon, WINE games can also feed MacLauncher's [temporal upscalers](https://procrastinine.github.io/maclauncher/graphics/upscaling.md#temporal-upscalers), which need information from the game's renderer. Compatible 64-bit games pass [MetalFX](https://developer.apple.com/documentation/metalfx) temporal upscaling through their own [DLSS](https://www.nvidia.com/en-us/geforce/technologies/dlss/) setting, and games that use AMD's FSR 2 or 3 hand over their camera data through DXMT. For FSR, Play downloads only the DXMT libraries it needs, not another WINE engine. **Runtimes → Graphics → DXMT support** keeps one set of these library versions, with one default, for both Sikarugir and CrossOver, and each game's **DXMT support** setting can choose a different version. ## What to expect WINE is very good, but it's a translation, so results vary from game to game. Games whose DRM or anti-cheat requires real Windows won't run. Installers that need to install further components can't be played as games; MacLauncher plays the game itself, so point it at the installed game folder or its main `.exe`. If a game's engine has a [native runtime](https://procrastinine.github.io/maclauncher/games/desktop-engines.md), try that first; it will usually run better. If a WINE game misbehaves, try another graphics backend, another WINE version, or CrossOver if you have it. [Choosing a runtime](https://procrastinine.github.io/maclauncher/background/choosing-a-runtime.md#windows-games) has more on choosing between them. Guides: [Windows Game](https://procrastinine.github.io/maclauncher/reference/game-types/WINDOWS.md), [Sikarugir](https://procrastinine.github.io/maclauncher/reference/runtimes/SIKARUGIR.md), [CrossOver](https://procrastinine.github.io/maclauncher/reference/runtimes/CROSSOVER.md) --- # Mobile and consoles > Android, iOS and iPadOS apps, PlayStation 5 and Nintendo Switch games, all running on a Mac without emulating the device. Web page: https://procrastinine.github.io/maclauncher/games/mobile-and-consoles/ Android apps, iPhone games, and PlayStation 5 and Nintendo Switch games can run on a Mac without emulating the device. Each of these runtimes works like [WINE](https://www.winehq.org/): the game's own code runs on your Mac's processor, and a layer translates what it asks of its home platform into macOS. [How games run on a Mac](https://procrastinine.github.io/maclauncher/background/how-games-run.md#not-just-windows-consoles-and-phones) explains why that's possible. Android, iPhone and iPad, and Switch games are built for ARM processors, so they need an Apple Silicon Mac. PlayStation 5 games are Intel (x86-64) programs instead: they run directly on Intel Macs and through [Rosetta](https://support.apple.com/en-us/102527) on Apple Silicon. MacLauncher Android works on any macOS version that MacLauncher supports, while AIM, both PS5 runtimes and nxnative need macOS 26. Each Mac.apk and PlayCover release states its own minimum, which MacLauncher reads from the download. The Vulkan provider a game uses can need a newer macOS still; the [requirements reference](https://procrastinine.github.io/maclauncher/reference/runtimes/SYSTEM_REQUIREMENTS.md) lists each one. ## Android Drag in an `.apk`, a folder of [split APKs](https://developer.android.com/guide/app-bundle), or an `.xapk`, `.apkm` or `.apks` bundle, and press Play. [Expansion (OBB) files](https://developer.android.com/google/play/expansion-files) next to the APK come along automatically. The Android game type has three runtimes. The default, MacLauncher Android, is a game-focused runtime that runs the full [Android 16](https://developer.android.com/about/versions/16) framework, supports Google accounts and services, and handles ARM64 VR/XR titles such as [Beat Saber](https://www.beatsaber.com/). It's the most compatible with complex commercial games like [Roblox](https://www.roblox.com/) or [Hungry Shark Evolution](https://www.ubisoft.com/en-us/game/hungry-shark/evolution). [Mac.apk](https://github.com/kksimp/Mac.apk) is an independent runtime with a choice of [Metal](https://developer.apple.com/metal/) or [Vulkan](https://www.vulkan.org/) graphics. [AIM](https://github.com/hahnlee/aim) runs apps offline on Android's original [ART runtime](https://source.android.com/docs/core/runtime) with Android services. [Choosing a runtime](https://procrastinine.github.io/maclauncher/background/choosing-a-runtime.md#android-games) compares them. Whichever runtime you use, each app runs on a virtual device modeled on the Pixel Tablet, in its own window, with private storage that stays separate from your other games. You can also download APKs inside MacLauncher from [Google Play](https://play.google.com/store/games) (with your own account), [F-Droid](https://f-droid.org/) and [IzzyOnDroid](https://apt.izzysoft.de/fdroid/), including specific older versions. See [Stores and downloads](https://procrastinine.github.io/maclauncher/tools/stores-and-downloads.md). In MacLauncher Android, the data-usage figures an app can ask Android for always read zero, so no app learns anything about the Mac's network traffic or that of other apps. **Example games:** Roblox, Monument Valley, Stardew Valley. Guide: [Android](https://procrastinine.github.io/maclauncher/reference/game-types/ANDROID.md) ## iOS and iPadOS iPhone and iPad apps are already ARM64 programs for an Apple operating system, so an Apple Silicon Mac can run them almost directly. MacLauncher uses [PlayCover](https://github.com/PlayCover/PlayCover)'s [PlayTools](https://github.com/PlayCover/PlayTools) framework to fill the gaps, including keyboard and mouse mapping. You don't need to install the PlayCover app itself: MacLauncher downloads the runtime, prepares a private copy of the app, signs it locally and launches it. You need a decrypted (unencrypted) `.ipa`. Apps run in a file sandbox with network access off by default; turn on **Network access** in the inspector for games that need to go online. **Example games:** Genshin Impact. Guide: [iOS / iPadOS](https://procrastinine.github.io/maclauncher/reference/game-types/IOS.md) ## PlayStation 5 PS5 games are x86-64 programs, the same instruction family as PC games, and the PlayStation 5 game type has two runtimes for them. The default, [AnyPS5](https://github.com/boykopovar/AnyPS5), converts the game's executable and modules into macOS programs and supplies its own versions of the PS5 system libraries. Converted games run natively on Intel Macs and through [Rosetta](https://support.apple.com/en-us/102527) on Apple Silicon, with graphics on Vulkan over Metal using an Intel-compatible driver. MacLauncher uses its own macOS port of AnyPS5 and manages the conversion, runtime versions, the Vulkan driver and your controls. You need an unpacked, decrypted PS5 game folder (with `sce_sys/param.json` and the game executable) and macOS 26 or later. Controls map to keyboard and mouse by default (I/J/K/L for the face buttons, WASD for the left stick, and so on), and every binding can be edited per game; physical controllers work too. The first launch converts the game, and later launches reuse that work. The second runtime, [Prosper](https://github.com/mattias800/prosper), runs the original PS5 programs instead of converting them. Play downloads a missing package after consent and continues preparation. **Runtimes** lists packages from MacLauncher Builds and also accepts local builds. Prosper runs as an Intel program, using Rosetta on Apple Silicon, and needs Vulkan 1.4 with Intel support. AnyPS5 stays the default. The game type's inspection and decompilation tools work with either runtime. **Example games:** titles the AnyPS5 project is bringing up include Ghost of Tsushima Director's Cut, Forspoken, Skyrim and Diablo II: Resurrected. Each has a [bring-up thread](https://github.com/boykopovar/AnyPS5/discussions/categories/game-bring-up) that reports how far the game gets. Guide: [PlayStation 5](https://procrastinine.github.io/maclauncher/reference/game-types/PS5.md) ## Nintendo Switch The Switch runs on an ARM64 processor, like Apple Silicon, so its game code can run directly on your Mac once it's prepared. [nxnative](https://github.com/seedds/nxnative) supplies the system services and converts the graphics to Metal. Import an `.nsp`, `.nsz`, `.xci` or `.xcz` file, or a folder of them. The first launch extracts the game, patches its code and compiles its shaders, showing progress as it goes. That can take a while, and later launches start straight away. Encrypted games need your own `prod.keys` file, which you can select in the game's Runtime Settings. If shader compilation needs Apple's Metal compiler, MacLauncher can download it, and Xcode isn't needed. nxnative has fixed keyboard controls (WASD for the left stick, J/K/U/I for A/B/X/Y, and so on), which Settings shows for reference, and supported controllers work natively. After the first preparation, the game's own options from nxnative appear in Runtime Settings. **Example games:** Mario Kart 8 Deluxe, The Legend of Zelda: Breath of the Wild, Super Mario Odyssey, from [nxnative's list of tested games](https://github.com/seedds/nxnative). Guide: [Nintendo Switch](https://procrastinine.github.io/maclauncher/reference/game-types/SWITCH.md) ## Bringing your own games MacLauncher doesn't provide games, keys or firmware. For Android, the built-in store downloads cover apps you own or that are free. For iOS, PS5 and Switch, you need your own decrypted copies and keys. --- # Mac apps, retro and more > Native macOS apps and scripts, 32-bit Mac apps, DOS games on DOSBox Staging, ScummVM adventure games, Infinity Engine games on GemRB, Half-Life on Xash3D FWGS, MUGEN, HashLink and video playback. Web page: https://procrastinine.github.io/maclauncher/games/more/ This page covers the remaining game types that MacLauncher plays on a Mac, from Mac apps you already have to DOS games, classic adventure games and videos. ## Mac apps and scripts Mac apps, scripts and executables that no engine-specific game type claims are imported as the macOS Game type, and they run as they are. MacLauncher still adds a few things: - The graphics layer gives any Mac app or game shaders, upscaling and frame generation. The app doesn't have to be a game. - Indie Mac builds downloaded from the web are often blocked by [Gatekeeper](https://support.apple.com/guide/security/gatekeeper-and-runtime-protection-sec5599b66df/web)'s quarantine and reported as "damaged". **Remove quarantine** in the inspector clears it. - Scripts (`.sh`, `.command`, Python and others) and bare Mac executables can be launched from the library. **Make executable** fixes a missing permission bit. - Your Mac games sit in the same library as everything else, with the same notes, tools and launchers. ### 32-bit Mac apps macOS [dropped support for 32-bit apps](https://support.apple.com/en-us/103076) in Catalina, which stranded a lot of older Mac games. MacLauncher can run them again with the 32-bit Mac runtime, [mac32](https://github.com/Shagulka/mac32), which loads a 32-bit Intel app inside a 64-bit process and bridges its system calls to current macOS. It is picked automatically for apps that are only 32-bit, such as the old Mac build of [Portal 2](https://store.steampowered.com/app/620/Portal_2/). Each mac32 release states the macOS version it needs, which MacLauncher reads from the download, and on Apple Silicon it also needs [Rosetta](https://support.apple.com/en-us/102527). Guides: [macOS Game](https://procrastinine.github.io/maclauncher/reference/game-types/MACOS.md), [32-bit Mac](https://procrastinine.github.io/maclauncher/reference/game-types/MACOS.md#32-bit-mac) ## DOS games DOS games run on [DOSBox Staging](https://www.dosbox-staging.org/). This one really is an emulator, which is fine: these games are tiny, and the PCs they expect no longer exist. Import the game's folder, or its `.exe`, `.com` or `.bat` file when the folder has several programs, and play. **Example games:** DOOM, Prince of Persia. Guide: [DOS](https://procrastinine.github.io/maclauncher/reference/game-types/DOS.md) ## Classic adventure games [ScummVM](https://www.scummvm.org/) runs hundreds of point-and-click adventures from their original data files: LucasArts [SCUMM](https://en.wikipedia.org/wiki/SCUMM) games, Sierra's SCI and AGI games, Adventure Game Studio games and many more. Common layouts are recognized on import as the ScummVM game type, and ScummVM itself is downloaded when you first press Play. **Example games:** The Secret of Monkey Island, Day of the Tentacle. Guide: [ScummVM](https://procrastinine.github.io/maclauncher/reference/game-types/SCUMMVM.md) ## Infinity Engine [Infinity Engine](https://en.wikipedia.org/wiki/Infinity_Engine) games and mods, the Baldur's Gate family, run on [GemRB](https://gemrb.org/), which plays the original game data as a native macOS program. [Near Infinity](https://github.com/Argent77/NearInfinity) is available in the inspector for browsing and editing their resources. **Example games:** Baldur's Gate, Planescape: Torment and Icewind Dale. Guide: [Infinity Engine](https://procrastinine.github.io/maclauncher/reference/game-types/INFINITY_ENGINE.md) ## Half-Life [Half-Life](https://store.steampowered.com/app/70/HalfLife/) runs on [Xash3D FWGS](https://github.com/FWGS/xash3d-fwgs), an open-source engine compatible with GoldSrc, the engine Valve built for the original game. It plays your copy's data as a native Mac program on Apple Silicon or Intel, without WINE. Import your Half-Life folder, such as the Steam installation, and press **Play**: the engine and Half-Life's game code are downloaded the first time. Mods that run on Half-Life's own game code, such as map packs, work the same way when you import the mod's folder from inside the Half-Life folder. Mods that bring their own Windows game code, Opposing Force and Blue Shift among them, can't load into a Mac engine, so they run through [Sikarugir or CrossOver](https://procrastinine.github.io/maclauncher/games/windows.md) from the Half-Life entry instead. Saves and settings stay in MacLauncher's data, and the game folder itself is never changed. Guide: [Half-Life (Xash3D FWGS)](https://procrastinine.github.io/maclauncher/reference/game-types/HALF_LIFE.md) ## MUGEN and Ikemen GO [MUGEN](https://en.wikipedia.org/wiki/Mugen_(game_engine)) fighting-game content runs on [Ikemen GO](https://github.com/ikemen-engine/Ikemen-GO), an engine compatible with MUGEN characters, stages and screenpacks. Ikemen GO 1.0 runs on Apple Silicon with macOS 14 or later, and version 0.99 is an Intel build that runs directly on Intel Macs and through Rosetta on Apple Silicon. Guide: [MUGEN / Ikemen GO](https://procrastinine.github.io/maclauncher/reference/game-types/MUGEN.md) ## HashLink and Haxe [Haxe](https://haxe.org/) games compiled for the [HashLink](https://hashlink.haxe.org/) virtual machine run on HashLink, using its Intel VM through Rosetta on Apple Silicon. Haxe games compiled to native Windows code instead are a separate game type, Haxe native build. They have no Mac runtime, so MacLauncher identifies and inspects them and plays them through Sikarugir or CrossOver. **Example games:** Dead Cells and Northgard (HashLink). Guides: [HashLink](https://procrastinine.github.io/maclauncher/reference/game-types/HASHLINK.md), [Haxe native build](https://procrastinine.github.io/maclauncher/reference/game-types/HAXE.md) ## Videos MacLauncher also plays videos, through [mpv](https://mpv.io/), so that the same upscalers, anime-oriented shaders, neural restoration and effect chains you use for games work on video too. mpv comes in Apple Silicon and Intel builds, and the Intel build of mpv 0.41 needs macOS 15. The effects have their own [hardware requirements](https://procrastinine.github.io/maclauncher/reference/runtimes/SYSTEM_REQUIREMENTS.md#graphics). Drop in a video file, or a folder of videos to get a playlist. Playback resumes where you stopped, and subtitles are supported. The [uosc](https://github.com/tomasklaen/uosc) interface and [thumbfast](https://github.com/po5/thumbfast) timeline previews are on by default once you install them in **Runtimes**, and you can add other mpv plugins too. You can also preview a video with your effects applied and export the result. Guide: [Video](https://procrastinine.github.io/maclauncher/reference/game-types/VIDEO.md) --- # Graphics and effects > How MacLauncher's Metal graphics layer applies shaders, upscaling, neural models and frame generation to games on macOS, and how a chain of effects fits together. Web page: https://procrastinine.github.io/maclauncher/graphics/ Every game you play through MacLauncher passes through the same graphics layer on its way to your Mac's screen. The layer runs on [Metal](https://developer.apple.com/metal/), takes each finished image from the runtime that drew it, and lets you process that image before it reaches the window. You can upscale it, sharpen it, clean it up with a neural network, give it the look of a CRT screen, insert generated frames between real ones, or combine several of these. The same layer serves native Mac apps, [Godot](https://github.com/godotengine/godot) and [RPG Maker](https://www.rpgmakerweb.com/) games, visual novels, Android and iOS games, browser games, videos and Windows games running in [CrossOver](https://www.codeweavers.com/crossover/). Anything MacLauncher can launch can have effects applied to it, and on macOS 15.2 or later so can [the window of any other app, or a whole display](https://procrastinine.github.io/maclauncher/graphics/window-graphics.md). The graphics layer works on Intel and Apple Silicon Macs, though some effects need more: MLX models and Metal 4 features need Apple Silicon and a newer macOS, and the libplacebo and ISF shader providers follow the requirements of the selected graphics package. MetalFX support depends on your GPU, which MacLauncher checks directly. An effect your Mac can't run is switched off without affecting the others. [Macs and macOS versions](https://procrastinine.github.io/maclauncher/macs-and-macos.md#graphics-features-by-macos-version) lists which features need which macOS version, and the [requirements reference](https://procrastinine.github.io/maclauncher/reference/runtimes/SYSTEM_REQUIREMENTS.md#graphics) has the complete tables. *Image comparison, Original pixels and CRT + Colour: Sonic and Tails in Chemical Plant Zone, Sonic the Hedgehog 2.* Sonic the Hedgehog 2 draws its world at 320×240. Here it is scaled 4× with nearest neighbor, and the same frame through the built-in CRT effect and a touch of Colour. Drag the divider to compare. ## The chain Effects live in an ordered list called the chain, which holds up to 32 rows. The image enters at the top, each row does one thing to it, and the image that leaves the last row is fitted to the window. A chain can be a single sharpening pass or something longer, for example: 1. Downsample the game's image to 720p, so the expensive steps have fewer pixels to process. 2. Run a neural model on that smaller image. 3. Upscale the result to the window with [MetalFX](https://developer.apple.com/documentation/metalfx). 4. Add frame generation to raise the frame rate shown on screen. 5. Apply a CRT shader to the final image. You choose the order, and the order changes the result. A CRT effect looks different before and after an upscaler, and sharpening before a neural model looks different from sharpening after it. [Building a chain](https://procrastinine.github.io/maclauncher/graphics/composing-effects.md) explains how rows interact. ## Simple and Advanced The inspector's **Graphics** section shows the chain in two views. **Simple** has one dropdown for each group of methods: **Image filters**, **Resize** (Downsample and Upscale) and **Temporal** (temporal upscaling and frame generation). You pick a method in a group, and Simple chooses the working sizes for it. **Advanced** shows every row in order. **Add effect…** adds an image filter, a downsample, an upscale, a temporal upscaler or a frame generator. Each row can be dragged to a new position, resized, adjusted and switched on or off. Both views edit the same chain, so switching between them loses nothing. To try both views, open the [interactive demo](https://procrastinine.github.io/maclauncher/demo/), select a game and scroll its inspector to **Graphics**. Picking an effect there brings up the article about it. ## The Graphics heading Clicking the **Graphics** heading opens and closes the section. While the section is closed, the heading summarizes the active effects. Its checkbox turns the whole chain off and on without changing any of it, so a chain can be set aside and restored later. The **⋯** menu beside the heading applies a saved preset, saves the current chain with **Save as preset…**, opens **Manage presets…**, or empties the chain with **Clear effects**. Presets let you reuse a chain on other games. After you apply a preset or clear the chain, **Undo** brings back the previous chain until your next edit. ## Changes apply live Edits apply while the game runs, in a window or fullscreen, whenever the game's graphics adapter supports live changes; otherwise the inspector says they take effect at the next launch. Shaders compile and models load in the background while the game keeps drawing. A few settings depend on a renderer integration that is set up when the game starts, and their controls say so. **Output → Compare** shows the untouched source, a split view, or the difference between the source and the processed image, which makes it easy to see what an effect changes. **Output → Performance overlay** draws frame rates, GPU time and latency over the game, which shows what an effect costs; [Performance and presentation](https://procrastinine.github.io/maclauncher/graphics/composing-effects.md#performance-and-presentation) describes it together with the frame-rate cap and display settings. ## Two kinds of input Most effects need only the finished picture. Color filters, spatial upscalers, neural upscalers, CRT shaders and some frame generators work on any game, because every game produces a picture. Some effects need more. Temporal upscalers such as MetalFX Temporal, [FSR](https://github.com/GPUOpen-LibrariesAndSDKs/FidelityFX-SDK) 2 to 4 and [XeSS](https://github.com/intel/xess), scene-based frame generators, and depth effects such as ambient occlusion and depth of field also use data from the game's renderer: its depth buffer (how far away each pixel is), its motion vectors (how each pixel moved since the previous frame) or its camera data. Only some runtimes pass that data to MacLauncher, so these effects run in some games and not others. When a game doesn't supply what an effect needs, the menus list the effect under **Needs scene inputs**. ## Where to go next - [Upscaling](https://procrastinine.github.io/maclauncher/graphics/upscaling.md): Nearest, bilinear, MetalFX, FSR, Lossless Scaling and shader upscalers, plus temporal upscaling. - [Neural upscaling and restoration](https://procrastinine.github.io/maclauncher/graphics/neural-restoration.md): Real-ESRGAN, Real-CUGAN, RTX VSR, DLSS neural rendering and NAFNet. - [Frame generation](https://procrastinine.github.io/maclauncher/graphics/frame-generation.md): Lossless Scaling, RIFE, MLX interpolation, VideoToolbox, Vision optical flow, MetalFX, FSR 3 and XeSS. - [CRT and retro](https://procrastinine.github.io/maclauncher/graphics/crt-and-retro.md): CRT Royale, Lottes, Easymode and other CRT shaders, plus motion clarity. - [Color, light and sharpening](https://procrastinine.github.io/maclauncher/graphics/color-and-light.md): Colour, CAS, local contrast, bloom, lens effects, depth fog and LUTs. - [Building a chain](https://procrastinine.github.io/maclauncher/graphics/composing-effects.md): How effects combine, processing sizes, presets and the performance overlay. - [Shader collections and imports](https://procrastinine.github.io/maclauncher/graphics/shaders.md): ReShade, RetroArch Slang, mpv, MagpieFX and ISF shaders. - [Any window or display](https://procrastinine.github.io/maclauncher/graphics/window-graphics.md): The same chain on another app's window, in place or scaled to fill the screen, or on a whole display. The repository's [graphics guide](https://procrastinine.github.io/maclauncher/reference/graphics/README.md) describes every control in full, starting with [how the chain works](https://procrastinine.github.io/maclauncher/reference/graphics/README.md#how-the-chain-works). The [algorithm reference](https://procrastinine.github.io/maclauncher/reference/graphics/PROVIDERS.md) lists each algorithm with its exact inputs and requirements. > **About the sample images:** > The before-and-after images in this section were made by running still images through MacLauncher's own **Export video…** pipeline, the same graphics chain games use, and saving a frame of the result. The example games and their copyright notices are listed on the [credits page](https://procrastinine.github.io/maclauncher/about/credits.md). --- # Upscaling > Upscaling games on macOS, from nearest-neighbor pixels to MetalFX, AMD FSR 1 to 4, Lossless Scaling LS1, Intel XeSS and other temporal upscalers. Web page: https://procrastinine.github.io/maclauncher/graphics/upscaling/ Games often draw fewer pixels than your Mac's display has, and upscaling enlarges their image to fill it. A pixel-art game might render at 320×180, an older 3D game at 720p, and a demanding one at whatever resolution keeps it running smoothly. On a Retina screen, the method chosen for that enlargement changes the result considerably. An **Upscale** row in the effect chain does the enlarging. By default it fills the window or the fullscreen surface; it can also use a fixed size or a multiple of its input. The samples below enlarge two very different images 4× with each method, cropped so individual pixels are visible: a frame of [Celeste](https://store.steampowered.com/app/504230/Celeste/), which draws its pixel art at 320×180, and a frame of Ciri from [The Witcher 3: Wild Hunt](https://store.steampowered.com/app/292030/The_Witcher_3_Wild_Hunt/), reduced to 480×270. Choose a game, then a method; the method stays selected when you switch games. **Celeste** **Nearest** *Image: Madeline among wind-blown flags in Celeste, enlarged with nearest neighbor, with sharp square pixels.* Nearest neighbor: every source pixel becomes a crisp 4×4 block. Exactly what the artist drew. **Bilinear** *Image: The Celeste frame enlarged with bilinear filtering, visibly blurry.* Bilinear: smooth, but pixel art turns to mush. **FSR 1** *Image: The Celeste frame enlarged with FSR 1.* AMD FSR 1: edge-aware enlargement followed by sharpening. Smoother than bilinear, but pixel corners still round off. **MetalFX** *Image: The Celeste frame enlarged with MetalFX Spatial.* MetalFX Spatial: Apple's reconstruction filter, built into macOS. It rounds the pixel corners off. **MAKO** *Image: The Celeste frame enlarged with MAKO spatial scaling.* MAKO: spatial reconstruction with its own sharpening. **xBRZ** *Image: The Celeste frame enlarged with xBRZ.* xBRZ 4×, a pixel-art scaler from the libretro Slang collection: diagonal edges are smoothed while flat areas stay flat. **SABR** *Image: The Celeste frame enlarged with SABR.* SABR, another libretro pixel-art scaler, with softer, rounder edges. **Real-ESRGAN** *Image: The Celeste frame enlarged with Real-ESRGAN.* Real-ESRGAN General 4×, a neural model. It redraws the scene with smooth, outlined shapes, which suits photos and 3D far better than pixel art. **The Witcher 3** **Nearest** *Image: Ciri enlarged with nearest neighbor, blocky.* Nearest neighbor: the same 4×4 blocks make a smooth image look jagged. **Bilinear** *Image: Ciri enlarged with bilinear filtering.* Bilinear: soft all over. **FSR 1** *Image: Ciri enlarged with FSR 1.* AMD FSR 1: a step crisper than bilinear and gentler than MetalFX. **MetalFX** *Image: Ciri enlarged with MetalFX Spatial.* MetalFX Spatial: crisp edges in the hair and face. **MAKO** *Image: Ciri enlarged with MAKO.* MAKO: sharp, close to MetalFX. **xBRZ** *Image: Ciri enlarged with xBRZ.* xBRZ: made for pixel art, it flattens skin and hair into blotchy patches. **SABR** *Image: Ciri enlarged with SABR.* SABR: the same flat patches as xBRZ. **Real-ESRGAN** *Image: Ciri enlarged with Real-ESRGAN.* Real-ESRGAN General 4×, a neural model: the cleanest edges, with skin and hair smoothed into a slightly painted look. No method is best for everything. Pixel art usually looks right with **Nearest**, ideally at a whole-number scale so every pixel stays the same size. Smooth, detailed images such as 3D games, painted visual novel backgrounds and video benefit from a reconstruction filter instead: *Image comparison, Bilinear and MetalFX Spatial: Ciri from The Witcher 3, enlarged 4× from 480×270.* A frame of Ciri from The Witcher 3: Wild Hunt, reduced to 480×270 and enlarged 4×. MetalFX Spatial brings back much more edge detail in the hair and face than plain bilinear filtering, with a little sharpening halo. ## Spatial upscalers These use a single finished image, so they work with every game. - **Nearest**, **Bilinear** and **Bicubic** are the classic filters. Nearest copies pixels, bilinear blends neighboring pixels, and bicubic blends a wider neighborhood for a little more sharpness. - **[libplacebo](https://libplacebo.org/) filters** add the kernels used by video players, such as Lanczos, EWA Lanczos, Spline36, Mitchell and Catmull-Rom. Their macOS requirement comes from the selected graphics package; the [requirements reference](https://procrastinine.github.io/maclauncher/reference/runtimes/SYSTEM_REQUIREMENTS.md#graphics) lists it. - **[MetalFX Spatial](https://developer.apple.com/documentation/metalfx)** is Apple's upscaler, built into macOS 13 and later and available on Macs whose GPU supports it. - **[AMD FSR 1](https://github.com/GPUOpen-Effects/FidelityFX-FSR)** is AMD's edge-adaptive upscaler with its RCAS sharpening pass, ported to [Metal](https://developer.apple.com/metal/). Its **Sharpness** control runs from 0 to 1. - **[MAKO](https://github.com/eugeniosegala/MAKO)** spatial scaling is another reconstruction filter, with sharpening built in. - **[Lossless Scaling](https://store.steampowered.com/app/993090/Lossless_Scaling/) LS1** is the upscaler from Lossless Scaling. It uses the model files from your own purchased copy, which **Runtimes → Graphics → Upscaling** can import or download through [Steam](https://store.steampowered.com/). [Getting Lossless Scaling files](https://procrastinine.github.io/maclauncher/graphics/frame-generation.md#getting-lossless-scaling-files) describes the options. ## Shader upscalers Shader collections add many upscalers written for video players and emulators, and most of them are tuned for one kind of image: - [Anime4K](https://github.com/bloc97/Anime4K), [ArtCNN](https://github.com/Artoriuz/ArtCNN), [CuNNy](https://github.com/funnyplanter/CuNNy) and [ACNet/ARNet](https://github.com/TianZerL/ACNetGLSL) are made for anime and line art. They are small neural networks that run as ordinary GPU shaders, and they often suit visual novels well. - [FSRCNNX](https://github.com/iwalton3/default-shader-pack), [RAVU and NNEDI3](https://github.com/bjin/mpv-prescalers) are made for general video, as is the included SSimSuperRes pass, which refines an upscaled image against its lower-resolution source. - [xBRZ](https://github.com/libretro/slang-shaders/tree/master/edge-smoothing/xbrz), [SABR](https://github.com/libretro/slang-shaders/tree/master/edge-smoothing/sabr) and the other pixel-art scalers in the [libretro Slang collection](https://github.com/libretro/slang-shaders) smooth diagonal edges while keeping the hand-drawn look of pixel art. A shader that always doubles its input appears as an Upscale with its 2× scale, and a later resize row can fit the result to the window. [Shader collections and imports](https://procrastinine.github.io/maclauncher/graphics/shaders.md) covers installing collections, and [Neural upscaling and restoration](https://procrastinine.github.io/maclauncher/graphics/neural-restoration.md) covers the heavier model-based upscalers. ## Temporal upscalers A spatial upscaler has one image to work from, while a temporal upscaler gathers detail across several frames. The game renders each frame with a tiny sub-pixel offset called jitter, and the upscaler uses the game's depth buffer and motion vectors to line those frames up and rebuild a sharper picture. Modern games use this technique to render a fraction of the pixels and still look sharp. MacLauncher includes these temporal upscalers: - **[MetalFX Temporal](https://developer.apple.com/documentation/metalfx)**, plus its [denoised variant](https://developer.apple.com/documentation/metalfx/mtlfxtemporaldenoisedscaler) on macOS 26 or later - **AMD [FSR 2.2](https://github.com/GPUOpen-Effects/FidelityFX-FSR2)**, **[FSR 3.1](https://github.com/GPUOpen-LibrariesAndSDKs/FidelityFX-SDK)** and **[FSR 4.1](https://github.com/UzenUPoZiTiV4ik/fsr4-native-macos)**; FSR 4.1 has Exact Fast, Lite and Lite 2 profiles and needs Apple Silicon with macOS 15 or later - **[Arm ASR](https://github.com/arm/accuracy-super-resolution-generic-library)** and **[Snapdragon GSR 2](https://github.com/SnapdragonGameStudios/snapdragon-gsr)** - **[Intel XeSS](https://github.com/intel/xess)**, which runs through D3DMetal or KosmicKrisp on Apple Silicon - **DLSS SR** for scenes, through [MLX-DLSS](https://github.com/iamwavecut/MLX-DLSS) All of them need depth, motion and camera data from the game itself, which a finished picture cannot supply. They run only in games whose runtime passes that data to MacLauncher; for other games, the spatial and neural upscalers are the options. ## Render size versus window size Upscaling pairs well with rendering fewer pixels in the first place. Two separate controls reduce the size. **Game resolution** asks the game itself to render at a smaller size, which saves the game real work. When the game's renderer can't change its size, MacLauncher uses a virtual window if one is available, and otherwise shrinks the finished image before the effects run. That fallback saves work in the effects but not in the game's own rendering. A **Downsample** row shrinks an image that has already been rendered. The game doesn't get faster, but every effect after the row has fewer pixels to process, which matters most for neural models. In both cases the window keeps its size, and only the processing resolution changes. [Building a chain](https://procrastinine.github.io/maclauncher/graphics/composing-effects.md) has more on sizes. The graphics guide's [size section](https://procrastinine.github.io/maclauncher/reference/graphics/README.md#rendering-processing-and-output-size) describes every size option, and the algorithm reference lists the requirements of each [spatial](https://procrastinine.github.io/maclauncher/reference/graphics/PROVIDERS.md#spatial-resizing) and [temporal](https://procrastinine.github.io/maclauncher/reference/graphics/PROVIDERS.md#scene-temporal-upscaling) upscaler. ## Further reading - [Image scaling](https://en.wikipedia.org/wiki/Image_scaling) and [pixel-art scaling algorithms](https://en.wikipedia.org/wiki/Pixel-art_scaling_algorithms) on Wikipedia, with side-by-side examples of the classic filters and pixel-art scalers. - AMD's [FSR 2 overview](https://gpuopen.com/fidelityfx-superresolution-2/), a readable introduction to how temporal upscalers use jitter, depth and motion vectors. --- # Neural upscaling and restoration > Real-ESRGAN, Real-CUGAN and NAFNet, and NVIDIA's DLSS and RTX VSR models through the MLX-DLSS port, running on Apple Silicon Macs with MLX and Metal. Web page: https://procrastinine.github.io/maclauncher/graphics/neural-restoration/ Neural upscaling and restoration use trained models, running on a Mac's GPU, to enlarge or repair a game's image. Ordinary upscalers fill in new pixels by fixed rules. A neural model, by contrast, is trained on many images and learns what images tend to look like, such as how a line in an anime drawing continues, what grass looks like up close, or which fine patterns are noise rather than detail. Given a small or damaged image, the model redraws it from what it learned. MacLauncher runs these models on your Mac's GPU through [MLX](https://github.com/ml-explore/mlx) and [Metal](https://developer.apple.com/metal/), inside the same graphics chain as every other effect. They need an Apple Silicon Mac with macOS 14 or later. Intel games running translated under [Rosetta](https://support.apple.com/en-us/102527) or [CrossOver](https://www.codeweavers.com/crossover/) can use them as well, because a small Apple Silicon helper runs the model on their behalf. ## Upscaling drawn art Neural upscalers do especially well on visual novels and anime-style games. This scene from [CLANNAD](https://store.steampowered.com/app/324160/CLANNAD/) was reduced to 640×480 and then doubled: *Image comparison, Bilinear 2× and Real-CUGAN 2×: Nagisa under the cherry blossoms in CLANNAD, upscaled 2× from 640×480.* Real-CUGAN redraws line work and flat color cleanly where bilinear filtering only blurs. The lighter shader upscalers from the [shader collections](https://procrastinine.github.io/maclauncher/graphics/shaders.md) aim at the same kind of image and cost far less: **Real-CUGAN** *Image: The CLANNAD scene upscaled with Real-CUGAN 2× Conservative.* Real-CUGAN 2× (Conservative), a neural model. **Anime4K** *Image: The CLANNAD scene upscaled with Anime4K Upscale CNN x2 M.* Anime4K Upscale CNN x2 M, a GPU shader. **ArtCNN** *Image: The CLANNAD scene upscaled with ArtCNN C4F32.* ArtCNN C4F32, a GPU shader. **Bilinear** *Image: The CLANNAD scene upscaled with bilinear filtering.* Plain bilinear filtering, for reference. At 4× the differences grow. This is the same scene, starting from only 320×240: **Real-ESRGAN Anime** *Image: The CLANNAD scene upscaled 4× with Real-ESRGAN Anime.* Real-ESRGAN Anime 4×. **Real-CUGAN 4×** *Image: The CLANNAD scene upscaled 4× with Real-CUGAN.* Real-CUGAN 4× (Conservative). **Bilinear** *Image: The CLANNAD scene upscaled 4× with bilinear filtering.* Bilinear 4×. ## Upscaling everything else [Real-ESRGAN](https://github.com/xinntao/Real-ESRGAN)'s **General** model handles 3D games and other rendered or photographic images rather than line art: *Image comparison, Bilinear 4× and Real-ESRGAN General 4×: Geralt from The Witcher 3, upscaled 4× from 480×270.* Geralt in The Witcher 3: Wild Hunt, reduced to 480×270 and enlarged 4×. Real-ESRGAN rebuilds hair, beard and chain mail where bilinear filtering only blurs them. On pixel art, the same model behaves very differently. It treats the pixels as detail to smooth over and redraws the scene with soft, outlined shapes, which is why pixel-art games usually stay with Nearest or a [pixel-art scaler](https://procrastinine.github.io/maclauncher/graphics/upscaling.md): *Image comparison, Nearest 4× and Real-ESRGAN General 4×: Madeline among wind-blown flags in Celeste, enlarged 4× from 320×180.* Celeste at its native 320×180, enlarged 4×. ## Cleaning up an image Not every model changes the size. [NAFNet](https://github.com/megvii-research/NAFNet) restores an image at its original resolution, with one model for noise and another for blur: *Image comparison, Noisy and NAFNet SIDD: A close-up of Geralt from The Witcher 3 with heavy added noise.* NAFNet's SIDD model removing heavy added noise. *Image comparison, Motion blur and NAFNet GoPro: A close-up of Ciri from The Witcher 3 with added motion blur.* NAFNet's GoPro model reversing added motion blur. ## The models | Model | What it does | Output size | | --- | --- | --- | | Real-ESRGAN | Anime and General upscalers. General has a paired denoising model, and when both are installed, the **Denoising** control blends between them. | 4× | | [Real-CUGAN](https://github.com/bilibili/ailab/tree/main/Real-CUGAN) | Upscaler trained on anime, in Conservative, No denoising and Denoise variants. | 2×, 3× or 4× | | RTX Video Super Resolution | NVIDIA's video upscaler, through [MLX-DLSS](https://github.com/iamwavecut/MLX-DLSS). | 2× | | DLSS neural rendering | The DLSS 5 neural rendering model through MLX-DLSS. It redraws the image toward a photoreal look, blended in with **Intensity**, and can keep image history with **Temporal reconstruction**. | Same size | | DLSS SR (image) | DLSS super resolution working from a sequence of finished images. | 2× | | NAFNet | SIDD (denoising) and GoPro (deblurring) restoration models. | Same size | MacLauncher's other neural models are [RIFE](https://github.com/hzwer/Practical-RIFE) and MLX interpolation for [frame generation](https://procrastinine.github.io/maclauncher/graphics/frame-generation.md), and [Depth Anything V2](https://github.com/DepthAnything/Depth-Anything-V2), which estimates depth from a flat image for the [estimated depth fog](https://procrastinine.github.io/maclauncher/graphics/color-and-light.md#depth-without-a-depth-buffer) effect. Real-ESRGAN and NAFNet build on the existing [Real-ESRGAN MLX](https://github.com/xocialize/mlx-realesrgan-swift) and [NAFNet MLX](https://github.com/xocialize/mlx-nafnet-swift) ports; Real-CUGAN runs its original models on MLX. ## Getting models MacLauncher doesn't include model files. **Runtimes → Graphics → Neural models** lists the supported downloads: **Install** downloads one, and **Import model…** adds a model you already have. Installed models work offline and are shared by every game. Each neural row in the chain has a **Model** menu. **Automatic** chooses an installed model for that row's operation, starting with the default you set for the operation in **Neural models**. You can also pick a specific model for one row. If a row's model is missing, the row shows **Model needed** and the rest of the chain keeps running. ## Keeping it fast A neural model's cost grows with the number of pixels it processes, so the usual approach is to give it a smaller image. Put a **Downsample** row before the model, or lower the **Game resolution**, and fill the window afterward with a fast upscaler such as [MetalFX](https://developer.apple.com/documentation/metalfx). [Building a chain](https://procrastinine.github.io/maclauncher/graphics/composing-effects.md) shows a complete example. If the model still can't keep up with the game, frame generation can fill in the missing frames. The graphics guide's [neural models section](https://procrastinine.github.io/maclauncher/reference/graphics/README.md#neural-models) lists every download and setting, and [Neural models and packages](https://procrastinine.github.io/maclauncher/reference/graphics/NEURAL_RESTORATION.md) describes the model architectures and import formats. ## Further reading - [Super-resolution imaging](https://en.wikipedia.org/wiki/Super-resolution_imaging) on Wikipedia, for the broader field these models come from. - The [Real-ESRGAN](https://github.com/xinntao/Real-ESRGAN), [Real-CUGAN](https://github.com/bilibili/ailab/tree/main/Real-CUGAN) and [NAFNet](https://github.com/megvii-research/NAFNet) project pages, each with its own comparisons and papers. --- # Frame generation > Frame generation for games on macOS: Lossless Scaling frame generation (LSFG) from a purchased copy, RIFE, VideoToolbox, Vision optical flow, MetalFX, FSR 3 and XeSS. Web page: https://procrastinine.github.io/maclauncher/graphics/frame-generation/ Frame generation makes motion look smoother in games that run at a low frame rate on your Mac. Some games are locked to 30 fps, and in others the game, or the effect chain on top of it, keeps the GPU busy. A frame generator compares two real frames, estimates how things moved between them, and draws one or more in-between images to show in the gaps. In the example below, [RIFE](https://github.com/hzwer/Practical-RIFE) fills the gap in a quick camera move. The two real frames are cut from one screenshot of The Witcher 3: Wild Hunt, and RIFE drew the middle one. **Real frame** *Image: Riders on a road in The Witcher 3, first frame of a camera pan.* The first real frame. **Generated** *Image: The generated in-between frame of the camera pan.* The image RIFE generated. The riders, the windmill and the mountains all sit about halfway between their positions in the two real frames. **Next real frame** *Image: Riders on a road in The Witcher 3, second frame of the camera pan.* The next real frame. Frame generation changes only what the display shows: the game still runs at its own speed and handles input at its original rate. The generated frames do add a little latency, because the generator has to wait for the next real frame before it can draw the ones in between. That trade works well for exploration and story games, while competitive and rhythm games usually play better with frame generation off. ## Two kinds of generators Image-pair generators need only the finished images, so they work with every game: - **[Lossless Scaling](https://store.steampowered.com/app/993090/Lossless_Scaling/) (LSFG)** is the frame generator from Lossless Scaling, using the files from your own purchased copy. It has Quality and Performance modes, 16-bit or 32-bit precision and a motion-estimation scale, and it handles HDR images. - **RIFE** 4.6 is an open neural interpolation model, running through [MLX](https://github.com/ml-explore/mlx) on the GPU. - **MLX interpolation** is NVIDIA's DLSS frame-generation model, running through [MLX-DLSS](https://github.com/iamwavecut/MLX-DLSS). - **VideoToolbox interpolation** is the low-latency frame interpolation in Apple's [VideoToolbox](https://developer.apple.com/documentation/videotoolbox) framework, and it runs on the Mac's Neural Engine. It needs macOS 26 or later. - **MetalFX image interpolation** feeds the [MetalFX](https://developer.apple.com/documentation/metalfx) frame interpolator with motion that VideoToolbox estimates from the two images, so it needs nothing from the game's renderer. It needs macOS 26 or later and a supported GPU. - **Vision optical flow** is adapted from [MetalDuck](https://github.com/Nycolazs/MetalDuck). Apple's [Vision](https://developer.apple.com/documentation/vision) framework measures how each part of the picture moved between the two frames, and the generator shifts both frames along that motion. Where the measurement can't be trusted, it blends the two frames instead. It runs on every Mac that MacLauncher supports. The last three use frameworks that come with macOS, so they need no downloads or model files. The row's **Frame multiplier** sets how many images a generator adds between a pair of real frames. At 3×, for example, it draws two images for every real frame, which takes a 30 fps game toward 90 fps. Most image-pair generators go up to 5×, or four images per pair, while VideoToolbox interpolation offers 2× and 4× and MetalFX image interpolation offers 2×. Image-pair generators also detect repeated frames and scene cuts and skip generation across them, which avoids smeared transitions. Scene generators use the game's depth, motion vectors and camera data, like the [temporal upscalers](https://procrastinine.github.io/maclauncher/graphics/upscaling.md#temporal-upscalers). They draw one image in the middle of each interval between real frames, and they run in games whose runtime supplies that data: - **MetalFX frame interpolation** needs macOS 26 or later and a supported GPU. - **[FSR 3](https://github.com/GPUOpen-LibrariesAndSDKs/FidelityFX-SDK) frame interpolation** is AMD's optical-flow and interpolation passes, ported to [Metal](https://developer.apple.com/metal/). - **[Intel XeSS](https://github.com/intel/xess) frame generation** uses XeSS-FG components that you import separately, and runs through D3DMetal or KosmicKrisp on Apple Silicon. ## Automatic **Automatic** is a generator choice of its own. It runs VideoToolbox interpolation, MetalFX image interpolation or Vision optical flow, preferring them in that order, and measures how long each pair of frames takes. When the generator in use can't keep up with the game's frame rate, the row moves to the next one straight away. After ten seconds with time to spare, it returns to a preferred generator, but never within thirty seconds of leaving it, so the row doesn't flip back and forth. Only the generators that offer the row's multiplier take part: at 3×, that is Vision optical flow alone. A row set to one particular generator always keeps it. ## Keep static content A generator estimates motion across the whole picture, so a menu, subtitle or health bar that stays still while the scene behind it moves can be dragged along with the scene and smeared in the generated images. **Keep static content**, an option of image-pair generator rows that is off by default for games and on by default for window graphics, repairs those areas after generation. It compares the two real frames around each pixel, and wherever they match, it returns the generated pixel to the real one, so interface elements and text stay sharp. The comparison sees only the two real frames. A small object that moves quickly across a detailed area that otherwise stays the same can therefore go missing from the generated images, and turning the option off brings it back. ## Pacing Generated frames look smooth only when they are evenly timed, so the chain's **Output** section has shared pacing settings. **Frame pacing** is either Fixed or Adaptive; Adaptive pacing varies generation, up to the row's multiplier, to approach a **Target frame rate** between 30 and 240 fps, within the display's actual refresh rate. **Smooth cadence** favors evenly spaced frames. These settings change only the images sent to the display, never the game's simulation. With window graphics, a generator draws only the images that the display can actually show, under Fixed and Adaptive pacing alike. For example, a window captured at 60 fps already fills a 60 Hz display, so a 2× row passes the real frames through and its **Details** give the reason. At 30 fps, the same display has room for one generated image between each pair of real frames. Each image is also timed to fall between two display refreshes, which keeps two images from landing on the same refresh and keeps small timing variations from moving an image to the wrong one. A game whose frame rate swings up and down can be held at a steady rate with the [Frame-rate cap](https://procrastinine.github.io/maclauncher/graphics/composing-effects.md#frame-rate-cap) in the same section, and the [performance overlay](https://procrastinine.github.io/maclauncher/graphics/composing-effects.md#performance-overlay) shows the captured, displayed and generated frame rates during play. For decoded video with content timestamps, generation fills the whole gap between two decoded frames, even at low frame rates or in slowed playback. Playback works one frame ahead so the in-between images can fill that gap, and file export uses the same timing and saves those images at their places in the video's timeline. A frame generation row can sit anywhere in the chain. Placed after an expensive neural model, for example, it lets the model run only on the real frames at the game's own frame rate. ## Getting Lossless Scaling files LS1 and LSFG need model files from a copy of Lossless Scaling that you own. **Runtimes → Graphics → Upscaling** offers four ways to get them: - **Import Lossless Scaling DLL…** reads the DLL from a local copy, including one installed through CrossOver. - **Find in Steam / CrossOver** searches Steam libraries and standard CrossOver bottles on your Mac, without going online. - **Download from Steam…** downloads the Windows version through the Mac [Steam](https://store.steampowered.com/) app, which must be signed in to an account that owns Lossless Scaling. - **Use SteamCMD…** downloads it with Valve's SteamCMD, signing in through Terminal, for Macs without the Steam app. MacLauncher reads the DLL without running or changing it and never sees your Steam password or Steam Guard code. Imported models are shared by every game. The graphics guide describes [frame generation](https://procrastinine.github.io/maclauncher/reference/graphics/README.md#frame-generation) and [Lossless Scaling setup](https://procrastinine.github.io/maclauncher/reference/graphics/README.md#lossless-scaling-setup) in full, and the algorithm reference's [frame generation table](https://procrastinine.github.io/maclauncher/reference/graphics/PROVIDERS.md#frame-generation) lists every generator's inputs and requirements. The same reference covers the [generators that use macOS frameworks](https://procrastinine.github.io/maclauncher/reference/graphics/PROVIDERS.md#image-pair-methods-from-macos-frameworks), [Automatic](https://procrastinine.github.io/maclauncher/reference/graphics/PROVIDERS.md#automatic) and [static content](https://procrastinine.github.io/maclauncher/reference/graphics/PROVIDERS.md#static-content) in detail, and the frame API reference describes [display timing](https://procrastinine.github.io/maclauncher/reference/graphics/FRAME_API.md#timing). ## Further reading - [Motion interpolation](https://en.wikipedia.org/wiki/Motion_interpolation) on Wikipedia, the same idea as TV "smooth motion" modes. - [Optical flow](https://en.wikipedia.org/wiki/Optical_flow) on Wikipedia, the estimate of how each part of an image moves that Vision optical flow and most other generators start from. - [Why do some OLEDs have motion blur?](https://blurbusters.com/faq/oled-motion-blur/), Blur Busters on sample-and-hold blur and why higher frame rates look sharper in motion. --- # CRT and retro > CRT Royale, CRT Lottes, Easymode and other CRT shaders for retro and pixel-art games on macOS, with scanlines, phosphor glow and curved glass, plus palette effects and motion clarity. Web page: https://procrastinine.github.io/maclauncher/graphics/crt-and-retro/ For decades, pixel art was drawn for cathode-ray tube (CRT) televisions and monitors, and CRT shaders give pixel-art games on a Mac the look of those screens. Artists knew that the electron beam would soften their pixels, that dark scanlines would separate the rows, and that the picture would glow through a phosphor mask, and they drew with that in mind. The [CRT Pixels](https://primagames.com/featured/interview-crt-pixels-jordan-starkweather-tells-us-why-retro-games-need-retro-screens) project made this widely known with side-by-side close-ups of real tubes. On a modern display every pixel is a hard-edged square, which is crisp but differs from what the artists saw. *Image comparison, Square pixels and Built-in CRT: Sonic and Tails in Chemical Plant Zone, Sonic the Hedgehog 2.* Sonic the Hedgehog 2 (1992) at its native 320×240, enlarged 4×, then through the built-in CRT effect with the simulated content height set to the game's 240 rows. Sprites drawn for a tube change the most. In this frame of Joe Musashi from Shinobi III, the lightning, the robe's shading and the dark rooftops blend into one picture: *Image comparison, Square pixels and CRT Lottes: Joe Musashi throwing a shuriken in Shinobi III.* Shinobi III: Return of the Ninja Master (1993) at its native 320×224, enlarged 4×, through CRT Lottes with its screen and frame size set to 320×224. ## The built-in CRT effect MacLauncher's own **CRT** effect works with every game, and its parameters control the main parts of the look. **Simulated content height** sets how many scanlines to draw; its default of 240 matches many classic games. Set it to the game's original height and the scanlines keep that spacing however you resize the window, or set it to 0 to follow the image size. **Scanline beam width** and **Scanline darkness** set how thick the lit lines are and how dark the gaps between them get. **Pixel softness** and **Phosphor glow** add the gentle blur and bloom of a real tube. **Screen curvature**, **Rounded corners**, **Edge shading** and **Screen edge fade** shape the glass, and **CRT strength** blends the whole effect with the original image. ## More CRT shaders MacLauncher also includes several established CRT shaders, each with a different look: **CRT Royale** *Image: The Sonic 2 frame through CRT Royale.* CRT Royale: a detailed simulation of the phosphor mask, beam shape, halation and screen geometry. **Lottes** *Image: The Sonic 2 frame through CRT Lottes.* CRT Lottes: Timothy Lottes' shader, with a strong shadow mask and bright bloom. **Easymode** *Image: The Sonic 2 frame through CRT Easymode.* CRT Easymode: a clean, bright look with fine scanlines. **GTU** *Image: The Sonic 2 frame through GTU.* GTU: a softer, composite-video style signal. **zfast** *Image: The Sonic 2 frame through zfast CRT.* zfast CRT: lightweight and quick. - **[CRT Royale](https://github.com/akgunter/crt-royale-reshade)** is Alex Gunter's [ReShade](https://reshade.me/) port of TroggleMonkey's widely used shader. - **CRT Lottes**, **CRT Easymode**, **GTU** and **zfast CRT** come from [RSRetroArch](https://github.com/Matsilagi/RSRetroArch)'s ReShade ports of the [RetroArch](https://www.retroarch.com/) originals. Several of these were written for emulators, where the shader knows the console's real resolution. They have **Screen** or **Frame** width and height parameters, which should be set to the game's original resolution so the scanlines line up with its pixels. The Lottes, Easymode, GTU and zfast samples above use Sonic the Hedgehog 2's 320×240, while CRT Royale is shown at its default settings. The [libretro Slang collection](https://github.com/libretro/slang-shaders), available from **Runtimes → Graphics → Shaders → Collections**, adds CRT halation along with pixel-art scalers, dedithering and restoration filters. You can also import any `.slangp` preset you already use in RetroArch, including CRT presets. [Shader collections and imports](https://procrastinine.github.io/maclauncher/graphics/shaders.md) describes both. ## Where a CRT goes in the chain A CRT effect needs several screen pixels for every game pixel to draw its scanlines and mask, so it belongs after the image has been enlarged to the window, usually by a **Nearest** upscale: 1. **Upscale**, Nearest, to the window. 2. **CRT**, with the game's original height. Color effects can go before or after it, depending on whether you want to grade the game or the simulated screen. [Building a chain](https://procrastinine.github.io/maclauncher/graphics/composing-effects.md) has more on ordering. ## Palette and other retro looks The included **Pixel palette** effect reduces each color channel to a few levels, with optional ordered dithering, which gives any game the limited colors of old hardware: *Image comparison, Original and Pixel palette: Riders on a road in The Witcher 3.* Pixel palette with six levels per color channel and its default ordered dithering, on the full 1920×1080 frame from The Witcher 3: Wild Hunt. *Image comparison, Original and Pixel palette: A close-up of the riders.* At 1:1, the dither pattern that stands in for the missing colors. ## Motion clarity A CRT also drew each frame as a brief flash of light. Modern displays keep each frame lit until the next one replaces it, which makes moving objects look less sharp. The **Motion clarity** control in the chain's **Output** section recreates some of the CRT's sharpness. **Black frame insertion** shows dark frames between real ones, and **CRT beam** scheduling spreads each frame over several subframes to imitate a scanning beam. **Subframes**, **Visible duty** and **Brightness** adjust the scheduling, and **Auto** turns it on when a shader in the chain asks for it. The display's refresh rate limits how much room there is for subframes, so high-refresh displays benefit most. The graphics guide lists the CRT effect's parameters under [included effects](https://procrastinine.github.io/maclauncher/reference/graphics/README.md#included-effects) and describes [motion clarity](https://procrastinine.github.io/maclauncher/reference/graphics/README.md#motion-clarity) in full. ## Further reading - [Why retro games need retro screens](https://primagames.com/featured/interview-crt-pixels-jordan-starkweather-tells-us-why-retro-games-need-retro-screens), an interview with the creator of CRT Pixels. - [CRT emulation for pixel art](https://www.gamedeveloper.com/art/opinion-crt-emulation-for-pixel-art), a developer's take on what a convincing CRT simulation needs. - [Why retro games look better on old-school CRT TVs](https://www.slashgear.com/2274532/why-retro-games-look-better-on-old-school-crt-tvs/), from SlashGear. - [CRT simulation in a GPU shader, looks better than BFI](https://blurbusters.com/crt-simulation-in-a-gpu-shader-looks-better-than-bfi/), Blur Busters on rolling-scan CRT simulation for motion clarity. - The [libretro shader introduction](https://docs.libretro.com/shader/introduction/), for RetroArch's shader presets. --- # Color, light and sharpening > Color and tone, CAS sharpening, bloom, lens effects, LUTs, SMAA, CMAA2 and FXAA anti-aliasing, and depth effects for games on macOS. Web page: https://procrastinine.github.io/maclauncher/graphics/color-and-light/ The color, sharpening, lighting and anti-aliasing effects on this page change how a game looks on your Mac without changing its resolution. Many games look better with slightly stronger color or crisper edges, and some of these effects give a game a different mood altogether. They work on the finished image, so they're available for every game, and most are cheap enough to leave on all the time. *Image comparison, Original and Colour: Three riders on a country road toward snowy mountains in The Witcher 3.* A road in The Witcher 3: Wild Hunt at its full 1920×1080, with the built-in Colour effect's saturation raised to 1.6. Its default, 1.2, is a gentler boost. *Image comparison, Original and Colour: A close-up of the riders and wildflowers.* The riders at 1:1, where the saturation boost shows in the saddles, flowers and grass. ## The built-in effects Five effects are part of MacLauncher itself: - **Colour** adjusts saturation. Its default of 1.2 is a little above neutral; 1 leaves color unchanged. - **Sharpen** is classic sharpening. **CAS Sharpen** is AMD's Contrast Adaptive Sharpening, which sharpens soft areas more than areas that are already crisp, and it works well as a finishing pass after an upscaler. - **Grayscale** removes all color. - **CRT** simulates a CRT screen and is covered in [CRT and retro](https://procrastinine.github.io/maclauncher/graphics/crt-and-retro.md). **Combine effects…** runs two to four of these as a single row. ## Other included effects The other included effects come from widely used [ReShade](https://reshade.me/) and video-processing projects, and from native [Metal](https://developer.apple.com/metal/) ports of graphics research: **CAS Sharpen** *Image comparison, Original and CAS Sharpen: The road with CAS Sharpen.* CAS Sharpen at its default strength. *Image comparison, Original and CAS Sharpen: The road with CAS Sharpen, close-up.* At 1:1, the armor, manes and grass gain crisp edges. **Soft bloom** *Image comparison, Original and Soft bloom: The road with soft bloom.* Soft bloom with strength 0.8, threshold 0.55 and radius 8, so the sky and the sunlit path glow. *Image comparison, Original and Soft bloom: The road with soft bloom, close-up.* The glow spreads from the bright path into the riders' outlines. **Lens** *Image comparison, Original and Lens: The road with FidelityFX Lens.* FidelityFX Lens with chromatic aberration raised to 1.5 and grain to 0.3, plus its default vignette. *Image comparison, Original and Lens: The road with FidelityFX Lens, close-up.* Up close, the color fringes and film grain are easy to see. **Kuwahara** *Image comparison, Original and Kuwahara: The road with the anisotropic Kuwahara filter.* Anisotropic Kuwahara at its defaults turns the scene into a painting. *Image comparison, Original and Kuwahara: The road with the anisotropic Kuwahara filter, close-up.* At 1:1, the brush-stroke smoothing follows the shapes of the horses and armor. - Color and tone effects include [SweetFX](https://github.com/CeeJayDK/SweetFX) Tonemap, Vibrance and Curves, color balance, [Halide](https://github.com/halide/Halide)'s **Local Laplacian** filter for detail and contrast, and **Histogram exposure**, which sets exposure automatically from the image's own histogram. - Light and lens effects are soft bloom and AMD [FidelityFX](https://github.com/GPUOpen-LibrariesAndSDKs/FidelityFX-SDK) **Lens** (grain, chromatic aberration and vignette) and **Blur**. - Clean-up effects are threshold debanding for smooth gradients, and [SMAA](https://github.com/iryoku/smaa), [CMAA2](https://github.com/GameTechDev/CMAA2) and FXAA anti-aliasing for jagged edges in games that don't smooth them themselves. FXAA, the version of NVIDIA's fast approximate anti-aliasing that comes with SweetFX, is quick and softens fine detail a little more than the other two. - [Anisotropic Kuwahara](https://github.com/jkyprian/gpuakf) is a painterly filter that smooths the image into brush-stroke-like regions. - **Daltonize** is an accessibility filter. It simulates a color-vision deficiency and shifts the color differences that would be lost into ones that stay visible, with adjustable strength. Shader collections add more: [qUINT](https://github.com/martymcmodding/qUINT) for bloom, grading, debanding and sharpening, [prod80](https://github.com/prod80/prod80-ReShade-Repository) for film-style color grading and LUTs, [CShade](https://github.com/papadanku/CShade) for exposure and image-based motion effects, [FXShaders](https://github.com/luluco250/FXShaders) for NeoBloom and ArcaneBloom, [AstrayFX](https://github.com/BlueSkyDefender/AstrayFX) for indirect lighting, ambient occlusion, anti-aliasing and sharpening, and [OtisFX](https://github.com/FransBouma/OtisFX) for cinematic depth of field, fog and grading. [Shader collections and imports](https://procrastinine.github.io/maclauncher/graphics/shaders.md) lists them all. ## LUTs A LUT (lookup table) is a complete color grade stored in a file, the same kind that photo and video editors use. A `.cube` file dropped onto MacLauncher joins the shader library as an effect, with controls for strength, trilinear or tetrahedral interpolation, and whether the table expects encoded or linear color. Full-size 65-point 3D tables are supported. ## Depth without a depth buffer Fog that thickens with distance needs to know how far away things are, and most games don't pass that information to MacLauncher. **Estimated depth fog** works without it: [Depth Anything V2](https://github.com/DepthAnything/Depth-Anything-V2), a small neural network, estimates depth from the finished picture, and the fog follows that estimate. It works with any game on Apple Silicon once the model is installed. *Image comparison, Original and Estimated depth fog: The road with distance fog toward the mountains.* Estimated depth fog on the full 1920×1080 frame, with a pale haze color and dithering off. ## Effects that use the game's depth Some lighting effects need the game's real depth buffer, and sometimes its camera, surface normals and materials. For games whose runtime provides them, MacLauncher includes: - [XeGTAO](https://github.com/GameTechDev/XeGTAO) and AMD [CACAO](https://github.com/GPUOpen-LibrariesAndSDKs/FidelityFX-SDK) ambient occlusion, which darkens corners and contact points - FidelityFX **depth of field** - depth fog and depth outlines adapted from FXShaders - [Godot](https://github.com/godotengine/godot)'s screen-space reflections - from collections, [SSRT3](https://github.com/cdrinmatane/SSRT3) indirect lighting, the [NiceGuy shaders](https://github.com/mj-ehsan/NiceGuy-Shaders)' lighting, reflections and fog, AstrayFX's RadiantGI and GloomAO, and OtisFX's depth of field and fog When a game doesn't provide those inputs, these effects stay in the menus under **Needs scene inputs**, with a note saying what they need. ## Final output The **Output** section at the end of the effect chain handles the last step to the screen. **Tone mapping** decides how bright highlights are compressed into the display's range, with the choices Automatic, None, Reinhard and PBR Neutral. HDR and wide-gamut images keep their range through the chain, and effects that handle only standard color get a local conversion. The graphics guide lists every [included effect](https://procrastinine.github.io/maclauncher/reference/graphics/README.md#included-effects) and describes [tone mapping](https://procrastinine.github.io/maclauncher/reference/graphics/README.md#tone-mapping) in full. The [algorithm reference](https://procrastinine.github.io/maclauncher/reference/graphics/PROVIDERS.md#shader-formats-and-image-effects) describes each native effect's algorithm. ## Further reading - [Tone mapping](https://en.wikipedia.org/wiki/Tone_mapping), [3D lookup tables](https://en.wikipedia.org/wiki/3D_lookup_table) and the [Kuwahara filter](https://en.wikipedia.org/wiki/Kuwahara_filter) on Wikipedia. - [Ambient occlusion](https://en.wikipedia.org/wiki/Ambient_occlusion), the darkening of corners and contact points that XeGTAO and CACAO estimate. - [Color blindness](https://en.wikipedia.org/wiki/Color_blindness), the background to Daltonize. --- # Building a chain > How MacLauncher combines shaders, upscalers, neural models and frame generation in one effect chain on macOS, with processing sizes, recipes, presets and the performance overlay. Web page: https://procrastinine.github.io/maclauncher/graphics/composing-effects/ MacLauncher combines graphics effects for games on macOS in an effect chain of up to 32 rows, and effects can go in any order and any combination. This page explains how rows interact and how sizes work, and gives a few example chains to start from. ## Top to bottom The image enters at the top of the chain and passes through each enabled row in turn. Each row receives the output of the row above it, so the order changes the result: - Sharpening before an upscaler sharpens the small image, and the upscaler then enlarges the sharpened edges; sharpening after the upscaler works on the final pixels. Both are valid choices with different results. - A CRT effect belongs after the image has been enlarged, so it has enough screen pixels to draw scanlines with. - Color grading before a CRT grades the game, while a grade after the CRT also tints the simulated glass and glow. - An expensive model costs least early in the chain, at a small size, before anything enlarges the image. Rows come in five kinds. **Image filters** keep the size, **Downsample** and **Upscale** change it, and **Temporal upscaling** and **Frame generation** work across frames. When you add a shader, MacLauncher places it by the output size it declares, so a shader that always doubles its input appears as an Upscale. ## Editing rows In **Advanced**, **Add effect…** adds a row of any kind, and dropping a shader file on a row replaces that row's effect. You can drag a row or move it with Option-Up and Option-Down, switch it off to set it aside with its settings intact, or remove it. **Options** holds the row's parameters and size, and **Details** shows what the row is doing while the game runs. A row that can't run as saved, for instance because its shader file is missing, stays off and shows **Needs attention** with the reason, and the rest of the chain keeps running. ## Sizes Every resize row can set its size in three ways: - a scale of the previous image, such as 0.5× or 2× - a fraction of the window or fullscreen surface, such as 100% - a fixed resolution, such as 540p or 1920×1080 A Downsample halves its input by default, and an Upscale fills the window. Fixed-scale models and shaders keep their own scale (a 4× model always outputs 4×), and a later resize row can fit the result to the window. **Options** and **Details** on each row show the actual input and output size it sees. Whatever happens inside the chain, the window keeps the size you gave it, and the last image is fitted to it. A **Downsample** row can also use **Adaptive quality**, which adjusts its working size within bounds you set to stay inside a GPU time budget. ## Recipes ### Pixel art with a CRT 1. **Upscale**: Nearest, to the window. 2. **CRT**: Simulated content height set to the game's original height. 3. **Colour**, for slightly stronger colors. The [overview page](https://procrastinine.github.io/maclauncher/graphics.md) shows this chain on Sonic the Hedgehog 2, and [CRT and retro](https://procrastinine.github.io/maclauncher/graphics/crt-and-retro.md) compares other CRT shaders that can take the place of step 2. ### A sharper visual novel 1. **Upscale**: [Real-CUGAN](https://github.com/bilibili/ailab/tree/main/Real-CUGAN) 2×, or [Anime4K](https://github.com/bloc97/Anime4K), which costs far less. 2. **Upscale**: [MetalFX](https://developer.apple.com/documentation/metalfx) or Bilinear, to fit the result to the window. 3. **CAS Sharpen** at a low strength. *Image comparison, Bilinear and Real-CUGAN → fit → CAS: Nagisa under the cherry blossoms in CLANNAD, upscaled from 320×240.* CLANNAD at 320×240, enlarged 4×: bilinear on its own, and the three-row chain above. ### DLSS neural rendering at a playable frame rate [DLSS neural rendering](https://procrastinine.github.io/maclauncher/graphics/neural-restoration.md#dlss-neural-rendering) redraws every frame with a neural model. On a game like DOOM 3 the result can look close to a photograph, with weathered skin, woven cloth and softer, more natural light. It is also the most demanding effect on this page, because the model processes every pixel of every frame. The tabs show the same frame three ways: **Original** *Image: A Mars City worker in a break room in DOOM 3, as the game draws it.* DOOM 3 at 3840×2160 with graphics effects off. **DLSS, full resolution** *Image: The same frame with DLSS neural rendering at full resolution.* DLSS neural rendering on the full-resolution frame. It looks the part, but at this size it's far too slow to play. **DLSS at 720p, upscaled** *Image: The same frame with DLSS neural rendering at 720p, upscaled with MetalFX.* A Downsample row hands DLSS a 720p image, and MetalFX Spatial brings the result back to full size. The model processes a fraction of the pixels, and most of the look survives. *Image comparison, Original and DLSS at 720p → MetalFX: A close-up of the worker's face in DOOM 3.* The face at 1:1: the original frame, and the playable DLSS chain. The complete chain: 1. **Downsample** to 720p, so DLSS has far fewer pixels to redraw. 2. **DLSS neural rendering** on the 720p image. 3. **Upscale** with MetalFX Spatial to the window. See [Upscaling](https://procrastinine.github.io/maclauncher/graphics/upscaling.md). 4. **Frame generation** with [Lossless Scaling](https://store.steampowered.com/app/993090/Lossless_Scaling/) at 4×, which fills in the frames DLSS can't produce in time. See [Frame generation](https://procrastinine.github.io/maclauncher/graphics/frame-generation.md). At 540p or 720p, the model redraws a fraction of the pixels, which makes DLSS fast enough to run in real time and keeps the game far more responsive than at full resolution. MetalFX then restores the sharpness, and frame generation smooths the motion. Input follows the frame rate after step 3, plus the small delay that generated frames add. The **DLSS · 540p + LSFG 4×** preset sets up a version of this chain in one step. ### Frame generation alone A single **Frame generation** row at 2× is often all a 30 fps game needs. **Automatic** works without any downloads, while [RIFE](https://github.com/hzwer/Practical-RIFE) and Lossless Scaling use a downloaded model or your own Lossless Scaling files. See [Frame generation](https://procrastinine.github.io/maclauncher/graphics/frame-generation.md). ## Presets **Save as preset…**, in the **⋯** menu beside the **Graphics** heading, saves the current chain under a name, with every row, size and parameter. Applying a preset to another game copies it into that game, so later edits to the preset don't change games it was already applied to. **Manage presets…** opens the presets in **Runtimes → Graphics → Presets**. A preset refers to the shaders and models it uses, which stay in the shared libraries. ## Seeing what changed **Output → Compare** switches between the processed image, the untouched source, a split view with a movable divider, and the difference between the two. **Details** on each row shows its sizes and whether it's running, with a reason when it isn't. ## Performance and presentation The **Output** section also has settings that leave the picture itself alone. Each one appears when the game's graphics support it. A saved choice also stays visible when it cannot run, with the reason shown; it applies once support is available. Supported changes apply while the game runs. - **Performance overlay** draws a small panel at the top left of the game with the captured, displayed and generated frame rates, GPU time, latency and how evenly frames are paced. **Compact** shows three lines. **Detailed** adds memory use, the parts that make up the latency, and running counts of captured, presented, generated, passed-through and dropped frames. It also lists the GPU time of each row in your chain; rows that the GPU processes in one batch share a measurement, and the overlay marks them. With the overlay on, the cost of an effect and whether frame generation keeps up are easy to see. - **Frame-rate cap** limits how often the game itself renders, from 10 to 1000 fps. A steady, lower frame rate can look smoother than one that swings up and down, and it leaves GPU time for the effects. When graphics are applied to [another app's window](https://procrastinine.github.io/maclauncher/graphics/window-graphics.md), the cap limits how often MacLauncher takes frames from that window instead. Without a cap, MacLauncher never limits the game. - **Display sync** and **Drawables** control how processed images reach the screen. Turning display sync off can lower latency in fullscreen but can cause tearing; in a window, macOS shows each image at the display's refresh either way. Two drawables lower latency, and three keep presentation smoother when GPU time varies. ## Shortcuts and screenshots **Settings → Launcher** has keyboard shortcuts for graphics, which work from any app while a game runs: - **Bypass graphics effects** turns the game's graphics off, or back on, just like its **Graphics** checkbox. Pressing it twice gives a quick before-and-after comparison. - **Save processed screenshot** saves the game's image as you see it, with every effect applied, as a PNG file. The file is named after the game and the time, the way macOS names its own screenshots, and the performance overlay is left out. Screenshots go to a MacLauncher folder in your Pictures folder unless you pick another **Screenshot folder**, and they need the game's graphics to be on. Both act on the only running game, or, with several running, on the one in front. If none of them is in front, they act on the most recently started one. A third shortcut, **Toggle graphics for front app**, works whether or not a game runs: it starts window graphics for [the app in front](https://procrastinine.github.io/maclauncher/graphics/window-graphics.md), with a new row of its own, or, when that app already has window graphics, takes them off again. A fourth, **Toggle pointer in window graphics**, hides or shows the pointer that MacLauncher draws on an enlarged window of the app in front. To set a shortcut, click **Record Shortcut** and press the keys. A shortcut combines Control with at least two of Option, Shift and Command, such as ⌃⌥⌘B. macOS and most apps leave combinations like these free, and Settings turns down the few that macOS does use, such as ⌃⇧⌘3 for screenshots. An active graphics shortcut takes precedence over the same keys in the app in front. ## Videos too Videos opened in MacLauncher play through the same chain. **Export video…** renders a video file with the saved chain applied, including neural models and image-pair frame generation. The sample images on this site were made that way. The graphics guide describes [the graphics chain](https://procrastinine.github.io/maclauncher/reference/graphics/README.md#the-graphics-chain), [processing sizes](https://procrastinine.github.io/maclauncher/reference/graphics/README.md#processing-sizes), [presets](https://procrastinine.github.io/maclauncher/reference/graphics/README.md#presets), the [Output section's performance and presentation settings](https://procrastinine.github.io/maclauncher/reference/graphics/README.md#performance-overlay-frame-rate-cap-and-presentation) and the [shortcuts](https://procrastinine.github.io/maclauncher/reference/graphics/README.md#shortcuts-and-screenshots) in full, and the [Video page](https://procrastinine.github.io/maclauncher/reference/game-types/VIDEO.md#preview-and-export) covers export. --- # Shader collections and imports > Running ReShade FX, RetroArch Slang, mpv and libplacebo, MagpieFX and ISF shaders and LUTs on macOS, from downloadable collections or your own files. Web page: https://procrastinine.github.io/maclauncher/graphics/shaders/ MacLauncher runs shaders from [ReShade](https://reshade.me/), [RetroArch](https://www.retroarch.com/), [mpv](https://mpv.io/), [Magpie](https://github.com/Blinue/Magpie) and other projects on macOS, side by side in the same chain. Shaders are small GPU programs that transform an image, and the communities around these projects have written thousands of them, from CRT simulations and anime upscalers to film grades, bloom and ambient occlusion. Shaders you already use elsewhere can often be used here too. ## Formats | Format | Files | Where it comes from | | --- | --- | --- | | ReShade FX | `.fx` | ReShade's large library of post-processing effects for PC games. Techniques, includes, lookup textures and parameters all work. | | [RetroArch Slang](https://github.com/libretro/slang-shaders) | `.slangp`, `.slang` | RetroArch's shader presets, run through [librashader](https://github.com/SnowflakePowered/librashader) on [Metal](https://developer.apple.com/metal/). Multi-pass presets keep their scaling and textures. | | mpv / [libplacebo](https://libplacebo.org/) | `.glsl`, `.hook` | Video-player shaders: upscalers like [Anime4K](https://github.com/bloc97/Anime4K) and FSRCNNX, chroma reconstruction, debanding, grain. | | LUT | `.cube` | Color grades from photo and video editors, as 1D, 3D or combined tables. | | [ISF](https://isf.video/) | `.fs`, `.isf` | Interactive Shader Format effects from the VJ and video world. | | MagpieFX | `.hlsl` | The effect format of Magpie, the Windows window upscaler, including its neural upscalers. | ## The shader library All shaders live in one shared library: the effects included with MacLauncher, the ones from installed collections, and the files you import. **Manage filters…** in the inspector opens the library in **Runtimes → Graphics → Shaders**. To add your own shader, use **Import filter…**, drop the file onto MacLauncher, or open it from Finder. Includes, preset passes and textures are read from their places next to the shader, so a shader folder works as it is. The library records where the file lives and never copies or changes it. An entry can be renamed for display without changing which file it uses, and imported shaders appear in the matching menus immediately. For one-off use, **Custom shader…** on a chain row points that row directly at a file. ## Parameters Most shaders expose settings. **Shader parameters…** on a row lists them with their original names, defaults and ranges, and changes apply live. Each row keeps its own values, so the same shader can appear twice with different settings. Changing a compile-time setting recompiles the shader in the background while the game keeps running. Shaders that read the game's depth also get **Depth input** settings, for games that store depth reversed, logarithmically or with an unusual far plane. All of a game's depth shaders share these settings. ## Collections Collections are curated sets of shaders from upstream projects. In **Runtimes → Graphics → Shaders → Collections**, **Refresh** lists a collection's versions and **Install** downloads one from the original source. Each installed collection records its exact source version and keeps its license notices. | Collection | What's inside | | --- | --- | | Anime4K | Anime upscaling, restoration, denoising and line thinning. | | [ArtCNN](https://github.com/Artoriuz/ArtCNN) | Neural upscalers and restoration for anime and art. | | [CuNNy](https://github.com/funnyplanter/CuNNy) | Learned upscalers for text, line art and visual novels. | | [ACNet and ARNet](https://github.com/TianZerL/ACNetGLSL) | Neural upscaling with mild denoising and line restoration. | | [RAVU and NNEDI3](https://github.com/bjin/mpv-prescalers) | Classic high-quality video prescalers. | | [mpv shader collection](https://github.com/iwalton3/default-shader-pack) | A popular mpv pack: FSRCNNX, FSR, CAS, NVIDIA Image Scaling, NNEDI3, chroma reconstruction and grain. | | [Chroma from Luma](https://github.com/Artoriuz/glsl-chroma-from-luma-prediction) | Rebuilds color detail from brightness detail. | | MagpieFX | Magpie's filters and scaling shaders, including its neural networks. | | libretro Slang | Pixel-art scalers such as [xBRZ](https://github.com/libretro/slang-shaders/tree/master/edge-smoothing/xbrz) and [SABR](https://github.com/libretro/slang-shaders/tree/master/edge-smoothing/sabr), dedithering, restoration filters and CRT halation. | | [Vidvox ISF](https://github.com/Vidvox/ISF-Files) | Image filters, analysis passes and procedural effects. | | [qUINT](https://github.com/martymcmodding/qUINT) | Bloom, Lightroom-style grading, debanding and sharpening; MXAO, ADOF and SSR use game depth. | | [prod80](https://github.com/prod80/prod80-ReShade-Repository) | Film-style grading, curves, LUTs, exposure and grain. | | [CShade](https://github.com/papadanku/CShade) | Image-based optical flow, motion blur, auto exposure and filters. | | [FXShaders](https://github.com/luluco250/FXShaders) | NeoBloom, ArcaneBloom, grading and lens effects. | | [NiceGuy shaders](https://github.com/mj-ehsan/NiceGuy-Shaders) | Screen-space lighting, reflections and depth fog. | | [Visibility bitmask lighting](https://github.com/cdrinmatane/SSRT3) | SSRT3 indirect lighting from real depth, normals and lighting. | | [AstrayFX](https://github.com/BlueSkyDefender/AstrayFX) | RadiantGI indirect lighting, GloomAO ambient occlusion, anti-aliasing, Smart Sharp and Clarity sharpening, bloom, lens flare and image trails. Several effects use game depth. Its author permits only unmodified copies, so MacLauncher installs it exactly as published. | | [OtisFX](https://github.com/FransBouma/OtisFX) | Cinematic depth of field, adaptive and height fog, depth haze, MultiLUT and PandaFX grading, and golden-ratio composition guides. | MacLauncher places a shader in the chain by what the shader declares about its output size and inputs, whatever its name. A shader that always doubles its input is an Upscale, one that keeps the size is an Image filter, and one that needs depth is marked as such and runs only in games that provide depth. The graphics guide's [shader library section](https://procrastinine.github.io/maclauncher/reference/graphics/README.md#shader-library) has the complete details for each format and [collection](https://procrastinine.github.io/maclauncher/reference/graphics/README.md#collections). The [shader integration reference](https://procrastinine.github.io/maclauncher/reference/graphics/SHADERS_AND_MEDIA.md) describes how shaders are sized and which inputs they receive. --- # Any window or display > Apply MacLauncher's shaders, upscalers, neural models and frame generation to any app's window, in place, enlarged or scaled to fill the screen, or to one display or all of them, each with its own chain, on macOS 15.2 or later. Web page: https://procrastinine.github.io/maclauncher/graphics/window-graphics/ MacLauncher can apply its graphics chain, with shaders, upscaling, neural models and frame generation, to the windows of any apps on your Mac and to your displays, several of them at once, and each window or display gets its own chain. The app doesn't have to be in your library, so games from other launchers, emulators and ports get the same effects as the games MacLauncher plays itself. Window graphics need macOS 15.2 or later and MacLauncher's graphics components; without them, the window graphics menu items and shortcut don't appear. ## Starting **File → Apply Graphics…**, or **Apply Graphics…** in MacLauncher's Dock menu, opens the Apply Graphics window, which shows a live preview of everything you can choose: - **Displays** shows each display under its macOS name, such as Built-in Retina Display or your monitor's name. With more than one display, **All Displays** applies one chain to every display at once. - **Windows** shows the windows of your apps, grouped by app with the app's icon. Full-screen windows are there too, and so are windows on other Spaces and minimized windows, marked **Other Space or minimized**. The previews of visible windows refresh every few seconds, and the search field finds an app or a window by name. The list shows up to 96 windows, keeping each app's front window, and the search finds the rest too, so a window doesn't go missing when you have a lot open. Click a tile, or move to it with the arrow keys and press Return, and the session starts right away, with its own row in the library. A window or display that already has graphics is marked **Has window graphics**; its row in the library is where you change or stop them. macOS only lets an app see other apps' windows with the Screen & System Audio Recording permission, so it asks for that permission the first time the window opens. If you don't allow it, the window lists your running apps without previews, and choosing one opens the macOS window picker for that app's windows; picking a window there counts as your consent, so no permission is needed that way. Displays, though, always need it. **Open Privacy Settings** takes you to the right page in System Settings, and the previews appear the next time you come back to the window after allowing it. A shortcut can skip the window. Assign **Toggle graphics for front app** in [Settings → Launcher](https://procrastinine.github.io/maclauncher/graphics/composing-effects.md#shortcuts-and-screenshots), and it starts a session for the app in front, taking its front window right away when MacLauncher has the Screen & System Audio Recording permission, or through the macOS window picker when it doesn't. Pressing it again while that app is in front ends its graphics. ## While it runs Once you choose a window or display, it appears in the library as a temporary row with a **Stop** button, at the top of the list, and the library selects it. If the app or display has no saved chain yet, nothing changes on screen until you add effects, so MacLauncher comes forward with the row's **Graphics** section open. Selecting the row opens the usual **Graphics** tab in the inspector, with rows, presets, live edits and status, just as for a game. The processed picture appears in a separate window above the app's window, either [in place, enlarged or scaled to fill the screen](#in-place-enlarged-or-fit-screen). It also appears over full-screen apps. It hides while the window is minimized or on a Space you aren't looking at, and comes back when the window does, so a window chosen on another Space shows its effects once you switch to that Space. Several windows and displays can have graphics at once, each in its own row with its own chain, so a game can wear a CRT shader while a video player next to it gets an upscaler. Editing one row changes only its window. All Displays is the exception: it's one row whose chain covers every display, and its inspector lists the displays under **Applied to**, where the button beside each one takes it back out. The Dock and File menus list every row under **Stop Window Graphics**, and the end of that menu shows the shortcut, or offers to assign one in Settings. Turning **Graphics** off stops the capture and hides the processed picture, and turning it back on resumes without asking you to choose again. A session ends and its row disappears when its window closes or its app quits, when you disconnect its display, when you stop sharing from the macOS capture indicator, when you choose **Stop**, or when MacLauncher quits; the other rows keep running. If an app opens a new window within 10 seconds of closing a captured one, the new window takes its place. All Displays picks up a display you connect while it runs. If capturing fails, for example because MacLauncher lost the Screen & System Audio Recording permission, that session ends and MacLauncher tells you why. ## In place, enlarged or fit screen The **Output** setting of the **Window capture** runtime places the processed picture: **In place**, **Fit screen**, or enlarged by **1.5×** up to **10×**. Display sessions are always in place. **In place**, the default, lays the processed picture exactly over the window. Clicks, keys and controllers pass straight through to the app. The picture follows the window when it moves, resizes or goes full screen, and keeps up with a window you drag, frame by frame. Sheets and other windows attached to the window appear in the processed picture, and so do the app's own floating palettes when they overlap it. The effect stacks with the window, as if it were part of it: another window that covers the window covers the effect too, and when you bring the window back, the effect comes with it. Clicks and selection inside the window leave the effect in front. The effect stays on while you work in another app. MacLauncher never brings a window forward or moves focus to show the effect. Menus, the Dock and alerts still appear over it. **Fit screen** enlarges the window's picture to fill the screen it's on, keeping the window's shape, with black bars on the remaining sides. The menu bar and the Dock stay visible unless the window is full screen. A scale factor such as **2×** or **3×** enlarges the picture around the window's center instead, as far as the screen allows. The chain's scaling method does the enlarging, so a [spatial upscaler](https://procrastinine.github.io/maclauncher/graphics/upscaling.md) such as FSR 1 or MetalFX Spatial can turn a small window into a full-screen picture, much as [Lossless Scaling](https://store.steampowered.com/app/993090/Lossless_Scaling/) does on Windows. The enlarged picture stays up while you use other apps, and clicks always pass through it. While the enlarged picture shows and its app is in front, MacLauncher keeps the mouse pointer inside the real window underneath, hides the system pointer and draws a pointer on the enlarged picture at the matching spot. Clicks, drags and scrolls land in the window exactly where the drawn pointer points, and keys and controllers go to the app as usual. **Show pointer in picture**, another **Window capture** setting, hides the drawn pointer, and the **Toggle pointer in window graphics** shortcut in Settings turns it off and on for the app in front while you play. A game that holds the pointer still for mouse look hides the drawn pointer until the pointer moves again. Switch to another app and the pointer is free again. Keeping the pointer inside the window needs MacLauncher to have the Accessibility permission. Choosing **Fit screen** or a scale factor without it brings up the macOS request and keeps **In place**; once you've allowed it in **System Settings → Privacy & Security → Accessibility**, choosing it again applies it. ## Effects on a window The picture comes from Apple's [ScreenCaptureKit](https://developer.apple.com/documentation/screencapturekit), which delivers the window's finished image at its own pixel size. Color effects, shaders, scaling methods, neural image processing and image-pair frame generation apply to it. Options that need data from inside a game's renderer, such as its render resolution, depth and motion vectors, aren't offered. - **Include pointer in capture**, a setting of the **Window capture** runtime, draws the pointer into the captured image, so effects apply to it as well. The real pointer always stays on top. - The output's [frame-rate cap](https://procrastinine.github.io/maclauncher/graphics/composing-effects.md#frame-rate-cap) limits how often MacLauncher takes a frame from the window, which leaves GPU time for heavy effects. ## Remembered chains Each app and each display keeps its own chain, and All Displays has one more. When a session ends, MacLauncher saves its chain and capture settings for its app or display (the displays under All Displays are saved as All Displays), and the next session for that app or display starts from it. Two windows of the same app each start from the app's chain, and the one that ends last is the one remembered. A display is recognized by the identifier macOS gives it, so a monitor keeps its chain when you plug it back in. An empty chain with no saved capture settings is left out. MacLauncher keeps at most 50 chains, drops the least recently used one first, and forgets apps that are no longer installed. The reference describes [window entries](https://procrastinine.github.io/maclauncher/reference/game-types/WINDOW.md), including sessions and remembered chains, in full. The frame source reference covers the [capture path](https://procrastinine.github.io/maclauncher/reference/graphics/INPUTS_AND_ADAPTERS.md#picked-windows-and-displays). --- # Tinker tools > How MacLauncher's tools work on macOS, and an overview of its store downloads, save tools, cheats, decompilers and version management. Web page: https://procrastinine.github.io/maclauncher/tools/ Besides importing and playing games, MacLauncher has tools for working with the games on your Mac: store downloads, save tools, cheats, decompilers and version management. ## How the tools work - Generated files, caches, private copies and exports live in MacLauncher's own storage, apart from the game's files, and **Forget** cleans them up. - Runtimes expose their settings, you can pass any launch flags you like, and every game can override the defaults and turn its own network access on or off. - Runtimes, tools, store downloads and accounts can all be managed by version, and a default applies when you don't choose one. A game's decompilers and extractors belong to its [game type](https://procrastinine.github.io/maclauncher/background/choosing-a-runtime.md#game-types-and-runtimes), so they stay available whichever runtime plays it, including Sikarugir or CrossOver. ## The tools ### [Stores and downloads](https://procrastinine.github.io/maclauncher/tools/stores-and-downloads.md) Find the games already installed from [Steam](https://store.steampowered.com/), [Epic](https://store.epicgames.com/), [GOG](https://www.gog.com/) and [itch.io](https://itch.io/), and download the games you own straight from those stores, for any platform and in any version you can get. That includes the Windows build of a Steam game on a Mac, or an older build by its manifest ID. Android apps come from [Google Play](https://play.google.com/store/games), [F-Droid](https://f-droid.org/) and [IzzyOnDroid](https://apt.izzysoft.de/fdroid/). ### [Saves and cheats](https://procrastinine.github.io/maclauncher/tools/saves-and-cheats.md) Find where a game keeps its saves, take snapshots before you experiment, restore them, and edit [RPG Maker](https://www.rpgmakerweb.com/) MV and MZ saves field by field. Cheats are built in for RPG Maker and [Ren'Py](https://www.renpy.org/) games. ### [Decompilers and extractors](https://procrastinine.github.io/maclauncher/tools/decompilers-and-extractors.md) Unpack archives, decrypt assets, and decompile scripts and code for most game types, from Ren'Py and RPG Maker to [Unity](https://unity.com/), [GameMaker](https://gamemaker.io/), Java, Flash and Android. The tools download on demand. ### [Versions and settings](https://procrastinine.github.io/maclauncher/tools/versions-and-settings.md) Install and switch between runtime versions, set defaults and per-game overrides, add launch arguments, save `.command` launchers, and run games from the command line. --- # Stores and downloads > Import installed Steam, Epic, GOG and itch.io games on macOS, and download any platform or version you own, including Steam depots and Android APKs. Web page: https://procrastinine.github.io/maclauncher/tools/stores-and-downloads/ The **External** window, next to Settings in the toolbar, connects MacLauncher to the game stores you already use. It finds the games you've already installed, and it downloads the games you own in exactly the version and platform you want. ## Games you already have The External window's **Installed** tab gathers the games installed by [Steam](https://store.steampowered.com/), [Epic Games](https://store.epicgames.com/) (including through [Heroic](https://heroicgameslauncher.com/) and [Legendary](https://github.com/legendary-gl/legendary)), [GOG](https://www.gog.com/) and [itch.io](https://itch.io/), both in their usual macOS locations and inside [CrossOver](https://www.codeweavers.com/crossover/) bottles. It reads the stores' local records, so it works offline. Tick the games you want and press **Import**. The games stay where they are, and MacLauncher adds them to your library. Versions that MacLauncher downloaded for you appear in the **Downloaded** tab instead, which works the same way. ## Downloading what you own Each store has its own tab, and these tabs let you choose more than the official launchers do. The Steam client on a Mac, for instance, won't normally let you download the Windows version of a game. MacLauncher will, and if the game is built on an engine with a [native runtime](https://procrastinine.github.io/maclauncher/games.md), that Windows build can run natively without CrossOver. What you can choose depends on the store: | Store | What you can pick | | --- | --- | | Steam | Branches, builds, individual [depots](https://partner.steamgames.com/doc/store/application/depots), and historical manifests (look up older manifest IDs on [SteamDB](https://steamdb.info/), or fetch the history from inside MacLauncher) | | Epic | Published platform builds, or an exact historical manifest | | GOG | Offline installer versions and [Galaxy](https://www.gog.com/galaxy) builds, including previous ones | | itch.io | Uploads for each platform, and earlier builds when you sign in | | [Google Play](https://play.google.com/store/games) | The current version for a choice of Android device profiles, or exact version codes | | [F-Droid](https://f-droid.org/) and [IzzyOnDroid](https://apt.izzysoft.de/fdroid/) | Every published APK version | The platform is your choice too: Windows, Linux, Mac (including old 32-bit Mac builds) and, where a publisher offers one, Android. Downloads go into their own version folders, so you can keep several versions side by side, and they're imported into your library automatically unless you untick that option. > **Note:** > Downloads follow the store's rules. You can download what your account owns or what's free, and some restricted or removed content stays unavailable. ## Accounts You can use more than one account per store. For Steam, you can reuse the account signed in to the Steam app on your Mac. MacLauncher talks to the running client and doesn't copy your credentials. You can also sign in to any number of additional accounts inside the External window, with [Steam Guard](https://help.steampowered.com/en/faqs/view/06B0-26E6-2CF8-254C) and QR sign-in supported. Remembered sign-ins are protected by the macOS Keychain, and passwords are never stored. Epic, GOG and itch.io have their own sign-ins in their tabs. Google Play accounts are shared with the Android runtimes, with a choice of device profiles. ## Steam API without Steam Some games refuse to start unless Steam is running. MacLauncher includes [offline Steam API support](https://procrastinine.github.io/maclauncher/reference/runtimes/STEAM_API.md) for the runtimes that need it, so those games can run locally, with the genuine [Steamworks](https://partner.steamgames.com/doc/sdk) libraries used where a game requires them. Guides: [External game libraries](https://procrastinine.github.io/maclauncher/reference/library/EXTERNAL.md), [Android app downloads](https://procrastinine.github.io/maclauncher/reference/library/GOOGLE_PLAY.md) --- # Saves and cheats > Find game saves on macOS, snapshot and restore them, edit RPG Maker saves, and use the built-in cheats for RPG Maker and Ren'Py games. Web page: https://procrastinine.github.io/maclauncher/tools/saves-and-cheats/ MacLauncher finds the saves of games on your Mac, keeps snapshots of them and moves them between locations, edits RPG Maker MV and MZ saves, and has built-in cheats for RPG Maker and Ren'Py games. ## Save tools Games keep their saves in all sorts of places: next to the executable, in `~/Library`, inside a [WINE](https://www.winehq.org/) bottle or in a browser profile. Every game type that knows where its games save has save tools. **Saves** in the game's inspector (**Edit saves** for game types that support save editing) shows where this game's saves actually live and gives you a few ways to look after them. ### Snapshots Before you try something risky, such as a save edit, a mod, a cheat or a new runtime version, take a snapshot with **Create snapshot**. A snapshot is an exact copy of the save files, kept in MacLauncher's storage. Restoring shows you a preview first, then puts back exactly the files that were recorded and leaves any newer saves alone. MacLauncher also takes a snapshot automatically before any import, edit or restore it performs on your saves, so a save edit that goes wrong can be rolled back. ### Moving saves around In the same view, the **Save files** tab lets you import and export save files, and edit them as JSON for game types whose save format MacLauncher can read. You can also point a game at a different save folder, for instance to share saves with another copy of the game. ### Editing RPG Maker MV/MZ saves [RPG Maker](https://www.rpgmakerweb.com/) MV and MZ saves get a full editor. **Edit values** shows switches, variables, gold, inventory, and each party member's HP, MP, TP and level, with names taken from the game's own database where it has them. Nothing from the game runs while you edit, and the original encoding is preserved. For other game types, the right tool depends on the format. RPG Maker XP, VX and VX Ace saves can be inspected as a data graph, and [Ren'Py](https://www.renpy.org/) saves through their metadata; to change a Ren'Py game's state, use the [console](#renpy) instead. Sikarugir keeps the original working directory. Saves can live in the original game folder or the game's Windows profile, and the save tools show both. An app-adjacent DLL adapter can also leave executable-relative files in its retained [adapter view](https://procrastinine.github.io/maclauncher/games/windows.md#original-game-files-and-separate-windows-environments). Guides: [Save snapshots](https://procrastinine.github.io/maclauncher/reference/tools/SAVE_SNAPSHOTS.md), [RPG Maker MV and MZ save editor](https://procrastinine.github.io/maclauncher/reference/game-types/RPGMAKER_MV_MZ.md#structured-save-editing) ## Cheats RPG Maker MV, MZ and XP/VX/VX Ace games and Ren'Py games have built-in cheats. Every game built with one of these engines shares the same internals, so one set of cheats works for all of them. **Cheats** in the inspector opens them. ### RPG Maker For RPG Maker MV and MZ games, the **Cheats** window has a long list of switches you can flip while you play: | Category | Cheats | | --- | --- | | Movement and speed | Game speed, move speed, always dash, no clip, no random encounters, fast events | | Battle | God mode, one-hit kills, always hit, always crit, immunity to status effects, always escape, damage and EXP multipliers | | Items and shops | Infinite items, no skill costs, every item in shops, free shopping | | Story | Instant text, message skipping on a held key, no game over | MV and MZ games also get an in-game Tools overlay, opened with Ctrl-Shift-T or Cmd-Shift-T, with the same cheats plus searchable inventory, teleport, variable and switch pages. With NW.js, the overlay is added by a patch from the inspector's **Patches** section. RPG Maker XP, VX and VX Ace games use the same Cheats window, and add an in-game cheat menu on **F8** with extras such as item grants, teleport slots, party and enemy tools, and stat, level and gold edits. Changes made in either place stay in sync. ### Ren'Py Ren'Py games can get an opt-in developer console, which you open with Shift+O in the game. With it you can read and change the game's variables, for example to set your money, and then save to a new slot. MacLauncher installs the console as a separate script file and leaves the game's own scripts untouched, and removing it puts everything back. The Cheats window can also install two community add-ons: the [Universal Ren'Py Mod](https://0x52.dev/mods/Universal-Ren-Py-Mod-1000) and the [Universal Ren'Py Walkthrough System](https://github.com/BCassO/universal-renpy-walkthrough). Guides: [Cheats](https://procrastinine.github.io/maclauncher/reference/tools/CHEATS.md), [Ren'Py console](https://procrastinine.github.io/maclauncher/reference/game-types/RENPY.md#renpy-console) --- # Decompilers and extractors > Unpack archives, decrypt assets and recover scripts and source code on macOS, for Ren'Py, RPG Maker, Unity, Android and most of the other game types MacLauncher supports. Web page: https://procrastinine.github.io/maclauncher/tools/decompilers-and-extractors/ To translate a game, mod it, rescue its music or read its script, you first need to see inside it, and MacLauncher's decompilers and extractors do that on your Mac. Most game types come with these tools in the inspector. The tools belong to the game type, so they read the game's original data whichever runtime plays it. They all follow the same pattern. You press the action, and if it needs a tool that isn't installed yet, MacLauncher downloads it and then continues where it left off. Results go into a separate export folder, so the game's files stay as they are. The one exception is Near Infinity, an external editor for Infinity Engine games: edits you save in it can change the game's resources. ## By game type Each game type links to the tools section of its guide. ### Desktop engines | Game type | What you can do | | --- | --- | | [Ren'Py](https://procrastinine.github.io/maclauncher/reference/game-types/RENPY.md#tools) | Extract RPA archives and decompile `.rpyc` scripts back to readable `.rpy` ([unrpyc](https://github.com/CensoredUsername/unrpyc), [rpatool](https://codeberg.org/shiz/rpatool) and UnRen) | | [RPG Maker MV and MZ](https://procrastinine.github.io/maclauncher/reference/game-types/RPGMAKER_MV_MZ.md#plugins-and-extraction) | Decrypt images and audio into a readable project ([RPGMakerDecrypter](https://github.com/uuksu/RPGMakerDecrypter)); the scripts, plugins and database are readable as they are | | [RPG Maker XP/VX/VX Ace](https://procrastinine.github.io/maclauncher/reference/game-types/RPGMAKER_XP_VX.md#ruby-scripts) | Decrypt `.rgssad`/`.rgss3a` archives, export and repack the Ruby scripts, inspect save and data files | | [RPG Maker 2000/2003](https://procrastinine.github.io/maclauncher/reference/game-types/RPGMAKER_2000_2003.md#tools) | Export the database and maps to JSON, or the game's text for translation | | [WOLF RPG Editor](https://procrastinine.github.io/maclauncher/reference/game-types/WOLFRPG.md#tools) | List and extract archives, including WOLF Pro archives ([UberWolf](https://github.com/Sinflower/UberWolf)), and export project data as JSON ([WolfTL](https://github.com/Sinflower/WolfTL)) | | [Godot](https://procrastinine.github.io/maclauncher/reference/game-types/GODOT.md#tools) | Recover the project, including GDScript ([GDRE Tools](https://github.com/GDRETools/gdsdecomp)) | | [GameMaker](https://procrastinine.github.io/maclauncher/reference/game-types/GAMEMAKER.md#decompilation-and-inspection) | Decompile Studio games' GML and export textures and sprites ([UndertaleModTool](https://github.com/UnderminersTeam/UndertaleModTool)), rebuild classic GameMaker 8 projects ([GM8Decompiler](https://github.com/OpenGMK/OpenGMK)) | | [Unity](https://procrastinine.github.io/maclauncher/reference/game-types/UNITY.md#inspector-tools) | Decompile Mono code to C# ([ILSpy](https://github.com/icsharpcode/ILSpy)), recover [IL2CPP](https://docs.unity.com/en-us/engine/current/manual/programming-environment/scripting-backends) assemblies for ILSpy ([Cpp2IL](https://github.com/SamboyCoding/Cpp2IL)), browse and export assets ([AssetRipper](https://github.com/AssetRipper/AssetRipper)) | | [FNA / XNA 4](https://procrastinine.github.io/maclauncher/reference/game-types/FNA.md#decompilation) | Decompile to C# with ILSpy | | [Java](https://procrastinine.github.io/maclauncher/reference/game-types/JAVA.md#decompilation) | Decompile to Java ([Vineflower](https://vineflower.org/)) | | [LÖVE](https://procrastinine.github.io/maclauncher/reference/game-types/LOVE.md#source-export) | Recover Lua and LuaJIT source ([LJD](https://github.com/dol/luajit-decompiler) and [unluac](https://sourceforge.net/projects/unluac/)) | | [Flash](https://procrastinine.github.io/maclauncher/reference/game-types/FLASH.md#tools) | Export ActionScript, images, sounds, fonts and text ([JPEXS FFDec](https://github.com/jindrapetrik/jpexs-decompiler)) | | [Construct](https://procrastinine.github.io/maclauncher/reference/game-types/CONSTRUCT.md#tools) and [Tyrano](https://procrastinine.github.io/maclauncher/reference/game-types/TYRANO.md#tools) | Extract the packaged HTML, scripts and resources | ### Visual novels | Game type | What you can do | | --- | --- | | [KiriKiri](https://procrastinine.github.io/maclauncher/reference/game-types/KIRIKIRI.md#script-export) | Export TJS and KAG scripts | | [AliceSoft](https://procrastinine.github.io/maclauncher/reference/game-types/ALICESOFT.md#source-export) | Decompile System 1–3 and System 3.5–3.9 scenarios, disassemble System 4 games and export their text, and edit the variables of a running System 3.5–3.9 game | | [Siglus / RealLive](https://procrastinine.github.io/maclauncher/reference/game-types/SIGLUS.md#source-tools) | Decompile Siglus scripts ([Siglus SceneScript Utility](https://github.com/Jirehlov/SiglusSceneScriptUtility)), export RealLive scripts and text (RLdev) | | [NScripter](https://procrastinine.github.io/maclauncher/reference/game-types/NSCRIPTER.md#tools) | Export the script, including encoded scripts | | [Nitroplus](https://procrastinine.github.io/maclauncher/reference/game-types/NITROPLUS.md#inspector-tools) | Inspect archives, extract the NSS script source and check it with the script compiler | | [Minori](https://procrastinine.github.io/maclauncher/reference/game-types/MINORI.md#script-tools) | Export scripts as UTF-8 text | | [MAGES.](https://procrastinine.github.io/maclauncher/reference/game-types/MAGES.md#archive-and-script-tools) | Inspect archives and scripts, export compiled scripts and, for supported editions, dialogue text | | [FAVORITE / FVP](https://procrastinine.github.io/maclauncher/reference/game-types/FVP.md#inspection-and-asset-exports) | Export dialogue ([msg-tool](https://github.com/lifegpc/msg-tool)) and extract assets | | [BGI / Ethornell](https://procrastinine.github.io/maclauncher/reference/game-types/BGI.md#inspector-tools) | Export compiled programs and messages (msg-tool) | | [CatSystem2](https://procrastinine.github.io/maclauncher/reference/game-types/CATSYSTEM2.md#script-and-archive-export) | Decode archives and export scripts as readable transcripts | | [AI5WIN](https://procrastinine.github.io/maclauncher/reference/game-types/AI5.md#detection-and-versions) | Report the game's data and configuration | | [VNDS](https://procrastinine.github.io/maclauncher/reference/game-types/VNDS.md#game-files-and-saves) | Open the scripts, which are plain text | ### Mobile, consoles and native programs | Game type | What you can do | | --- | --- | | [Android](https://procrastinine.github.io/maclauncher/reference/game-types/ANDROID.md#apk-decompilation) | Recover Java source and resources ([JADX](https://github.com/skylot/jadx)), or decode smali, the manifest and resources ([Apktool](https://github.com/iBotPeaches/Apktool)) | | [iOS / iPadOS](https://procrastinine.github.io/maclauncher/reference/game-types/IOS.md#inspector-tools) | Inspect and extract the contents of an IPA, and inspect unencrypted executables | | [PlayStation 5](https://procrastinine.github.io/maclauncher/reference/game-types/PS5.md#inspector-tools) and [Nintendo Switch](https://procrastinine.github.io/maclauncher/reference/game-types/SWITCH.md#inspector-tools) | Inspect programs and export functions, strings and C pseudocode ([Rizin](https://github.com/rizinorg/rizin) and [Ghidra](https://github.com/NationalSecurityAgency/ghidra)) | | [macOS Game](https://procrastinine.github.io/maclauncher/reference/game-types/MACOS.md#inspector-tools), [Windows Game](https://procrastinine.github.io/maclauncher/reference/game-types/WINDOWS.md#inspector-tools), [DOS](https://procrastinine.github.io/maclauncher/reference/game-types/DOS.md#inspector-tools) and [Haxe native build](https://procrastinine.github.io/maclauncher/reference/game-types/HAXE.md#binary-inspection) | Inspect the executable and export C pseudocode with Rizin and Ghidra | ### Other game types | Game type | What you can do | | --- | --- | | [Infinity Engine](https://procrastinine.github.io/maclauncher/reference/game-types/INFINITY_ENGINE.md#near-infinity) | Browse and edit resources and saves ([Near Infinity](https://github.com/Argent77/NearInfinity)) | | [ScummVM](https://procrastinine.github.io/maclauncher/reference/game-types/SCUMMVM.md#inspector-tools) | Identify the edition and extract resource archives ([ScummVM Tools](https://wiki.scummvm.org/index.php/ScummVM_Tools)) | | [MUGEN / Ikemen GO](https://procrastinine.github.io/maclauncher/reference/game-types/MUGEN.md#sprite-export) | Export sprites as PNG files | | [HashLink](https://procrastinine.github.io/maclauncher/reference/game-types/HASHLINK.md#bytecode-export) | Inspect bytecode and export its opcodes and pseudocode ([hlbc](https://github.com/Gui-Yom/hlbc)) | | [Video](https://procrastinine.github.io/maclauncher/reference/game-types/VIDEO.md#preview-and-export) | Report a video's streams, chapters and tags | The [tool reference](https://procrastinine.github.io/maclauncher/reference/tools/README.md) lists every action, output format and limit by game type, and [native binary inspection](https://procrastinine.github.io/maclauncher/reference/tools/NATIVE_INSPECTION.md) describes the Rizin and Ghidra exports. ## Installers and packed games Many games don't arrive as a plain folder. MacLauncher opens the common wrappers on import, so you can usually drag the download straight in. ### Installers [GOG](https://www.gog.com/)'s offline Windows installers, like many others, are built with [Inno Setup](https://jrsoftware.org/isinfo.php): a `setup_….exe`, often with numbered `.bin` parts beside it. MacLauncher reads the installer as data with [innoextract](https://github.com/dscharrer/innoextract), without running it, then detects the game type inside like any other folder. A GOG Windows installer of a Ren'Py, GameMaker or RPG Maker game can therefore end up on a native runtime, with no Windows or [WINE](https://www.winehq.org/) at any step. [Stores and downloads](https://procrastinine.github.io/maclauncher/tools/stores-and-downloads.md) gets those installers, older versions included, from inside MacLauncher. Encrypted installers aren't supported. ### Packed games Some games ship entirely inside one `.exe`, and the game type's module reads it in place: - TyranoScript, [Construct](https://www.construct.net/) and LÖVE games with their data appended to the executable as a ZIP; - Godot games with their data embedded in the executable; - RPG Maker XP/VX/VX Ace and NScripter games inside self-extracting archives (ZIP, RAR, 7z, NSIS, Inno Setup or CAB), opened with [7-Zip](https://www.7-zip.org/); - RPG Maker XP/VX/VX Ace, NScripter and Tyrano games packed with Enigma Virtual Box, unpacked with [evbunpack](https://github.com/mos9527/evbunpack). The unpacked copy lives in MacLauncher's own game data, and importing the same installer again reuses it. innoextract downloads the first time it's needed; 7-Zip and evbunpack are included. Guide: [Installer reader](https://procrastinine.github.io/maclauncher/reference/tools/INSTALLERS.md) ## What you get back [Decompiled](https://en.wikipedia.org/wiki/Decompiler) output is a faithful reading of what the game shipped, which is different from the developer's original project. Script engines such as Ren'Py, RPG Maker and KiriKiri come back very readable. Compiled code (C#, Java) usually decompiles well. Machine code from native programs comes back as pseudocode, which is good for understanding a program and useless for rebuilding it. --- # Versions and settings > Install and switch runtime versions on macOS, set defaults and per-game overrides, add launch arguments, save .command launchers and run games from the command line. Web page: https://procrastinine.github.io/maclauncher/tools/versions-and-settings/ MacLauncher installs and switches the runtime versions that play games on your Mac, and each game can choose its own runtime, version, settings and launch arguments. ## The Runtimes window The **Runtimes** window is MacLauncher's version manager. Every engine, player and tool has a page there, sorted into the groups Game engines, Consoles and mobile, Compatibility, Graphics and Tools. Each page works the same way: - The refresh button above a version list, **Reload versions**, looks up the available versions; the first time, it reads **Load versions**. The list comes straight from each project's own releases, so a new release appears the next time you refresh, without waiting for a MacLauncher update. Apart from a download you've agreed to, this is the only time MacLauncher checks for new versions. The results are cached, so the list is still there offline. - **Install** downloads the version you've selected. You can keep as many versions installed as you like, side by side. - **Remove** deletes an installed version you no longer need. - The default is the version used by games that don't ask for a specific one. A version picked for a particular game, or one the game's own files call for, takes precedence. [Choosing a runtime](https://procrastinine.github.io/maclauncher/background/choosing-a-runtime.md#versions) explains the order. Many runtimes have two sources: the upstream project's own releases, and [MacLauncher Builds](https://procrastinine.github.io/maclauncher-builds/), which provides ready-to-run macOS builds of engines that need adapting. Each source has its own version list, and everything you've installed from either one shows up together when you choose a version for a game. A few components ship inside MacLauncher itself and are marked **Included**. ### Processor builds MacLauncher comes as two apps, and each one downloads runtimes built for its own processor: the Apple Silicon app prefers Apple Silicon builds and the Intel app prefers Intel builds, even when it runs on an Apple Silicon Mac through Rosetta. A universal build, which contains both, serves either app. When a runtime is published for both processors, a **Build** menu above its version list switches to the other processor's versions. Builds for both can be installed side by side. One built for the other processor carries an **Intel** or **Apple Silicon** tag, while builds for the app's own processor and universal builds have none, and **Set default** on such a build makes it that runtime's default. An Apple Silicon build runs only on an Apple Silicon Mac, while Intel builds also run on Apple Silicon through [Rosetta](https://support.apple.com/en-us/102527). If Rosetta isn't installed yet, Play offers to install it, and macOS shows Apple's license prompt. A build your Mac can't run stays in the list, along with what it needs. [Macs and macOS versions](https://procrastinine.github.io/maclauncher/macs-and-macos.md) explains which runtimes and features depend on the processor or the macOS version. ### Your own copies Some runtimes can use a copy you already have. **Register custom…** adds your own executable, app or runtime folder to a runtime's choices, and CrossOver has **Add CrossOver…** and **Find installed applications**. Those copies stay where they are, because MacLauncher only points to them, and removing one only forgets it. ### Downloads You don't have to refresh before playing. If a game needs a runtime and no version list has been loaded yet, the download prompt that **Play** shows covers looking up the versions too, and MacLauncher installs the runtime's default version, which is the newest one that runs on your Mac unless you've chosen another. Development builds published through GitHub Actions, such as LÖVE nightlies and MKXP-Z's upstream builds, download without a GitHub account or any developer tools. A MacLauncher Builds package of a project that publishes no releases of its own is listed by the date of the upstream code it was built from, such as **Development build (Oct 28)**. Downloads run in the background while you keep using the launcher. A download button in the Runtimes window lists everything in progress, with a progress bar and a cancel button for each. **Runtimes → Graphics** manages the graphics components the same way: shader collections, imported shaders, presets, neural models and the upscaling and frame-generation components. See [Graphics and effects](https://procrastinine.github.io/maclauncher/graphics.md). ## Per-game choices A game's inspector lets you override almost everything for that game alone. ### Runtime and version You can pick a different runtime or pin an exact version. The first entry in the version menu is the game's **Recommended** version when its files call for one, and otherwise the **Default**. [Choosing a runtime](https://procrastinine.github.io/maclauncher/background/choosing-a-runtime.md) explains which runtime suits which game. ### Runtime settings A gear next to the runtime opens that runtime's settings for this game, such as window size, language, controls or launch flags. The defaults for each game type live in **Settings**; anything you change here applies to this game only, and **Reset** returns to the defaults. Less common options sit in a collapsed **Advanced** group. ### Launch arguments Launch arguments are extra command-line arguments passed to the game, for example `--windowed --name "Example name"`. Quotes keep spaces inside one argument. The arguments stay with the game even if you change its runtime, and shortcuts use them too. ### Network access Every game runs cut off from the Internet and your local network unless you allow it. The **Network access** checkbox turns access on for this game, and the default for newly added games is in **Settings → Launcher**. The block covers the game and everything it starts, native code included, and if MacLauncher can't put it in place, the game doesn't start. Changes apply the next time the game starts. A few games need access, for example web games that load their content from a website. ### Steam client on Play Games that use [Steam](https://store.steampowered.com/) can start the Mac Steam client when you press Play. With **Ask**, the default, MacLauncher offers **Start Steam** or **Launch without Steam** when Steam isn't running, because the Steam client goes online. **Start automatically** and **Don't start** skip the question. The setting is in **Settings → Launcher**, and each game can override it. ### Save location You can point the game at a different save folder, or reset it to the default. See [Saves and cheats](https://procrastinine.github.io/maclauncher/tools/saves-and-cheats.md#moving-saves-around). ## Settings The **Settings** window (Cmd+,) holds preferences, and the only thing in it that goes online is the **Check for Updates…** button. Its sidebar starts with a search field, followed by these sections: - **Launcher**: appearance (System, Light or Dark), whether the library shows game icons and runtime tags, the default **Network access** for new games, **Steam client on Play**, the [graphics shortcuts and screenshot folder](https://procrastinine.github.io/maclauncher/graphics/composing-effects.md#shortcuts-and-screenshots), **Check for Updates…** with the result of the last check, and **Check for updates at launch**, which is off by default. - One section per game type, with its **Default runtime** and a tab for each runtime's settings. A tab shows **Modified** when its settings differ from the defaults. Changes save as you make them and show up in every open window straight away. Graphics presets and the shader library live in **Runtimes → Graphics**. ## Shortcuts **Create shortcut…** next to Play (or **Shortcut** on a library row) saves a small `.command` file wherever you like, under any name. Double-click it and the game starts with its current runtime, version, settings and save location, without opening the library window. You can put it in the Dock, a games folder or another launcher. ## Launching without the library If you run MacLauncher from source, the same backend works from the terminal: ```sh pnpm launch --game /path/to/game --wait # play pnpm launch --game /path/to/game --inspect # show what was detected pnpm launch --game /path/to/game --action ``` Guides: [Runtime system](https://procrastinine.github.io/maclauncher/reference/runtimes/README.md), [Settings reference](https://procrastinine.github.io/maclauncher/reference/runtimes/SETTINGS_REFERENCE.md), [Release catalogs](https://procrastinine.github.io/maclauncher/reference/runtimes/RUNTIME_CATALOGS.md), [Network isolation](https://procrastinine.github.io/maclauncher/reference/runtimes/NETWORK_ISOLATION.md), [Backend and command line](https://procrastinine.github.io/maclauncher/reference/development/BACKEND.md) --- # FAQ and troubleshooting > Common questions about MacLauncher, including which Macs it runs on, how its builds can be verified and what it connects to, and what to try when a game doesn't start or doesn't behave. Web page: https://procrastinine.github.io/maclauncher/help/faq/ This page answers common questions about MacLauncher, starting with general ones, then trust and verification, then what to try when a game misbehaves. ## General ### Is MacLauncher free? Yes. It's open source under the [MIT license](https://github.com/procrastinine/maclauncher/blob/master/LICENSE). The runtimes it downloads are open-source projects or official free releases, each under its own license, and the [attributions](https://procrastinine.github.io/maclauncher/reference/ATTRIBUTIONS.md) list them all. A few optional extras use software you bring yourself, such as [CrossOver](https://www.codeweavers.com/crossover/) or a purchased copy of [Lossless Scaling](https://store.steampowered.com/app/993090/Lossless_Scaling/). ### What Mac do I need? Any Mac with macOS 13 or later, with either an Apple Silicon or an Intel processor. MacLauncher comes as two apps, one for each kind of processor, and the download buttons on this site offer the one that matches the Mac. Both apps share the same library, settings and installed runtimes. Most of MacLauncher works the same on every supported Mac. Android, iPhone and iPad, and Switch games need Apple Silicon, and some graphics features need Apple Silicon or a newer macOS. [Macs and macOS versions](https://procrastinine.github.io/maclauncher/macs-and-macos.md) lists what works where. ### Does MacLauncher pick Apple Silicon or Intel runtimes by itself? Yes. Each app downloads runtime builds made for its own processor, uses a universal build where one exists, and falls back to an Intel build through Rosetta on Apple Silicon when a runtime offers nothing else. The choice can be overridden: the **Build** menu in **Runtimes** lists the other processor's builds, and **Set default** on one makes it that runtime's default. [How MacLauncher picks a build](https://procrastinine.github.io/maclauncher/macs-and-macos.md#how-maclauncher-picks-a-build) explains the details. ### Which version of a runtime do I get? The one the game asks for, when its files name a version, and otherwise the default for that runtime. Without a saved default, MacLauncher uses the newest version that the runtime's publisher lists and that runs on the Mac. Versions come straight from each publisher's own releases, so a new release appears in **Runtimes** after a refresh without waiting for a MacLauncher update. Any listed version can be chosen for a game instead, and installed versions stay usable after the publisher stops offering them. [Choosing a runtime](https://procrastinine.github.io/maclauncher/background/choosing-a-runtime.md#versions) explains the order. ### Does it change my game files? No. MacLauncher reads your games where they are. Anything it generates (converted files, caches, private copies for [WINE](https://www.winehq.org/) games, saves kept by MacLauncher, and exports) goes into its own storage under `~/Library/Application Support/maclauncher/`. **Forget** removes that data for a game, and the original files stay put. ### Can I keep games on an external drive? Yes. When the drive is unplugged, its games stay in the library marked **Unavailable**, with their saves, settings and runtime choices intact, and MacLauncher neither changes them nor tries to detect them again. Once the drive is back at the same location, the games are ready to play without a restart or a new import, and a game that has moved somewhere else can be pointed at its new location with **Locate…**. [Games on an external drive](https://procrastinine.github.io/maclauncher/launcher.md#games-on-an-external-drive) has the details. ### Do I still need CrossOver or WINE? Only for games that have no native runtime. When a Windows game does need WINE, MacLauncher downloads and manages [Sikarugir](https://github.com/Sikarugir-App/Sikarugir), a free WINE distribution, and it can use an installed copy of CrossOver instead, which is usually the better choice for those who own it. Both are also offered for games of every other type that include a compatible Windows executable, next to their native runtime. See [Windows games through WINE](https://procrastinine.github.io/maclauncher/games/windows.md). ### How do Android games run? By default through MacLauncher Android, which runs the Android framework without an emulator or a virtual machine. It has two modes in one runtime: **JVM**, the default, converts the app's code to run on Java, and **ART** uses Android's own runtime instead. If a game misbehaves in one mode, the other is worth a try. [Mac.apk](https://github.com/kksimp/Mac.apk) and [AIM](https://github.com/hahnlee/aim) are alternative runtimes, and all three need Apple Silicon. [Choosing a runtime](https://procrastinine.github.io/maclauncher/background/choosing-a-runtime.md#android-games) compares them. ### Is it an emulator? Mostly not. Most runtimes run the game's own engine natively on macOS, or run the game's code on the Mac's real processor while translating its system calls, the way WINE does. DOS games are the exception, through [DOSBox Staging](https://www.dosbox-staging.org/). [How games run on a Mac](https://procrastinine.github.io/maclauncher/background/how-games-run.md) explains the difference. ### What about decompilation and recompilation ports? [Decompilation and recompilation projects](https://github.com/SubmitGame/awesome-decomp-games) rebuild individual games for current systems from the original game's compiled code, and most of them are older console games. MacLauncher covers a different kind of game: games built on shared engines, such as indie games packaged for Windows, Android and iOS games and visual novels, which a runtime for their engine can play. It doesn't download individual ports, but a port's macOS build works like any other Mac app: download it with a launcher such as [Quiver Launcher](https://github.com/tgeorgiadis/quiver-launcher) and drag it into MacLauncher. [Mac apps and scripts](https://procrastinine.github.io/maclauncher/games/more.md#mac-apps-and-scripts) describes how Mac apps are imported. ### Why is it built on Electron? Browser-based games are a big share of all games, and they run on the included [Electron](https://www.electronjs.org/) without any download. The codebase can also move to other platforms later, and the launcher's own weight hardly matters once a game is running. To skip the library window entirely, save a `.command` launcher for a game and double-click that. ## Trust and verification ### Does MacLauncher collect any data? No. MacLauncher sends no telemetry. The diagnostics it records go only into its log file on the Mac, where they help trace a problem when troubleshooting, and nothing sends that log anywhere. Anyone can read MacLauncher's source on [GitHub](https://github.com/procrastinine/maclauncher) to confirm this. ### Does it connect to the Internet? Only for something you asked for: refreshing a version list, installing a runtime or tool, pressing **Play** for a game whose runtime isn't installed yet (MacLauncher asks first), using a store, or checking for updates. MacLauncher makes no network requests of its own in the background, and installed runtimes work offline. The only exception is one you have to turn on: **Check for updates at launch** in **Settings → Launcher** looks for a new MacLauncher each time it starts, and it's off by default. Games run without Internet or local-network access unless their **Network access** setting allows it, and **Settings → Launcher** sets the default for newly added games. ### How is MacLauncher updated? Choose **Check for Updates…** in the MacLauncher menu, or the same button in **Settings → Launcher**. MacLauncher asks GitHub for its newest release, and if there's a newer one it offers **Download and Restart**. It downloads the same build that's running, Apple Silicon or Intel, checks it against the SHA-256 checksum published with that release and against its code signature, and swaps it in when it restarts. The old copy goes to the Trash, and your library, settings and saves stay where they are. Sometimes MacLauncher can't replace itself: macOS may be running it from a temporary read-only copy because it was opened straight from the Downloads folder, or the folder it's in may not be writable. Then it offers the release page instead, so you can download the new version yourself. Moving MacLauncher to the Applications folder fixes the first case. [App updates](https://procrastinine.github.io/maclauncher/reference/UPDATES.md) lists every check. ### How can I trust MacLauncher binaries? The app and the compiled packages from [MacLauncher Builds](https://github.com/procrastinine/maclauncher-builds), the companion project that compiles game engines and helpers for macOS, are built on GitHub's own machines from public source code and public recipes. A recipe is the set of instructions and patches that turns a project's source into a Mac package. For every file such a build produces, GitHub signs a build record that names the exact source code, recipe and build run behind it. A few older package versions were built before this setup and have no GitHub build record; the verification table lists them separately as built locally. Anyone can read that source and those recipes, [check a download against its build record](#how-do-i-check-a-download-myself) with GitHub's command-line tool, and rebuild it to compare. [Verifying MacLauncher](https://procrastinine.github.io/maclauncher/reference/development/VERIFYING.md) walks through the checks for the app, and the [package verification table](https://procrastinine.github.io/maclauncher-builds/verification.html) lists build records, recipes and supplied-file checks for MacLauncher Builds packages. ### How do I check a download myself? One command with the [GitHub CLI](https://cli.github.com/), `gh`, checks a downloaded app against its build record. Set `commit` to the full 40-character commit that the release tag's source link shows, then run the command in the folder that holds `MacLauncher.app.zip`: ```sh commit=<40-character-app-source-commit> gh attestation verify MacLauncher.app.zip --repo procrastinine/maclauncher \ --signer-workflow procrastinine/maclauncher/.github/workflows/macos-app.yml \ --source-digest "$commit" --deny-self-hosted-runners ``` A passing check means that GitHub's own machines built exactly this file from that public commit, using MacLauncher's public app workflow. [Verifying MacLauncher](https://procrastinine.github.io/maclauncher/reference/development/VERIFYING.md#verify-an-app) has the full steps, including the Intel app, the build manifest and a rebuild, and [Verifying MacLauncher Builds](https://github.com/procrastinine/maclauncher-builds/blob/main/VERIFYING.md) shows the same check for a package. ### What does a build record prove? A build record proves where a file came from: which public source code and recipe built it, in which build run on GitHub's machines. Because GitHub signs the record, a file changed after the build no longer matches it, and the check fails. The record does not prove that the source itself is safe; the source is public, so it can be reviewed. A rebuild is a second, independent check. A rebuilt MacLauncher Builds package is compared byte for byte with the published one, and the verification table shows each recorded result. The app's ZIP archive is not designed to come out identical on every build, because it stores timestamps and each build signs the app locally, so a rebuilt app is compared file by file instead. ### What about software that MacLauncher doesn't build? Some components come unchanged from their publishers, such as [Python](https://www.python.org/), [7-Zip](https://www.7-zip.org/), [Electron](https://www.electronjs.org/), Valve's SteamCMD, and Adobe's Flash Player projector, which MacLauncher Builds hosts exactly as Adobe released it. MacLauncher checks those in other ways: against the checksums that publishers list, against code signatures from Apple's Developer ID program that name the publisher, or against a checksum recorded when the file was first downloaded. [Files from other publishers](https://procrastinine.github.io/maclauncher/reference/development/VERIFYING.md#files-from-other-publishers) lists how each one is checked. Closed-source components can't be rebuilt from source, so their trust rests on their publisher. ## Troubleshooting ### macOS says MacLauncher can't be opened That's [Gatekeeper](https://support.apple.com/guide/security/gatekeeper-and-runtime-protection-sec5599b66df/web), because the app is ad-hoc signed rather than signed with a paid Developer ID. Open **System Settings → Privacy & Security**, scroll down and click **Open Anyway**. [Getting started](https://procrastinine.github.io/maclauncher/getting-started.md#2-allow-it-through-gatekeeper) has the steps. ### A Mac game says it's "damaged" Downloaded Mac games, especially indie builds, often carry Gatekeeper's quarantine flag. Import the app and use **Remove quarantine** in its inspector. ### My game wasn't recognized, or was recognized as the wrong thing Try importing the whole game folder instead of a single file, or the other way round. If a folder holds several executables, drag in the main `.exe` itself so MacLauncher knows which one is the game. A Windows game whose engine isn't recognized still imports, as a Windows Game, and runs through Sikarugir or CrossOver. ### A game shows Unavailable Its files aren't where MacLauncher last found them, usually because the drive is unplugged or the folder has moved. Reconnect the drive at the same location; MacLauncher notices the next time its window comes to the front, **Play** is pressed or **Detect all missing** runs. For a game that has moved for good, **Locate…** in the inspector points the library entry at the new location and keeps its saves, settings and effects. [Games on an external drive](https://procrastinine.github.io/maclauncher/launcher.md#games-on-an-external-drive) explains both. ### A runtime or effect says this Mac can't run it Some runtimes need Apple Silicon, and some graphics features need Apple Silicon or a newer macOS. The message names the requirement, and [Macs and macOS versions](https://procrastinine.github.io/maclauncher/macs-and-macos.md) lists them all. On an Apple Silicon Mac, the Apple Silicon app is the right one; the Intel app also runs there through Rosetta, but it picks Intel builds. ### The game won't start, or crashes Work through these, roughly in order: 1. Try another version of the same runtime in the inspector. Engines such as [Godot](https://github.com/godotengine/godot), [Unity](https://unity.com/) and [GameMaker](https://gamemaker.io/) are picky about versions. 2. Try another runtime. A game with a compatible Windows executable also offers Sikarugir and CrossOver, and Android games have three runtimes, with JVM and ART modes in MacLauncher Android. 3. Check the Runtime Settings. For WINE games, switching the graphics backend fixes many rendering problems, and Japanese games may need the `ja_JP.UTF-8` locale. 4. Turn off graphics effects to rule them out, then add them back one at a time. 5. Look at the log: **Help → Show Log in Finder** reveals MacLauncher's log file. ### The first launch takes a long time The first launch may download the runtime, and some games need preparing: Switch games are extracted and their shaders compiled, PS5 games are converted, Android apps are prepared, and WINE games get a private Windows environment. Progress is shown while this happens, and later launches reuse the result. ### Effects don't seem to change anything Check that **Graphics** is switched on for the game and that the effect isn't bypassed in the chain. Temporal upscalers and some depth effects need extra information from the game's renderer, so they only work where a runtime supplies it. The [graphics section](https://procrastinine.github.io/maclauncher/graphics.md) explains which effects need what. ### How do I uninstall MacLauncher? Quit it and delete MacLauncher.app. To also remove installed runtimes, settings and MacLauncher's per-game data, delete `~/Library/Application Support/maclauncher/`. Game folders are untouched either way. ## Still stuck? Search for the problem or open an issue on [GitHub](https://github.com/procrastinine/maclauncher/issues). Mention the game, its detected engine (shown in the inspector), the runtime and version used, and attach the relevant part of the log. --- # Credits and licenses > Where the images on this site come from, their licenses, and the projects the site is built with. Web page: https://procrastinine.github.io/maclauncher/about/credits/ MacLauncher builds on a large body of open-source work. The [attributions](https://procrastinine.github.io/maclauncher/reference/ATTRIBUTIONS.md) list every upstream project with its role and license, and the app's **Credits** window links to them as well. This page covers the website itself. ## Site images | Image | Source | License | | --- | --- | --- | | MacLauncher icon | [MacLauncher](https://github.com/procrastinine/maclauncher) | [MIT](https://github.com/procrastinine/maclauncher/blob/master/LICENSE) | | Library screenshot (home page, introduction and link previews) | A MacLauncher window showing the Android version of [Shattered Pixel Dungeon](https://github.com/00-Evan/shattered-pixel-dungeon) by Evan Debenham, with [CRT Royale](https://github.com/akgunter/crt-royale-reshade) | Shattered Pixel Dungeon: [GPL-3.0](https://github.com/00-Evan/shattered-pixel-dungeon/blob/master/LICENSE.txt); CRT Royale: [GPL-2.0](https://github.com/akgunter/crt-royale-reshade/blob/master/LICENSE.TXT) | ## Effect sample images Before-and-after examples on the [Graphics and effects](https://procrastinine.github.io/maclauncher/graphics.md) pages use screenshots of the following games, from the sources listed. They appear here only to illustrate the effects, and all rights remain with their owners. | Image | Source | Copyright | | --- | --- | --- | | Madeline among wind-blown flags (upscaling and neural upscaling examples) | [Celeste on Steam](https://store.steampowered.com/app/504230/Celeste/) ([screenshot](https://shared.akamai.steamstatic.com/store_item_assets/steam/apps/504230/ss_e0159d08620e917e632788c960d9593e5e7f431c.1920x1080.jpg)) | © Maddy Makes Games Inc. | | Ciri, Geralt and three riders on a road (upscaling, restoration, color, palette and frame generation examples) | [The Witcher 3: Wild Hunt on Steam](https://store.steampowered.com/app/292030/The_Witcher_3_Wild_Hunt/) ([Ciri](https://shared.akamai.steamstatic.com/store_item_assets/steam/apps/292030/203487f667e4ac00baf482b1c93c87a2b830a6fc/ss_203487f667e4ac00baf482b1c93c87a2b830a6fc.1920x1080.jpg), [Geralt](https://shared.akamai.steamstatic.com/store_item_assets/steam/apps/292030/3a3f430982cc3bccac1633d3ea60a30bf3d1ae9e/ss_3a3f430982cc3bccac1633d3ea60a30bf3d1ae9e.1920x1080.jpg), [riders](https://shared.akamai.steamstatic.com/store_item_assets/steam/apps/292030/8a97157ec7e4f3d458d70a0942779f093f404d8c/ss_8a97157ec7e4f3d458d70a0942779f093f404d8c.1920x1080.jpg)) | © CD PROJEKT RED S.A. The Witcher® is a registered trademark of CD PROJEKT RED S.A. This is an unofficial fan work and is not approved/endorsed by CD PROJEKT RED. | | Sonic and Tails in Chemical Plant Zone, from Sonic the Hedgehog 2 (CRT and overview examples) | [Sonic Origins on Steam](https://store.steampowered.com/app/1794960/Sonic_Origins/) ([screenshot](https://shared.akamai.steamstatic.com/store_item_assets/steam/apps/1794960/ss_7e93ca3dbea7d6a1396a4a1da2f3202c16935100.1920x1080.jpg)) | ©SEGA. All rights reserved. SEGA, the SEGA logo and SONIC ORIGINS are registered trademarks or trademarks of SEGA CORPORATION or its affiliates. | | Joe Musashi, from Shinobi III: Return of the Ninja Master (CRT example) | [SEGA Mega Drive and Genesis Classics on Steam](https://store.steampowered.com/app/34270/SEGA_Mega_Drive_and_Genesis_Classics/) ([screenshot](https://shared.akamai.steamstatic.com/store_item_assets/steam/apps/34270/ss_046569000a9c5cc6cc102cffa0c473cd46804ba1.1920x1080.jpg)) | © SEGA. SEGA and the SEGA logo are either registered trademarks or trademarks of SEGA Holdings Co., Ltd. or its affiliates. All rights reserved. | | Nagisa under the cherry blossoms (visual novel upscaling and chain examples) | [CLANNAD on Steam](https://store.steampowered.com/app/324160/CLANNAD/) ([screenshot](https://shared.akamai.steamstatic.com/store_item_assets/steam/apps/324160/ss_0ea83794c5f87b402f2975ad4000ce7eac42544f.1920x1080.jpg)) | © VISUAL ARTS/Key / Sekai Project | | A Mars City worker in a break room, from DOOM 3 (neural rendering chain example) | A 3840×2160 gameplay capture from [DOOM 3](https://store.steampowered.com/app/9050/DOOM_3/) | © id Software / Bethesda Softworks (ZeniMax Media) | For the examples, the screenshots were cropped and scaled, then processed with the effects named in each caption. The pixel-art frames were reduced to their native resolution by sampling the center of each enlarged pixel. The restoration examples add synthetic noise or motion blur before processing. ## Built with This site is built with [Astro](https://astro.build/) and [Starlight](https://starlight.astro.build/) (both MIT), and its search runs locally in your browser with [Pagefind](https://pagefind.app/) (MIT). Game and product names belong to their respective owners and are used here only to describe compatibility.