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 was 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.