Rayman 3: Broken effects, most noticeable on sparks and lighting effects about dgvoodoo2

[dege-diosg]

I don't have the gog version, but I quickly tried it on Rayman3 demo and Rayman3 (the original) but it all worked perfectly, aside from the FPS stuttering. Both with dgVoodoo D3D8 and D3D8->dgVoodoo D3D9.

I don't know why D3D8to9 solves the stuttering issue for you (it didn't do for me, so it's completely needless in the chain). Once somebody from the Rayman community told me that there was a patch for that so I never cared about it. But it must be a similar one I made for Rayman2.

Btw, what GPU do you have? How does it run (render) through pure dgVoodoo d3d8?

[RavenMacDaddy]

I'm running a GTX 1080 with the driver that comes with the OS, simply because when I was still running Windows 10, the later drivers caused severe DPC latency that locked up the whole system for a couple of seconds out of the blue every once in a while, but I'll try to update to the latest driver for reference when I get the time and run it on a stock GOG installation to begin with and work up from there.

I'm running the game with the resolution 3840x2160x32 (32-bit 4K) - through DSR on my main monitor and native on my TV, but both exhibit the same results as described.

This resolution requires BetterRayman3 by the way.

What I've yet to test is to delete the D3D8 DLL in the root dir to force it to load the one in the system folder, although then I would still need to involve d3d8to9 obviously.

Speaking of D3D8->dgVoodoo D3D9, how do you do that exactly? Cause when I used either 8 or 9 or both it all ended up in the stuttering behavior (but with no graphical glitches), being equal to the result of never involving d3d8to9.

[dege-diosg]

Ah, BetterRayman3... That's what I'm not familiar with, but is it that contains the fix for the stuttering? Does it have its own d3d8.dll?

I have the original vanilla install of the game which uses the system d3d8.dll, obviously.
So, either I just copy d3d8.dll from dgVoodoo to the game folder to wrap the game directly to D3D11/12, or copy d3d8.dll from D3D8to9 and d3d9.dll from dgVoodoo to wrap: game->d3d8to9->d3d9->d3d11/12.

[RavenMacDaddy]

Yeah, I'm currently reading up on its thread and there's a whole lot of troubleshooting going on where your software is part of the solution rather.

Appreciate you taking the time to sort this out.

Cheers.

[dege-diosg]

I looked at BetterRayman3. It's the patch from RibShark, I should have remember it.
I installed it and it has its own d3d8.dll, indeed.
If I set 'D3d8to9' to 1 in d3d8.ini then it wraps the game to d3d9. Otherwise plain d3d8 is used (from the system folder).
So, I simply copied dgVoodoo d3d9.dll to the game folder, set D3D8to9 = 1 and played the game at 2560x1440.
But, still couldn't see rendering errors.
You might try D3D12 as output API in dgVoodoo to see if that helps.

[RavenMacDaddy]

Yeah, they're talking about enabling everything under d3d8to9 with things like single core affinity etc.

Also, trying the game with different combinations of TnL and Hardware Vertex processing.

Here's one such post: https://raymanpc.com/forum/viewtopic.php?p=1366191#p1366191

I'm gonna try step by step, enabling d3d8to9 first with said options and its included d3d8 DLL.

For some reason I've always followed a guide which pointed to BetterRayman3.DLL as a custom DLL while having no idea what that DLL actually does.

The only weird thing in all of this is that while only using d3d8to9, I always ran with standard settings in the BR3 config which was to have both TnL and Hardware vertex processing on with no issues, only when introducing wrapping to DX11 or 12 with dgVoodoo the effects start to break.

---

Gonna test your method first though, so to recap:

1. BR3 includes a d3d8.ini which includes pointing to its own DLL as a custom
2. You set D3D8to9 = 1 in the ini file which makes use of the BR3 d3d8.dll in the root of R3.

Any other arguments to keep in mind or just that single argument?

3. You copy the d3d9.dll from dgvoodoo to R3 root to wrap it to DX11 by default.

Also gonna remove my config files for dgVoodoo to make sure the default config is used.

By the way, what's the easiest way to create a new config file for dgVoodoo that uses default settings? I read the documentation but maybe I'm missing something.

