Dark Earth crashes with "FATAL ERROR 8", same thing as natively, but DXGL seems to work so it seems to be rendering related.

Dege, ShadowBuffer Shadows in SC1 are working with a mighty FX5200 found in my drawers 😁
Standard MS WinXP SP3 drivers.

So they're not bugged in the 2002 release, the tech is working as expected (that shadow under the table doesn't show up with dgVoodoo2).

free image upload

lowenz wrote:

Dege, ShadowBuffer Shadows in SC1 are working with a mighty FX5200 found in my drawers :D […]
Show full quote

Dege, ShadowBuffer Shadows in SC1 are working with a mighty FX5200 found in my drawers 😁

free image upload

Not entirely - look at poor Fisher, all covered in darkness!

However, based on the opening 3D cutscene, it looks like what SC1 is attempting to do with its "shadow buffer" is this:

1. Render and light the scene as normal.
2. Calculate shadows.
3. Add them atop the normal scene.
4. Display results to user's monitor.

Unfortunately, the results are what is already known. dgVoodoo2 gets it almost right, but seems to miss something whereby the shadows and the scene are not added together in the correct order. In fact, it's almost like the order is flipped, with the shadow buffer rendered first, then normal lighting added to that.

Yes, but if Fisher looks at the television nearby the face is lighted (lit?) and the body projects a perfect shadow on the wall. So the tech is working (where it is supposed to work, it never was "full dynamic lighting" 😁 )
The flipped adding order is a good theory.....

Expack3 wrote:

Not entirely - look at poor Fisher, all covered in darkness! […]
Show full quote

lowenz wrote:

Dege, ShadowBuffer Shadows in SC1 are working with a mighty FX5200 found in my drawers :D […]
Show full quote

Dege, ShadowBuffer Shadows in SC1 are working with a mighty FX5200 found in my drawers 😁

free image upload

Not entirely - look at poor Fisher, all covered in darkness!

However, based on the opening 3D cutscene, it looks like what SC1 is attempting to do with its "shadow buffer" is this:

1. Render and light the scene as normal.
2. Calculate shadows.
3. Add them atop the normal scene.
4. Display results to user's monitor.

Unfortunately, the results are what is already known. dgVoodoo2 gets it almost right, but seems to miss something whereby the shadows and the scene are not added together in the correct order. In fact, it's almost like the order is flipped, with the shadow buffer rendered first, then normal lighting added to that.

This screenshot seems a bit strange to me, too.
If the lamp is the only light source in the scene then Fisher's back is black (+some ambient light), it's ok, but why isn't he casting shadow on the floor?

