VOGONS

Supreme Commander Forged Alliance crash under Windows 11 Arm in Parallels

Topic actions

First post, by mboro1876

Posted on 
User metadata
Rank Newbie
Rank
Newbie

Hi all,

Hope someone can help. I have an M1 Mac with Parallels running Windows 11 Arm. Supreme Commander Forged Alliance works fine (using the 'Safe Emulation' option) except that most of the weapon effects are missing. I'm therefore trying dgVoodoo2_86_4, and have been trying the version with debugging enabled. I get the game appearing to start, a dgVoodoo watermark black background, and then the Parallels virtual machine suspends after the game crashes.

The SupCom debug viewer claims that it ran out of memory (see the reports below) though there's no sign on the Windows resource monitor that this happened. The dgVoodoo debug output doesn't have anything obvious.

Steps tried:

- Made sure in dgVoodoo the video memory was set to 1GB (Parallels allocates 8GB to my virtual machine)
- Set the output API to DirectX 11 rather than 12. All DirectX 11 versions give the same error, whereas DirectX 12 gives the 'unable to create Direct3D error', presumably an issue with Parallels not supporting DirectX 12 properly or something.
- Set the Supreme Commander exe to various different Windows versions for compatibility, with no effect.
- Tried the MS WARP output API. The game launches and seems to run, but at 1-2 FPS of course.

I'd be grateful for any ideas for troubleshooting steps or experiences of the same error behaviour, or of this game working for others under similar conditions.

SupCom Debug viewer:

c:\work\rts\main\code\src\libs\gpggal\DeviceD3D9.cpp(475) Ran out of memory

Unknown symbol (address 0x004417fc)
Unknown symbol (address 0x0079ef71)
Unknown symbol (address 0x00913c62)
Unknown symbol (address 0x0ea81d3b)

DebugView:

[13180] [dgVoodoo CPL] INFO: Writing INI version of config to file C:\Program Files (x86)\GOG Galaxy\Games\Supreme Commander Forged Alliance\bin\dgVoodoo.conf.
[4984] D3D11: Removing Device.
[14972] [TRACE] The DiagOutputDir folder is accessible
[10768] [TRACE] The DiagOutputDir folder is accessible
[10884] WindowCreated
[10884]
[10884] VisualHostingHelperHwndCreated
[10884]
[10884] OnNavigatedTo
[10884]
[10884] EnsureEdgeView
[10884]
[10884] ResetEdgeChannelPreference
[10884]
[10884] ValidateAvailableBrowserVersion
[10884] (
[10884] 143.0.3650.96
[10884] )
[10884] NotShowingPinned
[10884]
[10884] WidgetNotShown
[10884]
[10884] WidgetWindowInvisible
[10884]
[10884] WidgetNotShown
[10884]
[10884] WidgetWindowInvisible
[10884]
[10884] WidgetNotShown
[10884]
[10884] WidgetFavorited
[10884]
[10884] NotShowingPinned
[10884]
[10884] WidgetNotShown
[10884]
[10884] WidgetFavorited
[10884]
[10884] TargetChanged
[10884] (
[10884] Forged Alliance
[10884] )
[1224] D3D11: Removing Device.
[7780] D3D11: Removing Device.
[5688] D3D11: Removing Device.
[1224] D3D11: Removing Device.
[5688] D3D11: Removing Device.
[4984] D3D11: Removing Device.
[10884] TargetChanged
[10884] (
[10884] Forged Alliance
[10884] )
[11740] D3D11: Removing Device.
[5688] D3D11: Removing Device.
[5688] D3D11: Removing Device.

x86 DLLs give the same outputs, except this time in DebugView there's a message about the x86 dgVoodoo DLLs running in emulation.

Reply 1 of 6, by Dege

Posted on 
User metadata
Rank l33t
Rank
l33t

I tried this game on my ARM rig but I could only make it start if I set "safe emulation" for the executable in the x86 emulation compat section.
Otherwise it couldn't compile an effect file, for some reason and failed with an error message.

So, it worked for me both with DX11 and 12, but not that great because of the strict emulation (both with the arm64_chpe_86 and plain x86 dlls).

If you run it through Parallels then you run it through a dx wrapper. As far as I know, Parallels does not have dx12 support and only partial dx11 (but I don't have any firsthand experience).
But, if my memory serves, it had quite good dx9 support. So, what if you just run it without dgvoodoo?

Anyway, "DX11 device remove" is not a good sign at all and indicates some error in the dx11 implementation. If you're interested, you can check out the dx11 debug log through the windows sdk. Or try out dgvoodoo _dbg version to see the dgvoodoo log. Or another game/demo through dgVoodoo to see if it works.

But honestly I don't think there is much chance it will.

Reply 2 of 6, by mboro1876

Posted on 
User metadata
Rank Newbie
Rank
Newbie

thanks a lot for the reply.

So yes I tried without dgVoodoo at all, it runs well except that all the weapons effects don’t render. I suppose that means either Parallels, or Windows 11 Arm, doesn’t implement DX9 perfectly?

I’m not seeing anything clear on the dgVoodoo dbg alerts viewed through DebugView. Is the DX11 debugging through Windows SDK a separate process, ie looking for debugging flags in DX11 itself rather than dgVoodoo?

Thanks so much

Reply 3 of 6, by Dege

Posted on 
User metadata
Rank l33t
Rank
l33t

Here I described, for an other case, how to install and use the Windows SDK to get the DX dbg layer log, but I'm not sure if it worths to mess with it:

Re: A newbie problem

And for the dgVoodoo log, you must use the spec-release version, the .zip with "_dbg" in their name.

mboro1876 wrote on 2026-01-01, 16:45:

So yes I tried without dgVoodoo at all, it runs well except that all the weapons effects don’t render. I suppose that means either Parallels, or Windows 11 Arm, doesn’t implement DX9 perfectly?

It's Parallels itself who provides a DX9 driver to the Windows install in the VM. So, Parallels probably doesn't correctly implements everything.
TBH, I had to make a fix for this game in dgVoodoo because it utilizes an edge case feature of DX9 and I guess that feature is not implemented in the Parallels driver either.

Reply 4 of 6, by Squall Leonhart

Posted on 
User metadata
Rank Member
Rank
Member

the parallels driver is a CodeWeavers CrossOver wrapper around Wine, limited to the capabilities of the apple opengl icd, can't expect full capability.

Reply 5 of 6, by Dege

Posted on 
User metadata
Rank l33t
Rank
l33t

No, that's a completely different stack, dx->vulkan->Metal on/from Wine.

By default, the DX drivers are written by Parallels, nothing to do with wine.
Just like under VMWare.

Reply 6 of 6, by Squall Leonhart

Posted on 
User metadata
Rank Member
Rank
Member
Dege wrote on 2026-01-01, 19:35:

No, that's a completely different stack, dx->vulkan->Metal on/from Wine.

By default, the DX drivers are written by Parallels, nothing to do with wine.
Just like under VMWare.

I see, the DX9 was based on Wine circa 2007, but things have changed since then i guess.

If they are utilising Metal than they are hitting the same problem as MoltenVK where the vertex shaders behave differently, and Geometry shaders don't exist at all.

Go to top of page Go to top of page
Back to dgVoodoo General
Close window
Close window