dxwrapper
dxwrapper copied to clipboard
elishacloud
Star Trek Armada no backgrounds with Intel integrated graphics Windows 11
Hate to pile onto the "Armada doesn't work" wagon, but I'm getting the same problem as described in https://github.com/elishacloud/dxwrapper/issues/28#issue-339708355 wherein the backgrounds during the missions aren't loading.
I'm using the fix as described in https://github.com/elishacloud/dxwrapper/wiki/Star-Trek-Armada-1, and I've tried with the assets in the zip file linked from the wiki page. I have also tried using the updated ddraw.dll and dxwrapper.dll from the latest (1.0.6542.21) release with the dxwrapper.ini settings from the wiki zip.
Everything opens and runs decently (a few hiccups here and there between the opening cutscene, menus, and mission start, but nothing affecting gameplay). The only issue is the black layer blocking all background textures in both the main screen and the mini map. Ships, planets, etc. still draw, but no grids.
1.2 retail CD release, patched to 1.3 Intel Iris Xe Graphics 30.0.101.1994 (also attempted with earlier graphics driver to no avail) Windows 11 Pro No compatibility settings enabled
Let me know if you need anything else for diagnosis, and thank you for all your hard work!
Ok, try with the following update. Unzip this into the Armada folder, overwriting any existing files: dxwrapper.zip
Stumbled on this issue. Having the same problem. Still on Windows 10. No luck with the above (attached) version.
For reference, a workaround is to configure 'shroud off' in the game creation settings (although this does not help with single player story mode).
This might have to do with D3D9On12. A lot of Intel systems are using that. I need to check on this later.
I tested this and it is an issue with D3D9On12. However, I just posted an update patch that should address this issue. You can see the update here: Star Trek Armada 1 patch
Darn, no dice. (Thanks for trying though!)
Here's the log:
If it's an issue with D3D9On12, then I feel like it should be reported there. In the meantime, idk if Intel hasn't added a mechanism to switch back between that and their original/native/old trinity d3d9 codepath, but worst case scenario I suppose you could just use dxvk.
p.s. a number was missed in the "patch updated" date
Hi @mirh ,
Thanks...it's been about 10 years since I've done any DirectX programming so I wasn't aware of a bunch of the recent developments you mentioned (D3d9On12 and DxVK). I did some quick Googling/reading about these things and I think I understand what might be going on. Thanks! I'll do some tinkering!
I found out the reason that the backgrounds are missing during the missions. This game uses a rare render state type D3DRENDERSTATE_COLORKEYENABLE which is not implemented by some Intel video cards.
@Squall-Leonhart was it ever eventually possible to switch between igd9trinity and d3d9on12?
intel handles it all transparently and doesn't expose any controls for it, they arent using 9on12 at all now though.
It is optimised for UMA graphics architectures like those on mobile phones, rather than dedicated cards like the Arc Xe.
the Iris Xe should run this game fine now with the Arc and Iris Xe driver, the op was made on the DCH driver.
Ok, try with this update. I have implemented the menu using GDI and the actual game play using Direct3D9. I added a shader for D3DRENDERSTATE_COLORKEYENABLE support.
Here is the new update: dxwrapper.zip
what intel cpu do you have accwebs, there shouldn't have been any issues with the pre-Xe/XeMax/Arc/7x0 gpus in the DCH driver, and if you have one of these but still using the DCH driver then it was your issue all along.
From the dxwrapper log file here is what the graphics card is reading as:
8904 20:06:42.521 Intel(R) UHD Graphics
BTW: here are two more good discussions on color keying. Though they are related to Nvidia it is still good info.
https://github.com/narzoul/DDrawCompat/issues/116#issuecomment-946084312 https://github.com/narzoul/DDrawCompat/issues/241#issuecomment-1671964348
what intel cpu do you have accwebs, there shouldn't have been any issues with the pre-Xe/XeMax/Arc/7x0 gpus in the DCH driver, and if you have one of these but still using the DCH driver then it was your issue all along.
11th Gen Intel Core i9-11900H. It's a laptop in case that matters (idk if Intel is still doing their 'mobile vs desktop edition' thing they used to do without giving the processors a unique product number despite the difference).
The IGP in the Tigerlake-H is an Xe variant, so it is supported by the Arc and Iris drivers.
With the DCH variant, you're stuck using 9on12, which is the cause of the issue with DXWrapper
I thought both the Arc and GCC drivers were DCH-based?
They are, but Intel maintains DCH in the title and filename of the old driver that includes the 9on12 implementation for Iris/Xe parts it supports, and drops DCH from the title and file name of the Iris and Arc Xe package.
With the DCH variant, you're stuck using 9on12, which is the cause of the issue with DXWrapper
9on12 is not an issue with dxwrapper. The issue happens without dxwrapper. There are several fixes in dxwrapper for cards that use 9on12.
9on12 is not an issue with dxwrapper. The issue happens without dxwrapper. There are several fixes in dxwrapper for cards that use 9on12.
The capabilities of D3D8, DDraw and D3DImm are directly tied to the D3D9 capabilitys of the hardware and its driver, the D3D9 UMD and DX runtime in combination handle emulation of the fixed function capabilities, including those going back to the legacy DDraw D3D primitives and the colour combiner caps provided in D3D8, this is why some Drivers are better than others for legacy games with less than 32/24 bit formats.
The issue is going to happen whether you use dxwrapper or not for obvious reasons, the capabiltiy just isn't exposed by the driver with the Iris and Xe parts because it doesn't have a true legacy DX UMD, just an emulation layer,
The same driver package thats has issueson Iris/Xe/700 won't have issues with with a UHD 600 or lower because it doesn't use this shonky emulated UMD.
Once an Xe/700/Iris user installs the driver package relevant to that hardware, they will have the igd9trinity UMD registered which returns the legacy capabilities that are missing in this situation, the D3DRENDERSTATE_COLORKEYENABLE support is returned and these igp's behave like their older 600 series cousins.
the workaround you found is good for the future case where vendors just give up on a D3D9 umd, and especially so on the weird arm windows setups that don't have d3d9 at all.
Yes, I understand. dxwrapper has a feature to convert the game from DDraw/Direct3D or d3d8 to d3d9. So functions like D3DRENDERSTATE_COLORKEYENABLE need to be re-implemented on d3d9. In this case, since d3d9 does not have this function I use shaders to emulate it.
Makes sense for a promotion to D3D9 vs keeping it on D3D8, D3DRENDERSTATE_COLORKEYENABLE is definitely not a d3d9type.
Just for the records (after banging my head a little on the topic) I think one better way to frame the issue is simply that Xe drivers anywhere before 31.0.101.3959 didn't ship igd9trinity. Because "DCH" (or at least whatever still offered support for old cpus) hasn't been updated past 31.0.101.21xx, so of course it couldn't ship anything better. Also of note that for a very short time "Arc DCH" was a thing too.
This issue should be fixed with the latest update here: https://github.com/elishacloud/dxwrapper/wiki/Star-Trek-Armada-1