Splinter Cell

[AlpyneDreams]

See also: #65

• Works pretty well! Se below for comparison with WineD3D.
• [x] Shadows (#65) are a concern.
• [ ] Currently crashes when alt-tabbing because GetClientRect is returning 160x24 for some reason so it just infinitely tries to recreate the swapchain. Maybe the game is making the window this stupid size? I don't know.
• [ ] "Shiny textures"

[AlpyneDreams]

• [ ] "Shiny textures" may apparently be an issue that exists on d3d9 hardware and is reproduced by d9vk. Will have to look into why that's happening. I think they're in the CIA levels.

[AlpyneDreams]

• I can reproduce the issue in the CIA level
• But not the issue in the Defense Ministry level. That one works fine.
• dgVoodoo has the same issue so it may just be the game is just genuinely broken
  • Probably no point in testing WineD3D, lol

[AlpyneDreams]

• The shiny textures issue is present on GeForce FX+ but not GeForce 4 according to this tech review.
  • There must be either some incorrect behavior or a vendor hack on GF4 that's missing here...
  • It seems like the glitch might still appear for a split second on GF4. Apparently according to Vogons the game chooses render path (multi-pass vs one shader) based on a visibility check in shadow buffers.
  • Currently even for dgVoodoo 2 the only fix is to use a texture mod (in the thread). I think I will have to leave this one unsolved for a while.

[AlpyneDreams]

Note about this game is that neither D3D8 apitrace nor renderdoc+d8vk seem to work. Best I've gotten is D3D9 apitraces of d3d8to9.

[tobiasjakobi]

I've tried the game with the 1.0 release of d8vk, but I can't get shadow buffer mode to work.

I make sure that the game picks up the correct d3d8.dll (by enabling the full HUD and checking the output). So SC is definitely using d8vk and d8vk is using the correct config. The config has d3d8.useShadowBuffers set to True.

Forcing projector mode in the game's INI renders appropriate shadows (light cones are a bit blocky though), in particular the main character is casting a shadow. Switching to shadow buffer mode no shadows are rendered anymore. I'm currently testing the tutorial level, which has a corridor with a big fan, which also acts as light source. In project mode the fan casts a shadow onto the nearby wall, in buffer mode no shadow can be seen.

Going through the commit log the 1.0 release should have support for shadow buffers. So either I'm doing something completly wrong here, or the support got broken at some point.

[WinterSnowfall]

@tobiasjakobi I'm not sure I understand what the problem is. I haven't messed with game settings (it's all on high and max) and am seeing shadows (I'm assuming you were referring to the fan below):

Have you tried running the game with -shadowmode=buffer?

Since this is an UE game, it could also be something that got fixed by #163 which was merged after the 1.0 release. Long story short, we were not exposing D3DPRASTERCAPS_ZBIAS, and apparently most UE games rely on it to enable character (and potentially other types of) shadows.

[mirh]

It has been like almost a decade since I first came to know about the problem, and people banging their head against it.. but could it be that the game has a vendor-specific whitelist? Unsure if I actually had read this once, or just dreamt it.

Maybe tobias isn't using an nvidia. In which case, assuming it also works with d3d8, you could try customDeviceId=0250 and customVendorId=10DE (i.e. a GeForce4 Ti 4600).

[WinterSnowfall]

-shadowmode=buffer will force it on regardless of what card you have and is the same as force-enabling in the game's INI file. Just had a look at it, and it seems like I had done that ages ago, which is probably why I'm seeing the right behavior. IIRC the game won't auto-enable shadow buffers if left to its own devices.

[mirh]

I'm very confident that the game wasn't broken on day one, so it must definitively have some way to decide what to pick up. And UE2 doesn't have AppCompat buckets like later versions, but it's literally written in the ini that unspecified==auto-detect. Alas my disassembly skills suck too much to make a sense of what happens inside of UD3DRenderDevice::DetermineShadowMode.

[tobiasjakobi]

OK, so I've tried a few things.

First of all, the game seems to have exactly two shadow rendering algorithms, one being projector mode, the other one being buffer mode. There is nothing else. Automatic mode just means that the game decides on the algorithm based on some (currently unknown) heuristics. I don't think the heuristics is important here, as we can just force/select the mode ourselves.

Secondly, the mode passed via argument, i.e. using -shadowmode=<mode>, has a higher priority than what is stored in the INI. However it doesn't seem to make any functional difference.

I did three screenshots with project mode: Image 1 Image 2 Image 3

Image 2 illustrates what I referred to above as blocky. Still, projector mode looks surprisingly good.

Moving on to buffer mode: Image 1 Image 2

As one can see, or rather not see, this doesn't look too good.

Next I'm going to try to override vendor/device ID and checking out the changes mentioned by WinterSnowfall.

EDIT: And as you can probably guess from the HUD, the game is running on a Steam Deck.

[mirh]

This is how it should look btw https://youtu.be/nB9BTbtNyDw?t=1220

And I think presumably the d3d9 override should carry to d3d8. https://github.com/AlpyneDreams/d8vk/blob/d3c1331a8555a578b9c8a89061fc67b5a6aec767/src/d3d8/d3d8_interface.cpp#L76-L77

[tobiasjakobi]

No luck so far. I've tried the vendor/device ID override. Doesn't have any effect. I've cherry-picked the commit from https://github.com/AlpyneDreams/d8vk/pull/163 on top of d8vk-v1.0 and tested the build. Same results as before.

Currently building the d3d9/dref-scaling branch...

EDIT: Oh great, no d3d8 DLL in this branch. Trying again with d3d9/dref-scaling rebased on main.

[tobiasjakobi]

OK, now we're getting somewhere!

New screenshot with buffer mode: Image 3

This is with d3d8.scaleDref = 24 in the d8vk config.

At least the shadow cast by the fan now looks a lot more like the tech review that mirh posted. However (!) apart from these "unique" light sources, no other light source seems to cast shadows.

E.g. the projector mode screenshot I previously posted (this one) clearly shows the wall-mounted light sources in the corridor casting a shadow of Sam Fisher. I can't believe that is is how the game is supposed to look like. I skipped through the tech review and buffer mode always looks vastly superior to projector mode.

Any other ideas what I could try here? I'm thinking about trying the scellpt wrapper to see how this one looks. Or maybe dgVoodoo2 if I can get it working.

EDIT: I tried dgVoodoo2 with the config from the widescreen patch.

This is how it looks like: Image 4

Looks pretty solid. Fan is casting shadow, Sam Fisher as well. I went back into previous locations of the tutorial and my current impression is: This is how the games was supposed to look like.

[tobiasjakobi]

Another update.

So first of all: I made a mistake with my last test involving d8vk. The version string in the HUD gave it away. I realized, after reading the d3d8 device code, that the code from main is now just a wrapper around d3d9. And I just replaced the d3d8 DLL, not the the d3d9 one. The version string is from the dxvk build shipped by Proton-GE. This obviously can't work because the Dref scaling bits are inside the d3d9 DLL.

I then did a few things.

Rebased main branch from this repo on master from dxvk/upstream: https://github.com/tobiasjakobi/dxvk/tree/d8vk-main-update

Restored the d3d9/shadows branch that carries the 2x2 PCF shadow filtering implementation: https://github.com/tobiasjakobi/dxvk/tree/d3d9/shadows

Created a new branch d8vk-shadows-update with the rebased main branch, plus the d3d9/shadows commits cherry-picked on top: https://github.com/tobiasjakobi/dxvk/tree/d8vk-shadows-update

Testing was now done with the d8vk-shadows-update branch, using both the d3d8 and d3d9 DLL. I also modified the version string so that one can immediately see that the correct DLL is picked by the game. I just used the d3d8.scaleDref setting for now, leaving the d3d8.shadowFilter setting alone. This should not cause any side effects, since the code introduced for the shadow filtering is only active if the setting is set to True.

Still, nothing changed visually. A bit frustrated I began changing the d3d8.scaleDref setting. And interestingly the setting doesn't have ANY EFFECT at all. The fan shadow renders correctly even if the setting is zero, i.e. no rescaling is done. It's as if the rescaling code isn't even active.

I made two more screenshots. Both from the exact same position, the first one using d8vk, and the second one using dgVoodoo2: Image 5 Image 6

[AlpyneDreams]

It seems like there's still some issues with shadows then. I think what we're doing now is probably correct but something just needs to be tweaked to make sure all lights work. What we really need is screenshots from original GeForce 3/4 hardware because I am not confident that dgVoodoo 2 isn't juicing up the shadows with extra samples.

[WinterSnowfall]

I'll share them here too, for safe keeping.

Splinter Cell on Windows XP + a GeForce 4 Ti 4800 SE:

Splinter Cell with dxvk 2.4:

[tobiasjakobi]

Just a short note that even with the recently released DXVK v2.4, shadows still don't work properly in SC.

Even worse, the game immediately crashes on startup when you use the latest dgVoodoo2 (which is 2.82.5 for me). I went back to dgVoodoo2 v2.81.3 to make it work again.

The first screenshot shared by @WinterSnowfall (the one on native HW) is how the game renders with dgVoodoo2. Maybe native looks a bit worse because of filtering tricks that dgVoodoo2 does, but I think that's negligible.

[mirh]

Report regressions here You might also want to give a check to Komat's original fix perhaps (if self-admittedly imperfect)

[QmwJlHuSg9pa]

Even worse, the game immediately crashes on startup when you use the latest dgVoodoo2 (which is 2.82.5 for me). I went back to dgVoodoo2 v2.81.3 to make it work again.

FWIW, there is an incompatibility in v2.82.x under Linux, meaning that v2.81.3 is the latest version that works for any game (and strangely, v2.81.3 is no longer available for download, meaning that v2.81.2 is the latest available for Linux).

[mmillar-bolis]

and strangely, v2.81.3 is no longer available for download, meaning that v2.81.2 is the latest available for Linux.

Here's an archive of the page with a working download of v2.81.3: archive.org

[tobiasjakobi]

Even worse, the game immediately crashes on startup when you use the latest dgVoodoo2 (which is 2.82.5 for me). I went back to dgVoodoo2 v2.81.3 to make it work again.

FWIW, there is an incompatibility in v2.82.x under Linux, meaning that v2.81.3 is the latest version that works for any game (and strangely, v2.81.3 is no longer available for download, meaning that v2.81.2 is the latest available for Linux).

Thanks for pointing this out. At least this means I didn't do anything obvious wrong.

Also, I finished SC in the meantime with my DXVK+dgVoodoo2 setup. I have to say that, taking the release date of the game into consideration, lighting/shadows look pretty nice.