The "shadow buffers" feature was actually an embellishment in the form of extra samples from dgVoodoo 2 that I assumed was hardware-accurate. I think the hardware actually did only a regular bilinear tap (but I don't have the hardware and I haven't done empirical testing - so I can't say for certain).

The "dref scaling" feature (d3d8.scaleDref) however is a config option necessary for Splinter Cell. Its shaders expect nonstandard behavior with non-normalized integer depth values. However it seems to never have been added to the config for that game and the spinoff games that shares its engine. So that definitely needs to be fixed

It appears we'll need a similar PR for Splinter Cell: Pandora Tomorrow according to this page. Can someone test and commit that? I don't own that game.

If nobody else has it I can try to find the discs and test locally.

I think the hardware actually did only a regular bilinear tap (but I don't have the hardware and I haven't done empirical testing - so I can't say for certain).

If you have a way that can be captured (perhaps with a test?) I have a GeForce 4 Ti 4800 in my retro PC, so can shed some light here.

It appears we'll need a similar PR for Splinter Cell: Pandora Tomorrow according to this page. Can someone test and commit that? I don't own that game.

It's ever more critical for Pandora Tomorrow, as stealth detection mechanics in some sections of the game depend on shadow buffers working properly. Because there's no way to cater for that on modern hardware, the game is currently unavailable digitally (and it's the only game in the Splinter Cell series that's in this particular situation).

I have the game and can test it, but whatever worked for the first game in the series will most likely also work here, since both are using the same engine.

scaleDref appears to be enough for Pandora Tomorrow, however the original Splinter Cell still doesn't look age accurate (see below)

FYI: I restored this shadow buffers branch at some point, see here -- but it didn't result in the expected results.

Still looking forward to seeing this being supported.

from my PR:

Splinter Cell seems to expect its shaders to do a perspective divide when sampling shadow maps even though it never sets D3DTTFF_PROJECTED. As far I'm aware, this game never worked properly except for on legacy D3D8 drivers for Windows XP with earlier GeForce cards, so I have to assume this was a driver hack. At some point D3D8 drivers or the frontend were updated to match the D3D9 behavior, breaking the game entirely. This document from NVIDIA says that the XYZ coordinates are divided by W (it calls them STR and Q), but never mentions D3DTTFF_PROJECTED.

Without the perspective divide, shadows are broken in some (but not all) scenes rendering the game unplayable as they need to be visible for stealth. To further complicate things, the shader also seems to expect that the second texcoord (texcoord 1) also has perspective divide applied, even though texture 1 is a non-depth light cookie texture so it's not as simple as applying perspective divide for all depth textures.

What this hack does is it will simply force perspective divide for stages 0 and 1 when a depth texture/shadow map is bound to stage 0, and ignore any pleas from the game to set the texture transform flags back to zero while the shadow map is bound.

I have not been able to find any indicators the game might provide to the driver to enable a hack somehow (e.g. a FOURCC code) and a deep dive on the web has returned nothing. I was not able to find any nonstandard texture stage states passed in, and the shaders don't seem to have any special flags or extensions used. It has been nearly impossible to fully know if the game is doing anything like that because the game crashes on my machine when using renderdoc, apitrace, and d3d8to9 on Linux, so my information is incomplete. Therefore, this hack might not necessarily perfectly emulate what those drivers are doing but it makes the game work.

If someone could get a d3d8 apitrace of the game running with shadows enabled, we might be able to work out a bit more about what's going on here. I have attached a relevant save game file that would need to be traced:

• ShadowyCrates.zip

@mirh I've had a chance to test out the behavior of both games on a Radeon 9200 SE, running on a period accurate system, with some interesting results. The projected mode of Splinter Cell works, producing fairly similar results even on ATI cards:

For fun, I also tried to force hardware shadow map mode, but that resulted in a hard crash.

It's with Pandora Tomorrow where things get iffy. It appears light sources are rendered correctly, but there's no shadows (or projected shadow maps) at all, which indeed means gameplay on ATI cards is, if not "broken", then definitely sub-par:

I mean, radeon cards working seemed kind of a given. They did add the ps1.4 path and of course something would have had to work.
If any my bold claim was that even on dx10 cards the situation was fair enough at least "earlier" (though it may have been like that).

And if you report that RV280 isn't working properly conversely, I'm actually kinda surprised then? That doesn't feel right.
Is that on XP? Both with (say) a 2004 and a 2008 driver?

And if you report that RV280 isn't working properly conversely, I'm actually kinda surprised then? That doesn't feel right. Is that on XP? Both with (say) a 2004 and a 2008 driver?

It is on Windows XP with Catalyst 5.4 which IIRC was released around late 2004-2005, so should have been after the release of the game in any case. I'll try later drivers, see how that goes. I might also be getting a Radeon 9600, so can test on that as well a bit later.

That's pretty weird. Kudos for the diligence.
Uh, one other interesting thing (besides finding the driver ranges of when breakage happens, if anybody in the future will want to play with IDA) would be to try to rename the games executable and see if anything changes.
I don't know of any other old-fashioned way to shim applications, so that should be pretty telling if there are custom quirks.

Nice! Now I'm itching to replay PT on my Steam Deck 😸

They released an updated executable for PT, may be worth investigating to see how they dealt with shadows... not sure if they added back SC1-style fallback shadows or what, but it should be much easier to get a hold of for local testing:

https://store.steampowered.com/app/3929740/Tom_Clancys_Splinter_Cell_Pandora_Tomorrow/

They released an updated executable for PT, may be worth investigating to see how they dealt with shadows... not sure if they added back SC1-style fallback shadows or what, but it should be much easier to get a hold of for local testing:

We are aware, we've already had to adjust our handling of Steam vs Retail versions of the game. The Steam version does indeed fix shadows on modern hardware. I'm assuming they simply modified the dref scale in the source code, since that should be pretty easy to do (but I guess they didn't bother until today).

P.S.: PT shadows don't use the infamous "shadow buffers" of the first game, and will work correctly even on AMD assuming the dref is scaled correctly. We're already handling that part for the retail release of the game.

It's not really the best either
@Joshhhuaaa

Haven't reproduced any water issue in the location from the video using either wined3d or dxvk on amd. This is with the Steam version of the game.

Edit: Forgot it might be more interesting also testing Nvidia, but at least spoofing that in dxvk didn't change anything

I'm not sure if you'd rather a new issue for this or what but @Joshhhuaaa pointed me here to report this. The lights casting in these screenshots are incorrect (I've tested this on Steam Deck with and without proton compat layers). This is the Steam version of Pandora Tomorrow that recently released. If any more information is needed then please ask. It seems to be the only major graphical issue for this game on Linux/Steam Deck right now.

The lights casting in these screenshots are incorrect (I've tested this on Steam Deck with and without proton compat layers). This is the Steam version of Pandora Tomorrow that recently released.

We've already adjusted things for the Steam release, it should be fine on the latest master code. Long story short, the Steam release fixed the shadows on modern hardware, but they were broken by our workaround which assumed they didn't work. It's a mess, because now we only have to apply the workaround for the retail release and not Steam, but as long as you don't change the installation structure, it's all good now.

P.S.: Reminder that on Proton you need PROTON_DXVK_D3D8=1 to even use dxvk for d3d8 games.