You launch a 1990s game and the graphics are a psychedelic mess: rainbow smears where the menu should be, inverted colours, a palette apparently chosen by a broken kaleidoscope. This is the famous 256-colour problem, and it has been breaking classic games since Windows Vista. It is also one of the problems DxWnd exists to solve — palette emulation is among its documented features. This guide explains why the colours break, what DxWnd does about it, and how to get a specific game looking right.
Why 256-Colour Games Break on Modern Windows
Games of that era did not store a colour per pixel the way modern games do. They used a palette: each pixel held a number from 0 to 255, and a shared table said which actual colour each number currently meant. Games animated water, fire and glowing effects by rewriting the table rather than the picture — cheap and clever. The catch is that the palette was a single system-wide resource. Old Windows versions arbitrated it between programs in a way those games were written against.
Modern Windows dropped that bargain. Windows 10 and 11 do not manage a global 256-colour palette for desktop applications the way Windows 95/98 did, so when an old game sets its palette and starts drawing, nothing guarantees the numbers map to the colours the game intended. Another window, a notification, or the desktop itself can reshuffle the mapping mid-game, which is why colours sometimes start fine and corrupt after a few seconds, or look right until you Alt+Tab. If you want the wider picture of what else modern Windows changed for these games, our DxWnd on Windows 11 guide covers it.
What DxWnd Does About It
DxWnd intercepts the game’s graphics calls — the layer where palette operations live — and emulates the old palette behaviour privately for that game: the game sets and cycles its palette as it always did, and DxWnd translates the result into colours a modern window can display correctly. The game’s own palette tricks (the animated water, the pulsing lights) keep working, because from the game’s point of view nothing changed. This is part of the same DirectDraw/GDI emulation family as its window forcing, and for many 256-colour titles simply running through DxWnd with a default profile is the whole fix — no palette-specific action needed.
The Practical Steps
- Run the game through DxWnd — launched from inside DxWnd, as administrator, on the current build. For a good share of palette games this alone restores correct colours, and it is the baseline everything else builds on. Our main tutorial covers the setup.
- Keep the game at its native resolution. Palette games are almost always low-resolution titles. Set the window to the game’s own size rather than scaling it up; colour problems plus aggressive scaling can compound into a picture that is hard to judge, and you want one variable at a time.
- Do not stack palette folklore. If you previously applied compatibility settings, registry tweaks or third-party palette tools to this game, unwind them while testing DxWnd — two different fixes fighting over the same palette produce weirder colours than either alone.
- If colours are right until you switch windows, that is the shared-palette reshuffle described above. Playing in the DxWnd window without task-switching is the pragmatic answer for such titles, and it is a known characteristic of the genre rather than a fault in your setup.
- Still wrong? Some games use palette tricks unusual enough to need per-game settings in their profile. Search the project’s SourceForge forum for your title — palette problems are among the most-reported and most-solved issues there — and check whether a community .dxw profile already exists.
A Diagnostic Worth Knowing: The Screenshot Test
If you cannot tell whether the game is producing wrong colours or your display path is mangling good ones, take a screenshot while the game looks wrong. Screenshots capture what the program actually drew, before the window’s palette translation reaches your screen. If the screenshot’s colours are correct while the live window’s are garbled, the game and DxWnd’s emulation are doing their jobs and the corruption happens in the final presentation — a strong hint that a task-switch, a second graphics tool, or a display setting is interfering. If the screenshot is garbled too, the wrong colours are baked into the game’s output itself, and the hunt stays in the profile and palette settings described above. Two different answers, two different fixes — and one keypress tells you which.
The explorer.exe Myth, Honestly
Older forums prescribe a famous ritual for this problem: kill explorer.exe before starting the game, then relaunch it afterwards. There was a real mechanism behind it in the Windows XP/Vista/7 era — Explorer itself held palette entries, and removing it stopped the desktop from stealing the game’s colours. Repeating it today is poor advice: the mechanism belongs to the old palette-arbitration system, killing your shell destabilises the desktop session, and it solves nothing that DxWnd’s per-game palette emulation does not solve more precisely and safely. File it under computing folklore: historically explicable, currently obsolete.
Setting Expectations
Most 256-colour games come right under DxWnd, many with no effort beyond launching through it. A stubborn minority need specific profile settings or a fix in a newer build, because “the palette” was implemented with per-game quirks that have to be met individually. If your colours stay wrong after the steps above, the exact symptom — wrong from the first frame, or corrupting after a while — is the detail to lead with on the forum. Related display problems live in the troubleshooting hub, including the black screen guide for windows that show nothing at all.