ScummVM can pin a CPU core at 100% even on modern hardware and it happens because of three things working against you at once: a software scaler that redraws every pixel on the CPU, a demanding audio emulator, and a game loop that runs as fast as the machine allows. The good news is that each of those is a setting you can change in about a minute.
This guide explains the cause briefly and then walks through every fix in order of impact. Most readers will see a big drop after the first two changes alone.
Why does ScummVM use so much CPU?
ScummVM is not an emulator in the traditional sense. It re-implements the game engines directly, which means it handles graphics, audio, timing, and input entirely in software. On most modern desktops that is not a problem. But a few default settings push the workload much higher than it needs to be.
The biggest culprit is usually the graphics pipeline. By default, ScummVM uses the SDL Surface graphics mode, which does all scaling on the CPU. A game running at 320×200 needs its pixels multiplied up to fit your screen, and that multiplication happens thousands of times per second in software. Switch the renderer to OpenGL and the GPU takes over that job, which is what GPUs are built for.
The second source of load is audio emulation. Emulating an AdLib sound card or a Roland MT-32 in software takes real processing power. The MT-32 emulator, in particular, has very high processor requirements ScummVM’s own documentation warns that ‘a fast CPU is strongly recommended.’ FluidSynth with a large soundfont file can cause the same problem.
The third factor is the game loop itself. When nothing throttles the frame rate, ScummVM loops as fast as it can, feeding work to the CPU even when the game on screen hasn’t changed. Enabling vsync caps the loop to your monitor’s refresh rate and lets the CPU rest between frames.
Fix 1: Switch the graphics mode to OpenGL
This is the single most effective change for most users. OpenGL mode hands the scaling job to the GPU, which can do it in a tiny fraction of the time the CPU would spend on it in SDL Surface mode.
To switch:
- Open ScummVM and select the game you want to configure.
- Click ‘Game Options’ (or the gear icon in grid view).
- Go to the Graphics tab.
- Set Graphics Mode to OpenGL.
- Click OK and launch the game.
You can also change this globally in Global Options if you want it to apply to every game. The OpenGL mode also handles aspect ratio correction more cleanly than the SDL Surface mode, so the picture often looks better too.
One thing to note: in OpenGL mode the scaler setting has no effect, because the GPU handles scaling directly. You gain GPU acceleration but lose access to the software scaler list. For most games, that is a trade you should make.
Fix 2: Drop to a lighter scaler (if staying in SDL Surface mode)
If you need to stay in SDL Surface mode for any reason, the scaler you choose has a large effect on CPU load. ScummVM’s documentation is clear that every scaler other than Normal 1x carries a speed penalty.
The scalers go from lightest to heaviest roughly like this:
| Scaler | CPU cost | Image quality |
| Normal 1x | Lowest — no scaling | Original resolution, no filtering |
| Normal 2x / 3x / 4x | Low — integer scaling only | Clean pixel look, no smoothing |
| AdvMAME 2x / 3x | Moderate | Sharpens edges using nearby pixels |
| Edge 2x / 3x | Moderate to high | Anti-aliased, very clean result |
| HQ 2x / 3x | High — slowest option | Smooth, high-quality anti-aliasing |
If your CPU is struggling, set the scaler to Normal 2x. You get a clean doubled image with almost no processing overhead. Normal 1x runs at the original game resolution, which looks tiny on a modern display but uses the absolute least CPU.
To change the scaler, go to Game Options or Global Options, select the Graphics tab, and pick your scaler from the Scaler dropdown. Remember this setting only applies when using the SDL Surface graphics mode.
Fix 3: Choose a less demanding audio emulator
Audio emulation is often the hidden villain in ScummVM CPU problems. If your game uses AdLib music (the OPL chip sound that most classic adventure games default to), you have three emulator options in ScummVM: MAME, DOSBox, and Nuked.
According to ScummVM’s audio documentation, MAME is the least accurate of the three and uses the least CPU power, while Nuked is the most accurate and the most CPU-intensive. DOSBox sits in the middle.
For most players, MAME sounds perfectly acceptable. The accuracy difference between MAME and Nuked is only noticeable if you have a reference point to compare against.
- To switch the AdLib emulator:
- Open Global Options (or Game Options for a specific game).
- Go to the Audio tab.
- Find the AdLib Emulator dropdown (labelled ‘OPL Emulator’ in some versions).
- Select MAME.
- Click OK.
This one change can noticeably reduce CPU load in games with active background music.
Fix 4: Drop the MT-32 or FluidSynth emulator if you don’t need it
If you have the MT-32 emulator enabled, disable it unless you specifically want MT-32 audio. ScummVM itself describes the processor requirements for MT-32 emulation as ‘quite high,’ with a fast CPU ‘strongly recommended.’ Running it on an older or mid-range machine can peg a CPU core entirely, especially during scenes with complex music.
The same applies to FluidSynth. FluidSynth with a large soundfont can demand significant processing power. If you do want to use FluidSynth, try a smaller soundfont file a 30MB general MIDI soundfont does the job for most games and is far lighter than a 150MB orchestral one.
To check what audio device your game is using:
- Open the game’s options (Game Options from the launcher).
- Go to the Audio tab.
- Check the ‘Music device’ or ‘Preferred device’ field.
If it says MT-32 or FluidSynth, switch it to AdLib (MAME) or your system’s native MIDI synthesiser.
On Windows, the native GS WaveTable Synth uses almost no CPU. On macOS, the Apple DLS software synthesizer works the same way. Neither sounds as good as MT-32 emulation, but both are essentially free in terms of processing cost.
Fix 5: Enable vsync to cap the frame rate
Without vsync, ScummVM’s game loop runs uncapped. The engine keeps drawing and redrawing as fast as the hardware allows, even when the game’s actual animation hasn’t changed. On a fast machine that means the CPU stays busy doing work that produces no visible benefit.
Enabling vsync locks ScummVM to your monitor’s refresh rate typically 60 frames per second. Once a frame is drawn, the loop waits for the display to be ready before drawing another. During that wait, the CPU is idle, which is exactly what you want.
- To enable vsync:
- Open Global Options.
- Go to the Graphics tab.
- Tick the ‘Vsync’ checkbox.
- Click OK.
Tip: vsync works best with the OpenGL graphics mode. Combining OpenGL and vsync together gives you GPU rendering capped to your monitor’s refresh rate — the lowest CPU load ScummVM can realistically achieve.
Fix 6: Check the ‘Avoid delayMillis’ option
ScummVM includes a per-game option called ‘Avoid delayMillis’ for certain game engines, particularly Blade Runner. ScummVM’s own documentation notes explicitly that this mode ‘might result in high CPU usage.’ If you see it ticked in your game’s options and you’re experiencing high load, turn it off.
To check this:
- Highlight the game in the launcher.
- Click Game Options.
- Look through the Game tab for any option mentioning ‘delay’ or ‘delayMillis.’
- If the option is enabled and you don’t have a specific reason to use it, untick it.
This option exists as a workaround for timing bugs in specific games, so it’s only relevant to a few titles. But it’s worth checking if nothing else has worked.
Quick-reference: all the settings in one place
Here’s a summary of every setting covered above, where to find it, and what to change it to:
| Setting | Where to find it | Change to | Expected effect |
| Graphics Mode | Global or Game Options > Graphics | OpenGL | Biggest CPU drop; moves scaling to GPU |
| Scaler | Global or Game Options > Graphics | Normal 2x (SDL mode only) | Lower software scaling load |
| AdLib Emulator | Global or Game Options > Audio | MAME | Lighter OPL audio emulation |
| Music / MIDI device | Global or Game Options > Audio | Native MIDI or AdLib | Avoids MT-32 or FluidSynth overhead |
| Vsync | Global Options > Graphics | Enabled | Caps frame loop to monitor refresh rate |
| Avoid delayMillis | Game Options > Game (specific games) | Disabled | Removes busy-wait loop for affected titles |
Apply these in order. Most users see the biggest gain from fixing the graphics mode first, then audio. You may not need all six changes — stop when the CPU load is acceptable for your machine.
Editing the configuration file directly
All of the settings above can also be set by hand in ScummVM’s configuration file scummvm.ini on Windows, or ~/.config/scummvm/scummvm.ini on Linux and macOS. The GUI is easier for most users, but knowing the config keys is useful if you’re scripting or copying settings between machines.
The relevant keys for the [scummvm] global section:
| Config key | Value to use |
| gfx_mode | opengl |
| render_mode | (leave default) |
| opl_driver | mame |
| vsync | true |
| music_driver | auto (or null for system MIDI) |
The full list of configuration file keys is documented in the ScummVM configuration file reference. Game-specific settings go under a section named for each game’s target ID, and they override the global defaults.
If CPU usage is still high after all these changes
A small number of games are genuinely CPU-intensive at the engine level. Some older SAGA engine games (like Inherit the Earth) update the entire screen on every frame rather than just the parts that changed, which means they’re heavy regardless of scaler or renderer settings. 3D games in ScummVM (Grim Fandango, Escape from Monkey Island) also carry a higher baseline load than 2D games.
For these situations:
- Make sure you’re running the latest version of ScummVM. The team continuously improves engine performance, and the most recent stable release (2026.2.0 as of March 2026) includes ongoing engine optimisations.
- For 3D games, try OpenGL without shaders rather than OpenGL with shaders the shader pipeline adds GPU work that some integrated graphics cards handle poorly, which then pushes more load back to the CPU.
- On laptops, check your power plan. Running ScummVM on a power-saver profile can throttle the CPU below what the game needs. Setting the machine to balanced or high performance can help it handle the load smoothly, at the cost of battery.
- If your machine has an integrated GPU shared with the CPU (common in laptops), OpenGL mode still helps but can’t reduce load as dramatically as it does on a discrete GPU, because both share the same chip power budget.
Frequently asked questions
Why is ScummVM using 100% CPU on a fast computer?
Usually because the game loop is running uncapped and the SDL Surface renderer is doing all the pixel scaling in software. Enable vsync and switch to OpenGL mode in Global Options. Those two changes together bring most systems from 100% down to under 20%.
Does changing the graphics scaler actually reduce CPU load?
Yes, but only when using the SDL Surface graphics mode. Scalers like HQ 2x and HQ 3x use lookup tables and process every pixel, so they’re noticeably heavier than Normal 2x. If you switch to OpenGL mode, the scaler setting has no effect — the GPU handles scaling instead.
Will switching to the MAME AdLib emulator affect how the music sounds?
There is a small accuracy difference between MAME and the Nuked emulator, but it is subtle and most players can’t hear it without a direct comparison. MAME emulates the OPL chip well enough that all the music plays correctly — it just skips some of the finer emulation details that eat CPU.
Is there a way to limit ScummVM CPU usage from outside the app?
You can lower the process priority using Task Manager on Windows (right-click the process > Set Priority > Below Normal) or the nice command on Linux. This doesn’t reduce the raw work ScummVM does, but it lets other processes get more CPU time. Fixing the settings inside ScummVM is always better than throttling it from outside.
Conclusion
ScummVM’s high CPU usage almost always comes down to the same three causes: software rendering in SDL Surface mode, a heavy audio emulator, and an uncapped game loop. Switching the graphics mode to OpenGL is the biggest single fix. Pairing that with the MAME AdLib emulator and vsync enabled takes care of the other two. Most players who go through these steps end up with CPU usage well below 20%, even on older hardware, and the games play exactly as they should.
Recommended Articles:
How to Test the Thermal Lottery on a CPU
How to Clear CPU Cache (and What Actually Speeds Up a Slow PC)
