Integrate dominion wars fixes?

[yochenhsieh]

Hello,
Thank you for your efforts developing the wrapper to fix many old games!
I wonder if it's possible to integrate Star Trek: Deep Space 9 - Dominion Wars fixes here?
http://jiridvorak.webpark.cz/dw/
The source code is available on the page.

Thank you!

[elishacloud]

Have you tried with the latest download build from the Actions tab? Please upload the log file.

[yochenhsieh]

dxwrapper-ds9dw.log
dxwrapper.ini.txt

install Dominion Wars
apply patch 1.04
apply no-cd fix (perhaps optional, but I always use it; still requires a empty virtual drive.)
hexedit ds9dw.exe - replace ddraw with ddra2
copy ddraw.dll dxwrapper.ini dxwrapper.dll to game folder
rename ddraw.dll to ddra2.dll
Set compatibility mode - 640x480 (if desktop resolution is larger than 1600), 16bit.
Start ds9dw.exe

[elishacloud]

I don't see any DirectX APIs being called. I also see the following compatibity settings:

Environment variable __COMPAT_LAYER = "640X480 16BitColor DisableThemes"

I recommend doing the following:

1. Disable all settings in the ini file except dd7to9.
2. Disable all compatibility setting in Windows for that exe file.
3. If you need 16bit color then you can set the DdrawOverrideBitMode option in the ini file to 16.

[yochenhsieh]

Tried again with only dd7to9 enabled, and DdrawOverrideBitMode = 16
And this time keep ddraw.dll reference in exe unchanged.
Game will start now. But:
1- mouse cursor and gui rendered incorrectly.
2- 3D scene in game cannot be rendered
dxwrapper-ds9dw.log

Normal: (with only jiridvorak's wrapper)

.

[elishacloud]

Looks like there is a lot of stuff in this game that is not yet supported by dd7to9. Here is a list of some items:

13072 12:07:04.508 m_IDirect3DViewportX::AddLight Error: Not Implemented
13072 12:07:04.992 m_IDirect3DVertexBufferX::ProcessVertices Warning: 'D3DVOP_CLIP' not handled!
13072 12:07:04.992 m_IDirect3DVertexBufferX::ProcessVertices Warning: 'D3DVOP_EXTENTS' not handled!
13072 12:07:04.994 m_IDirect3DViewportX::TransformVertices Error: Not Implemented
13072 12:07:11.516 m_IDirect3DViewportX::DeleteLight Error: Not Implemented

I recommend disabling dd7to9 and just trying DDrawCompat.

BTW: Given the incorrect color of the dash, I suspect that DdrawOverrideBitMode = 16 may not be needed.

[yochenhsieh]

Crashed to desktop after game start if using DDrawCompat. Tried all 3 versions (2.0 2.1 3.2)
dxwrapper-ds9dw.log

[elishacloud]

Ok, try this one. I implemented all the missing functions in Dd7to9, including AddLight, DeleteLight and TransformVertices.

Here is the testing build: dxwrapper.zip

[yochenhsieh]

Great improvement!
Mouse cursor and gui rendered correctly.
Only 3D scene not rendered.

log file:
dxwrapper-ds9dw.log

[elishacloud]

I will need to look into this more. I noticed this log:

5956 21:32:58.731 m_IDirect3DVertexBufferX::ProcessVerticesUP Warning: 'D3DVOP_LIGHT' not handled!

It is possible that the 3D aspects are being rendered, but with no lighting so they show up as black.

[elishacloud]

I added support for lighting. I have no way to test it, but hopefully this will work.

Try this one: dxwrapper.zip

[yochenhsieh]

Graphically it looks same as previous version.
Log:
dxwrapper-ds9dw.log

[AsusFarstrider]

I wanted to share a working modern-Windows result that may help close the loop on this investigation.

I have now validated the North American 1.04 release of Star Trek: Deep Space Nine – Dominion Wars on Windows 11 with an AMD Radeon RX 6800 XT. Intro videos, menus, mouse input, sound, and 3D gameplay all work, and I successfully played Federation missions 1–2 and Dominion mission 1.

The decisive issue was not missing D3D operations in the rendering backend. The recovered MIT-licensed source for Jiri Dvorak’s original Dominion Wars wrapper shows that the game has a broken non-power-of-two texture path. On modern hardware, the game sees NPOT support, takes that path, and submits effectively uninitialized texture dimensions. In my crash dump, this produced dimensions of roughly 13.8 million × 13.9 million pixels, followed by E_INVALIDARG, a NULL object, and an access violation at ds9dw.exe+0x8A08.

The working DDrawCompat 0.7.1 profile is:

PalettizedTextures = on
CompatFixes = singlemonitor
CapsPatches = D3DDEVICEDESC.dpcTriCaps.dwTextureCaps|=0x2
ForceD3D9On12 = on

The important setting is the POW2 capability patch. It re-advertises D3DPTEXTURECAPS_POW2, which makes Dominion Wars avoid its defective NPOT path and use the valid texture-creation path instead.

The remaining mouse issue is separate: Dominion Wars misbehaves when the real primary desktop width is 1600 pixels or greater. I currently work around that with a launcher that temporarily switches the desktop to 1280×960, starts the game, and restores the original resolution on exit.

I have published the installer, launcher, findings, and source here:

https://github.com/AsusFarstrider/dominion-wars-modern

This is still an early alpha and has limited hardware coverage, so I am not claiming universal compatibility yet. I would be very interested to know whether this capability-patching approach is useful for dxwrapper as well, or whether the recovered root-cause information helps explain the missing 3D scene observed in this thread.

[elishacloud]

This game is using older DX version, meaning it is likely expecting the POW2 flag. According to a check-in here the flag should be there for pre-DX7 but not for DX7.

Note: dxwraper has an option to set this flag. It is a hidden option but it is called SetPOW2Caps. This option has four settings as described below:

0 = return original caps
1 = force both
2 = force D3DPTEXTURECAPS_NONPOW2CONDITIONAL
3 = force D3DPTEXTURECAPS_POW2
4 = remove both

[AsusFarstrider]

That is extremely helpful, thank you. My working DDrawCompat configuration forces exactly D3DPTEXTURECAPS_POW2, and that was the change that stopped Dominion Wars from generating the invalid texture dimensions and allowed the 3D game to initialize.
So it sounds like the equivalent dxwrapper test would be SetPOW2Caps = 3.
The recovered Dvorak wrapper source specifically documents that Dominion Wars’ non-power-of-two path leaves texture dimensions uninitialized, which matches the malformed allocation I observed in the debug log and crash dump.
I would be very interested to know whether enabling that hidden option with the existing Dominion Wars dxwrapper profile brings back the missing 3D scene.