Compatibility Report

Yes. I dug into the actual changes between Proton 5.13-6 and 6.3-8, and I found one thing that makes your observation about the black window much more convincing.

The important part: Wine 6.3 itself has an existing Electron black-window regression

Wine 6.3's own release notes list bug #48618:

“Multiple applications show black client area on startup (Wargaming.net Game Center, Electron based apps)”

And the reported workaround was --disable-gpu.

That is very interesting for 8Bit Fiesta because the game is built on NW.js, which is essentially Chromium + Node.js + a native window layer. NW.js is explicitly Chromium-based, and its window API creates/manages native windows.

So your situation is suspiciously similar:

old Chromium/NW.js app → Wine 5.13 works → Wine 6.3 black client area

And Wine 6.3 itself documents Electron applications getting black client areas.

But there's an important catch

I don't think we can say:

"Wine 6.3 introduced the bug."

Because bug #48618 was already reported before Wine 6.3 and is listed among the bugs fixed in 6.3.

In other words, Wine 6.3 apparently contained a fix/workaround for some Electron black-window problems, rather than introducing them.

That's actually more interesting.

The release notes show that 6.3 contained a large number of user32, winex11.drv, D3D11 and graphics changes. For example:

d3d11: changes to device/context state
winex11.drv: changes involving X11 events
user32: window activation behavior
uxtheme: themed drawing changes

But nothing in the 6.3 release notes screams "we changed JavaScript".

What about JavaScript specifically?

I don't see evidence of a major JS engine rewrite between Proton 5.13-6 and 6.3-8.

Wine's jscript, mshtml, etc. weren't undergoing some giant JavaScript-engine transition during that period that would explain this.

And that's actually expected: NW.js doesn't primarily depend on Wine's JavaScript implementation.

Its JavaScript is running inside Chromium/V8, which is bundled inside the NW.js executable.

So:

8Bit Fiesta
↓
NW.js
↓
Chromium
↓
V8 (JavaScript)
↓
Chromium rendering
↓
Windows graphics APIs
↓
Wine / Proton
↓
X11 / Vulkan / OpenGL

The JavaScript itself is therefore much less suspicious than the Chromium rendering/window path.

And there's another very interesting thing

Proton 6.3-1 changed three major components simultaneously:

Wine 5.13 → 6.3
DXVK 1.7.2 → 1.8.1
vkd3d updated
FAudio updated

Valve explicitly documents those changes.

So your test:

5.13 works → 6.3 doesn't

doesn't isolate Wine.

It could theoretically be:

Wine 6.3
DXVK 1.8.1
a Proton-specific patch
interaction between them

However, the different window decorations strongly point toward Wine/window handling, rather than DXVK alone.

The window-decoration clue

This part of your observation is particularly interesting:

5.13 → old Windows 9x-ish blue decoration
6.3 → different/newer decoration

That isn't just Chromium's UI.

It's Wine rendering the native window frame/theme.

And Wine was doing substantial work around uxtheme, user32, and winex11.drv during this era. For example, later 6.x releases contain changes to themed rendering, window sizing, fullscreen conditions, and user32/winex11 behavior.

So I do think the decoration change is potentially correlated with the actual regression, rather than merely being cosmetic.

It could be something like:

Wine 5.13
↓
old X11/window implementation
↓
NW.js creates Chromium window
↓
Chromium GPU surface works
↓
GAME RENDERS ✅

Wine 6.x
↓
changed window/X11 behavior
↓
NW.js creates window
↓
Chromium GPU surface/window interaction breaks
↓
Wine frame still renders
↓
CLIENT AREA = BLACK ❌

That's a hypothesis, not proven, but it fits your observations surprisingly well.

There's also a smoking-gun-ish Wine bug

Wine's 6.3 release notes specifically identify:

#48618 — Electron applications showing a black client area

with:

--disable-gpu as a workaround.

That makes me want to try one experiment on Proton 6.3-8:

Launch option
--disable-gpu

But there's a catch: we need to make sure that argument actually reaches NW.js/Chromium, rather than being interpreted by the game/Proton.

Try:

%command% --disable-gpu

on 6.3-8.

If the game suddenly works:

HOLY SHIT.

That would strongly suggest the regression is specifically in the Chromium GPU rendering path, rather than general window management.

And it would explain why:

Wine window frame appears
JavaScript/game process is running
audio may work
Chromium's actual content is black

That is basically the exact class of problem Wine's #48618 describes.

One more thing I'd test if that doesn't work

Try:

%command% --disable-gpu-compositing

and, separately:

%command% --disable-gpu --disable-gpu-compositing

Don't use all of them at once initially; we want to know which one changes the behavior.

So my current best guess is no longer "some random Wine incompatibility."

It's:

8Bit Fiesta's old NW.js/Chromium renderer is hitting a Wine/graphics/windowing regression somewhere after Wine 5.13, and Wine 6.3's documented Electron black-client-area bug makes the Chromium GPU path particularly suspicious.

And the fact that 3.16 and 5.13 both work, while 6.3 doesn't, is very strong evidence that we're looking in the right general area.

If --disable-gpu works on 6.3, we've got a much more concrete lead.

wine 6.3 release, proton changelog