Can confirm. Tried a few settings too (GDI hooking and trying to force windowed mode struck me as the most relevant ones as the game seems to do something weird with its window) same result.

I like suggesting alternatives, so people are aware of them. DDrawCompat can scale the image to desktop like you want. cnc-ddraw can also scale the image or it can just convert the game to D3D9 so you can use dgVoodoo's D3D9 wrapper to do the scaling. I would assume DxWnd also works, but I didn't try that one.

Also I'm sure there are applications or scripts that help you restore icons/windows at mode changes when games screw them up. Though usually they're only screwed up by permanent mode changes (which it doesn't seem like Stronghold does, it didn't mess with my windows), if you learn to use Microsoft's application compatibility toolkit you can apply the "ForceTemporaryModeChange" to correct this bad behaviour.

Appreciate your reply, ZellSF. I tried DDrawCompat and it seems to be working well. Thanks a lot! I hope that one day dgVoodoo will support Stronghold 😀

If Stronghold works with the default dgVoodoo config (unforced resolution) but not with other than 'unspecified' scaling mode and otherwise, then I wouldn't be surprised if the drawing of 2D elements relies on the current window size in the game code. Since dgVoodoo (actually DXGI in the background) resizes the window to cover the whole screen in fullscreen mode then the game rendering code might scale up the position of the 2D elements into wrong positions (out of the window). Say, the game expects the game window with size of 640x480 because that is the game resolution but dgVoodoo changes the window size to, say, 2560x1440.

I'll look at it but it is a problem with other games as well.

Dege wrote on 2023-02-04, 19:08:

If Stronghold works with the default dgVoodoo config (unforced resolution) but not with other than 'unspecified' scaling mode and otherwise, then I wouldn't be surprised if the drawing of 2D elements relies on the current window size in the game code. Since dgVoodoo (actually DXGI in the background) resizes the window to cover the whole screen in fullscreen mode then the game rendering code might scale up the position of the 2D elements into wrong positions (out of the window). Say, the game expects the game window with size of 640x480 because that is the game resolution but dgVoodoo changes the window size to, say, 2560x1440.

I'll look at it but it is a problem with other games as well.

Hi Dege. I've been a big fan of your work for a long time. I found this thread when troubleshooting MX vs ATV Unleashed. What's described here is the same behaviour as i've seen in that game in Wine 6-7, Proton\GE 6-7 on Steam Deck. Boot, black screen, can hear intro videos, can navigate and exit menus (due to practising and A-B testing). Anyway, you're incredibly talented. Thanks for all you do for games preservation.

Hi! Thanks! 😎
I'll have a look into it, I must have this game as I remember testing it sometime (a year?) ago.

I checked it out and my suspicions seem to be confirmed: the game works with the default config and the black screen only appears with forced resolution or scaling modes other than 'Unspecified'.
The dgVoodoo log also contains failed Blt operations because of invalid rects.

So, it is the usual... Not a dgVoodoo problem, but the game should be patched instead. I'll look into it later.
Btw, which executable should I use? I don't have the latest patched to wide screen.