Flashlight glitches in one area while using WineD3D (d3d9 files)

[Polymega]

Hi guys,

Don't ask me how I came across this bug 'cause I don't even know: https://youtu.be/apBrNkB0IZE Update: New spot: https://youtu.be/T87IEMVuXSg

What causes this: Using the WineD3D files (using d3d9.dll, wine3d.dll, and libwine.dll)

Issue: If you boot the game and load the motor home save point (after you've acquired the flashlight) and simply spin around inside the motor home James' flashlight loses its per pixel shading and turns into a hard edge light source instead.

If you pause the game or leave the motor home the flashlight fixes itself from then-on-forward.

However, this only happens if you load that save point first upon a fresh game boot. If you load another save point first then load the motor home save point the bug won't happen. It can be replicated every time upon a fresh game boot.

Also, I had this happen to me in one other area but didn't think to record it at the time and can't remember where it occurred. I loaded several other random save spots upon a fresh game boot and the issue did not occur. I'm not sure what circumstances within the game cause this to only happen in certain areas and only on a fresh game/save load.

[elishacloud]

Personally I would like to stop using WineD3D. It adds a few other issues as well and increases the complication.

[nipkownix]

Pardon my ignorance, but.. why is WineD3D necessary? I was under the impression you guys were using crosire's d3d8to9 alone. Is there really a need to wrap DirectX to OpenGL?

[Polymega]

For Nvidia cards, it's pretty much a must.

It fixes the black lines of faces issue; restores missing fog effects such as at the beginning of the game (observation deck area); restores special overlays (such as the closet bars while we're watching RPT through James's eyes as he's hiding in the closet); and, probably the biggest buff, it alleviates the white shaders issue.

AMD cards only suffer from the black lines on faces issue which can be allievated by only using D3D8to9 as it seems just bumping the game up to DX9 cures that issue.

[nipkownix]

That's intriguing. I don't think I ever faced these issues on my Nvidia card using dgVoodoo2. I'm not sure what they even look like, to be honest.

[Polymega]

using dgVoodoo2

That's probably what fixes the issues for you. Do me a favor and temporarily disable/remove from the directory the dgVoodoo2 files and start a new game. Go to the fenced off tunnel. It should be white for you here?

https://youtu.be/878F2cbLAXo?t=2m39s

[Polymega]

Ah, another thing it fixes for Nvidia cards: Using the WSF without WineD3D there will be chunks of the wall that "deload" around the edge of the camera frame without it:

https://www.youtube.com/watch?v=hzdAhOvpGfA

[Polymega]

@elishacloud I'm not a fan of asking because of all the tremendous work you have already been doing and may continue to do so elsewhere (such as allowing for high res static 2D images) but if there's a way to grab the bits n' pieces of what makes WineD3D fix SH2 to be integrated into the likes of the SH2 Enhancement mod instead I'm sure there would be no contesting that. Also because the less files having to be used on the user's end the less likely for failures elsewhere.

[elishacloud]

if there's a way to grab the bits n' pieces of what makes WineD3D fix SH2 to be integrated into the likes of the SH2 Enhancement mod instead

WineD3D is open source, so it is possible to take code from there to make a mod. However, WineD3D converts everything into OpenGL rather than DirectX. Also WineD3D is such a large project I am not sure I could figure out what part of it is needed to fix the Silent Hill 2 issues. It would probably be better to manually fix the issues one-by-one, rather than pulling code from WineD3D. I will add these to my list.

BTW: @brunibunny says he is using dgVoodoo. Have you looked into using that instead? You should be able to just copy the d3d8.dll file from dgVoodoo rather than the d3d8.dll file from d3d8to9.

[Polymega]

BTW: @brunibunny says he is using dgVoodoo2. Have you looked into using that instead?

I haven't given dgVoodoo2 much time on my end. About a year back now another GitHub user mentioned to me and some others how working with WineD3D may be the better of the two since dgVoodoo2 isn't open source. Because of that statement/suggestion I kind of ran with WineD3D from that point.

However, I'm happy to also try and test dgVoodoo2 myself in more detail in the future then and, if it gets your seal of approval Elisha, change the Installation Guide around accordingly. dgVoodoo2 wraps/converts the game to DX11, correct?

[elishacloud]

gVoodoo2 wraps/converts the game to DX11, correct?

Correct.

About a year back now another GitHub user mentioned to me and some others how working with WineD3D may be the better of the two since dgVoodoo2 isn't open source.

I don't think we gain anything by using WineD3D just because it is open source. WineD3D was really designed for Linux-based systems that don't have DirectX. That is why it converts DirectX to OpenGL. However OpenGL does not work as well on Windows as DirectX does.

Currently we use d3d8to9 + WineD3D. WineD3D requires three dll files. Using dgVoodoo will simplify this by requiring only one file. In fact I could even wrap the dgVoodoo dll inside the SH2 Enhancement project, if dgVoodoo works ok with Silent Hill 2.

[nipkownix]

Do me a favor and temporarily disable/remove from the directory the dgVoodoo2 files and start a new game. Go to the fenced off tunnel. It should be white for you here?

Ah, I see now. It's white, yeah. Using dgVoodoo, it's actually gray. And as far as I can tell, it's the only graphical bug that dgVoodoo doesn't fix. (well, kinda. its neither white nor black :p)

The fog seems to be here and I see no issues such as chunks of the wall disappearing. No "black outlines" on faces either.

Here are some pics:

The gray tunnel puzzles me tho. I played the entired game using dgVoodoo and I saw nothing like this anywhere else in the game. Of course I don't know the game as well as you do.. so you're gonna have to do some testing of your own :p

[mirh]

I don't think we gain anything by using WineD3D just because it is open source.

That's why we have dxwrapper /s

However OpenGL does not work as well on Windows as DirectX does.

That's only true for AMD (or slightly Intel). Nvidia has performance parity (if not even a tad more) with GL. Of course the "translator" shall be perfectly optimized in its turn to retain the exact performance then.

[elishacloud]

That's only true for AMD (or slightly Intel). Nvidia has performance parity (if not even a tad more) with GL.

There is definitely a performance issue with WineD3D. However I was thinking more of compatibility. I have had more compatibility issues with GL than with DirectX on Windows. If a game has both DirectX and GL options, then chances are that the DirectX options work better than the GL options on Windows.

Also keep in mind that things like SweetFX and injectSMAA work with DirectX 9 and newer. Which means these tools should work natively with dgVoodoo, since dgVoodoo converts the game to DirectX 11. Not all of these tools will work with WineD3D/GL.

[Polymega]

There is definitely a performance issue with WineD3D.

The game refuses to start for me on my Surface laptop with Intel integrated graphics using WineD3D. It'll launch the window and try but will crash 20-40 seconds later. Granted, WineD3D isn't needed for my laptop since it's not using an Nvidia card but still worth the note, I feel.

[Polymega]

Update on this glitch: It doesn't happen if the noise grain filter is already turned on. Because of how wildly specific/circumstantial this bug is I'm going to close the ticket unless others start noticing/reporting this same bug. https://youtu.be/3D5o7zB0cFo