---

Frequently editing this I realise I'm just rambling on, but it's just been such a troubleshoot fest while trying to figure this out.

[dege-diosg]

I played around with the game a little bit more carefully, and I think I managed to reproduce the problem.
I found a location where it's relatively easy to produce flashing empty half-translucent rectangles:

That shiny 'orb' shouldn't be there, it's flashing across various frames for a while then disappears (Rayman is just standing, his or the camera position is not changing).
This capture is from the vanilla version of the game with native D3D8, without dgVoodoo (to keep things simple).
I could reproduce it with dgVoodoo D3D8 as well and managed to trace down the Draw call belonging to those unnecessary sparkling rectangles but honestly, I couldn't see anything strange in the API call log. In fact those sparkling rectangles are continuously drawn in multiple frames but the incoming vertex data can vary, ending up in it's either invisible or not.

Based on this, and the fact that the issue arises with both native and dgVoodoo D3D8, I think it must be a bug in the game code itself. Mismanaged vertex buffers or something like that, but it's not clear what it depends on, why it comes more easily with dgVoodoo than natively.

BetterRayman3 intercepts the D3D8 calls coming from the game and modifies them before forwarding them to either 'the real' D3D8 or D3D9, depending on the config in d3d8.ini. This is to provide more resolutions, widescreen support and such. And, the fps stutter is also fixed in that, I think.

[RavenMacDaddy]

Does the same thing happen if you limit the fps to 60?

The game's framerate and physics are linked, hence abnormal results might occur the more you go past that threshold.

[RavenMacDaddy]

Alright, here are my test results, doing it step-by-step.

• Running with a stock GOG installation, I can confirm that the game doesn't stutter.
• BetterRayman3's d3d8.dll is needed to allow for d3d8to9 conversion and to load BetterRayman3.dll correctly. Hence if you install BetterRayman3, its included d3d8.dll should always be used. Without it, the game will stutter - at least on my system.
• You could use an alternative wrapper which lets you load BetterRayman3.dll as well, like DxWrapper. This will give you additional options, like using MSAA when wrapping the game to DX9, however it doesn't seem to solve the Hardware Vertex Processing issue mentioned below and it's better to run the game at a higher resolution instead (with Nvidia DSR or equivalent if needed) of using AA, so the easiest option is to use what's already included with BR3.
• While only using d3d8to9 might work without issues with a BR3 modified game without resorting to configuration alterations, adding dgVoodoo into the mix required me to turn off Hardware Vertex Processing to ensure that no effects would be broken, and I didn't notice any negative side-effects by turning this option off. Using dgVoodoo to wrap the game to the DX11 API lets me run the game with the Auto HDR feature that at the time of writing is exclusively available on Windows 11, hence turning off Hardware Vertex Processing seems to be a good trade-off.

While you indeed have to alter the stock configuration to make the game render correctly with dgVoodoo, I wouldn't consider this a fault of your software since you've yourself experienced similar broken effects with no clear technical reason why, reading up on your last post.

Therefore I consider this issue closed, but if you do have any further updates, I'll gladly read them, and I appreciate you taking the time to troubleshoot this with me.

Cheers

[dege-diosg]

I don't want to reopen this issue, just my final thoughts:

Indeed, disabling hw vertex processing solves the problem, just checked it out. dgVoodoo always does its vertex processing in hw though, aside from some extreme cases (e.g. more lights are enabled that the hw supports) or when a game explicitly calls a vertex processor method.
Neither of them applies for this game.

So, the only difference is with disabled hw vertex processing is that the game won't write the vertex data directly into the video memory but into software memory instead which is later forwarded to the GPU by dgVoodoo internally. It's a very little overhead for this game on a nowadays computer.

It also reveals the nature of the bug: the game occassionally overwrites vertex data that's not yet processed by the GPU (the whole rendering is done through dynamic vertex buffers) but it cannot occur through software vertex buffers because of how the data handled in that case.

I remember another game having this problem: Beyond Good and Evil.

[RavenMacDaddy]

I remember another game having this problem: Beyond Good and Evil.

... which totally makes sense given it's the same team at Ubisoft during that era.