Anyway, I think the same as Expack, the nVidia shadow hack must have included some additional (nonstandard) 'automatic mechanism', something that one wouldn't expect through the DX interface because when I debugged the game,
then it clearly showed that shadows was rendered into depth buffers (I could see them visually through dgVoodoo's debug support), but at a later rendering stage they weren't utilized (when normal polygons were rendered).

lowenz wrote:

Dege, are you using the exe name as a key in your little database file for configuration profiles?

'cause if I remove a "mech3.exe" profile having another "mech3.exe" in another directory (2 installations) the latter entry is removed too!

No, they are only folder paths, there are no file names included.
Could you send me the your dgVoodooSetupPaths.dat file (it's in ....\AppData\Roaming\dgVoodoo folder) (of course only if it doesn't contain any path that could reveal anything from your privacy or sg)? There must be something special there. 😀

Please, take a look! (nothing to hide, my love for old games is manifest 😁 )

http://www24.zippyshare.com/v/bNCcZI7F/file.html

Another one (mission start)! Look at those perfect shadows from 2002 😁

And with 2008 WHQL NVidia ForceWare 175 (More correctness! So it's really driver-dependent) (custom 640x512 resolution, so I can play with the FX5200 :p )

lowenz wrote:

Standard MS WinXP SP3 drivers. https://s31.postimg.org/5tqjxj9jv/image.pngfree image upload […]
Show full quote

Standard MS WinXP SP3 drivers.
free image upload

.....and with NVidia drivers:

!!!!!
So there's some blending too (look at the pre-baked shadow, now it's well toned down/blended)

lowenz wrote:

And with 2008 WHQL NVidia ForceWare 175 (More correctness! So it's really driver-dependent) (custom 640x512 resolution, so I can […]
Show full quote

And with 2008 WHQL NVidia ForceWare 175 (More correctness! So it's really driver-dependent) (custom 640x512 resolution, so I can play with the FX5200 :p )

A little bit strange however, because the blending should be the opposite: the closer the shadow to the casting object the stronger (and sharper) the shadow should be. 😀

Did some digging on how the GeForce 4 Ti does shadow buffering in Splinter Cell, and discovered these interesting links. In particular, I found this one rather enlightening (no pun intended):

Splinter Cell shadow system is a major part of the game. On NV2x/NV3x hardware, it runs using a technique called Shadow Buffers. This technique is rendering the scene from every shadow casting light and store a depth buffer that represent each pixel viewed by this light source. Each pixel has an X, Y, Z coordinate in the light system and these coordinates can be transformed, per pixel, in the viewer coordinate system. It’s then easy to compare with the actual depth stored in the Z buffer to figure out if the pixel viewed by the camera is the same or is occluded by the pixel viewed by the light. If they are the same, it means the pixel is lighted, if the light pixel is in front of the viewer pixel, it means the pixel is in the shadow. On all other current hardware, the game is using another technique called projected shadows (shadow projectors). The technique is somewhat similar, we render the scene from the light point of view but instead of storing the depth, we are storing the color intensity in a texture. That texture is then mapped per vertex on each object that is going to receive the shadow. To be able to have objects casting shadows on other objects that are themselves casting shadows, Splinter Cell is using a 3-depth levels shadow casting algorithm. In general, the first level is used to compute the shadow to be used on the dynamic actors like Sam. The second level is used to compute the shadow used by the static meshes like a table or boxes. The final level is used for the projection on the BSP. This system is allowing Sam to receive the shadow of a gate on him, then Sam and the gate can cast on a box and finally all three objects can cast on the BSP (ground). This system also has a distance check algorithm to determine if Sam’s shadow should be projected on a static mesh (like a box) or if it shouldn’t base on their relative position. Both systems have their own strength/weaknesses. The main advantage of the Shadow Buffer algorithm is how easy it is to work with. Shadow Projectors are tricky and difficult to use.

Expack3 wrote:

Did some digging on how the GeForce 4 Ti does shadow buffering in Splinter Cell, and discovered these interesting links. In particular, I found this one rather enlightening (no pun intended):

Splinter Cell shadow system is a major part of the game. On NV2x/NV3x hardware, it runs using a technique called Shadow Buffers. This technique is rendering the scene from every shadow casting light and store a depth buffer that represent each pixel viewed by this light source. Each pixel has an X, Y, Z coordinate in the light system and these coordinates can be transformed, per pixel, in the viewer coordinate system. It’s then easy to compare with the actual depth stored in the Z buffer to figure out if the pixel viewed by the camera is the same or is occluded by the pixel viewed by the light. If they are the same, it means the pixel is lighted, if the light pixel is in front of the viewer pixel, it means the pixel is in the shadow. On all other current hardware, the game is using another technique called projected shadows (shadow projectors). The technique is somewhat similar, we render the scene from the light point of view but instead of storing the depth, we are storing the color intensity in a texture. That texture is then mapped per vertex on each object that is going to receive the shadow. To be able to have objects casting shadows on other objects that are themselves casting shadows, Splinter Cell is using a 3-depth levels shadow casting algorithm. In general, the first level is used to compute the shadow to be used on the dynamic actors like Sam. The second level is used to compute the shadow used by the static meshes like a table or boxes. The final level is used for the projection on the BSP. This system is allowing Sam to receive the shadow of a gate on him, then Sam and the gate can cast on a box and finally all three objects can cast on the BSP (ground). This system also has a distance check algorithm to determine if Sam’s shadow should be projected on a static mesh (like a box) or if it shouldn’t base on their relative position. Both systems have their own strength/weaknesses. The main advantage of the Shadow Buffer algorithm is how easy it is to work with. Shadow Projectors are tricky and difficult to use.

Yes, that's what dgVoodoo emulates, SCPT works the same. But it all is not enough for SC1, as if sg extra was needed (nVidia driver specific way of working?).
(This shadow-buffer hack is not standard (but nVidia-specific) in DX8/9 because sampling the depth buffer implicitly contains a comparison, unlike in case of plain textures. This all got standardized in DX10 and up under the term of "comparison sampling" and became general, for plain textures too, with the usual selectable comparison functions.)

VirtuaIceMan wrote:

Just gave Small Rocket's Kayak Extreme a go (Win10 64bit). Without dgvoodoo you have to disable "water foam" in game, or it crashes (and use Win98 compatibility mode). With dgvoodoo it works, but the entire water layer is missing; invisible, removing the rendering of parts of the kayak too!

Does this game have a patch? K2PC.exe crashes immediately after launching it, even with Win98 compat mode (Win10 64bit).

Knight Rider works and dgVoodoo2's resolution forcing means it's no longer limited to its previous max resolution of 1600x1200.

Zanzarah also works nicely, resolution forcing and all. There's a resolution hack available for the game, but with dgVoodoo2 you don't have to hunt that down and you can get proper UI scaling (resolution hack displays UI elements 1:1). By default the game is limited to 1024x768.

Motocross madness 2 doesn't work with dgvoodoo 2.52.
If I don't use dgvoodoo2 I can select between software mode and directx mode (gtx780) but in directxmode with my graphic cards The only resolution is 640x480. If I use dgvoodoo 2.52, I have dgvoodoo watermark but the only option is software mode but I can select 1080p resolution.

willow wrote:

Motocross madness 2 doesn't work with dgvoodoo 2.52.
If I don't use dgvoodoo2 I can select between software mode and directx mode (gtx780) but in directxmode with my graphic cards The only resolution is 640x480. If I use dgvoodoo 2.52, I have dgvoodoo watermark but the only option is software mode but I can select 1080p resolution.

I have tried it and dgvoodoo DX renderer is recognized by the game, aswel as ddraw for menu, i guess.

Anyway, it seems it is totally broken. Some events do not work (unlocked framerate related, maybe) and some others work with lots of graphical problems, most of the field is invisible, etc.

Note: WIP24 & Windows 10 64-bit
Note2: Terrain pass seems to affect this graphical problems but none of the three options (you can choose single pass with gforce4) makes it really accurate.

Thanks but I have tried and it's not recognized on my PC with windows 10 and wip24. I have tried more than 10 times. I don't know why.

Dege, any news about the new input code?

I found some issue using dgVoodoo2 with ReShade 3.0 (beta), cause ReShade 3.0 can now block the input to use the in-app configuration menu.

willow wrote:

Motocross madness 2 doesn't work with dgvoodoo 2.52.
If I don't use dgvoodoo2 I can select between software mode and directx mode (gtx780) but in directxmode with my graphic cards The only resolution is 640x480. If I use dgvoodoo 2.52, I have dgvoodoo watermark but the only option is software mode but I can select 1080p resolution.

I've been wanting to examine that game for a long while but I always failed at installing it. As soon as I can solve that somehow, I'll fix it.

There are some good news however.
It seems I figured out the GF4-specific obscure shadow-buffering: it seems that if a depth-stencil texture is selected into the pixel pipeline, then the chip (or, maybe the driver) automatically applies projection to ALL incoming texture coordinates and DOESN'T CARE about the projection flag that the application set for the texture stages. So, shortly, it forces global texcoord projection for configurations having a depth-stencil texture. It's true that sampling a depth-stencil shadow buffer without projection doesn't make any sense in practice.
This explains why shadow buffering works at some places in the game on modern GPU's: those places are the ones where the game 'doesn't forget' to set the texture projection flags through DirectX.
I think I'll add the 'force depth projection' working mode to the 'GeForce4' preset.