X105 wrote on 2022-08-15, 19:18:

Game: (d3d8.dll, 32-bit) Ephinea Phantasy Star Online Blue Burst (largest PSOBB private server) https://ephinea.pioneer2.net - c […]
Show full quote

Game: (d3d8.dll, 32-bit) Ephinea Phantasy Star Online Blue Burst (largest PSOBB private server) https://ephinea.pioneer2.net - currently self-distributes 2.79.1

Conditions:
- dgVoodoo2 version: 2.75 or higher (any after 2.74.1) on DX11 mode
- Tested on AMD Graphics, Windows 10

Issue:
- All text in the game renders as solid white boxes [] (visible at title screen menu, very quick/easy to reproduce)

Workarounds:
- DX12 mode: Fixes the text, but with new side effects: The game's inbuilt screenshot function produces black screenshots, and the game ignores MSAA settings
- Revert to 2.74.1: All problems fixed.

Oh, and it looks like ALL versions of dgVoodoo break full motion video rendering as well on D3D12.

I think this is because D3D12 forces as flip style presentation model. Attempting to use "discard" or "seq" (not "flip_discard" or "flip_seq") causes PSO to crash on startup with D3D12.

If flip_discard or flip_seq is used with PSO, screenshots and FMV break regardless of if you're using D3D11 or D3D12. (Can test easily by going to the character creation process on Ephinea.)

I'll also note that all versions, using both D3D11 and D3D12, "Vertex Fog" in PSO doesn't work at all. Pixel Fog is fine, but probably less efficient than Vertex Fog.

If you go to Caves, for example, none of the fog is present with Vertex Fog.. (Can easily see by just looking into the next room in Cave 1 from the entrance.)

Where as using Pixel Fog or using playing without dgVoodoo has the nice pulsating fog in the Caves.

Sub desert is Episode IV also looks wrong with Vertex Fog on as well.

I'd bet the PSO fog bug is related to the FFXI fog bug reported here: Fog issue in FFXI

dgVoodoo seems to definitely have some fog bug in it's code.

I had to code a work around to disable fog on the title screen of PSO as well as during bursting when utilizing SMAA because dgVoodoo will render the entire screen white otherwise. (Works fine on D3D9 native or D3D9on12.)

dgVoodoo also sets the screen to black when performing Photon Blasts in PSO, which is again another fog issue I believe. Going to look into that this weekend to see if I can make a workaround for it.

sodaboy581 wrote on 2022-08-19, 20:40:

dgVoodoo seems to definitely have some fog bug in it's code.

I had to code a work around to disable fog on the title screen of PSO as well as during bursting when utilizing SMAA because dgVoodoo will render the entire screen white otherwise. (Works fine on D3D9 native or D3D9on12.)

dgVoodoo also sets the screen to black when performing Photon Blasts in PSO, which is again another fog issue I believe. Going to look into that this weekend to see if I can make a workaround for it.

OK, so, I've resolved this in the latest update for Ephinea. Just had to set FOGENABLE and LIGHTING to 0 before calling smaa->go. 😜

Still, though, dgVoodoo should have emulated native DX behavior. It is what it is, though, and we're all good now!!

I've just wanted to write that if you have a simple repro or maybe a simple repro app then I could have a look into it some of the next days.
But, I still don't understand:
1) Uhm... what is SMAA? I mean in terms of the D3D9 API
2) How setting FOGENABLE to 0 solves the wrong fogging?

Dege wrote on 2022-08-20, 07:33:

I've just wanted to write that if you have a simple repro or maybe a simple repro app then I could have a look into it some of t […]
Show full quote

I've just wanted to write that if you have a simple repro or maybe a simple repro app then I could have a look into it some of the next days.
But, I still don't understand:
1) Uhm... what is SMAA? I mean in terms of the D3D9 API
2) How setting FOGENABLE to 0 solves the wrong fogging?

SMAA is a post processing antialiasing solution.

You can download a version of it for DX9 or DX10 at https://github.com/iryoku/smaa

When using the DX9 version with dgVoodoo on PSOBB, if you log off after successfully getting to the ship select, the entire screen became white after calling SMAA:go.

The entire screen would also become black while using a Photon Blast if SMAA was enabled.

This doesn't happen if you use D3D9 via D3D8to9. It also doesn't happen using D3D9on12. (Since PSO does not have native D3D9 support.) It only happens when using dgVoodoo.

However, setting FOGENABLE to 0 before calling SMAA::go fixes both issues with dgVoodoo.

Probably not as important, as Pixel fog works, Vertex fog with dgVoodoo and PSOBB doesn't work at all.

If you want to reproduce it, you can do so fairly easily by selecting the "Direct3D 9" API on Ephinea PSOBB (which will utilize D3D8to9), enabling SMAA, and dropping dgVoodoo's d3d9.dll into the PSO folder, then running the game.

Connect to the game and reach the ship select, then press ALT+Backspace to log off.

When you return to the title screen, the screen will be covered in solid white.

Delete D3D9.dll and do the same... and it's fine.

It's not a big deal since there is a fix, but just noting a behavior where dgVoodoo does not act like native DX9.

Why the use of the d3d9.dll when dgVoodoo 2 can step in at Direct3d 8? I'm assuming d3d8to9 is integrated into ephinea.dll, so I can't imaging stacking a wrapper (dgVoodoo) on top of another wrapper (d3d8to9) will have everything working as expected. I think the only real issue is vertex fog doesn't work on PSOBB, and maybe other games, with dgVoodoo.

Truth Unknown wrote on 2022-08-20, 21:05:

Why the use of the d3d9.dll when dgVoodoo 2 can step in at Direct3d 8? I'm assuming d3d8to9 is integrated into ephinea.dll, so I can't imaging stacking a wrapper (dgVoodoo) on top of another wrapper (d3d8to9) will have everything working as expected. I think the only real issue is vertex fog doesn't work on PSOBB, and maybe other games, with dgVoodoo.

That is not the problem, d3d8to9 barely does anything, to be honest. And it works fine when using d3d9on12, which also goes through 8to9.

But, anyhow, the reason is D3D8 is trash and I need to use some D3D9 calls to implement things like SMAA anyway. You can't do SMAA on D3D8.

Also, dgVoodoo has opted not to expose the real device it creates. I did some testing of hijacking it's D3DCreate11Device to get the true device, but if you start playing with the device and device context outside of dgVoodoo, you get weird stuff that happens since dgVoodoo was not designed to be used that way.

Thus, the best method of being able to do things like SSAA, SMAA, HSAA, and so on internally is to just use d3d8to9 and, if you provide 11/12 API support, dgVoodoo on top of it while still using the d3d9 device I've stolen from d3d8to9.

Like I said, the main problem was just having fog enabled before calling smaa::go, which has now been fixed. I have yet to see any other issues with dgVoodoo and was only pointing out something dgVoodoo does that native DX does not do.

To also be fair, the bbmodplugin also has the same exact issue which I have submitted to Ender/Soly to fix.

If you log onto PSOBB with addons loaded, get to ship select or further, and then ALT+Backspace or quit to the title screen, the addon window will become white underneath. This problem is resolved by setting FOGENABLE to 0 in the bbmod source code before it does it's full screen quad.

They'll be submitting a fix for it soon.

Ok, I'll look into the issue. This fog thing is getting very confusing because (according to my tests) there is a difference between D3D8 and 9 vertex fog pipeline. So, if the pipeline part in question is utilized in D3D8 then D3D8to9 shouldn't work correctly. At least with an old driver, because I guess that MS D3D8 is internally mapped to the D3D9 DDI these days.

As for the fix: it should be fixed in dgVoodoo instead. It indeed should work exactly the same way as the native one because it's a state machine.

sodaboy581 wrote on 2022-08-21, 08:39:

Also, dgVoodoo has opted not to expose the real device it creates. I did some testing of hijacking it's D3DCreate11Device to get the true device, but if you start playing with the device and device context outside of dgVoodoo, you get weird stuff that happens since dgVoodoo was not designed to be used that way.

Hmm, it could do that via an addon interface. Something that'd require some more coding on my part but lack of time (and general lack of community interest) does not drive me to work on that.

Dege wrote on 2022-08-21, 09:06:

sodaboy581 wrote on 2022-08-21, 08:39:

Also, dgVoodoo has opted not to expose the real device it creates. I did some testing of hijacking it's D3DCreate11Device to get the true device, but if you start playing with the device and device context outside of dgVoodoo, you get weird stuff that happens since dgVoodoo was not designed to be used that way.

Hmm, it could do that via an addon interface. Something that'd require some more coding on my part but lack of time (and general lack of community interest) does not drive me to work on that.

I understand!

That'd be pretty elite if you did do that, though.

My workaround to get it looked like this, having PSO call dgVoodooCreate8 instead of the normal Direct3DCreate8: https://pastebin.com/qQjuZNC6

But yeah, I imagine you could just have a function in your DLL that you could export... The function could simply modify two pointers passed to it which would be where they want to store the pointers to the D3D11Device and D3D11DeviceContent.

A developer could then just GetProcAddress for your new function and, voila, they've got the real Device and DeviceContext after calling it.

In the mean time, I guess someone could just do what I did up there and redirect dgVoodoo's GetProcAddress procedure to one of their own.

It'd be more complicated, it's not about hooking. dgVoodoo could ignite your dll as an addon which has (or can have) various callback points like global init/exit, object (like device, texture, whatever) creation/destroy or image presentation, etc. Since dgVoodoo can handle multiple adapters, there are more than one D3D11 device contexts existing and you could acquire the used one at device creation and release it on device destroy, use it for your own rendering code when handling a presentation callback, etc. At least, that was my original idea.

Btw, I've just tried to repro the issue. I copied dgv D3D9.dll (2.79.2) to the game folder, selected Direct3D9 and SMAA (medium) in the options and ran the client. I got to the ship selection menu, SMAA was active because my rotating character was nicely antialiased. Then Alt-Backspace to the main menu but it worked fine.
Since I had to update my PSOBB client to the latest version, do I have the workaround fix (with fogenable and lighting disabled) you mentioned and that's why I don't have the issue?
The client version is Ephinea v1431 if that helps.

X105 wrote on 2022-08-15, 19:18:

As of yesterday, Ephinea has updated itself to use 2.79.2 and I find no issues, though the black screenshot issues on DX12 remain (the Ephinea staff are attempting workarounds).

Btw, how to activate the screenshot function?
If it tries to BitBlt from the game rendering window then it won't work with D3D12 because windows backed by flip_ * type swapchain (which is mandatory for D3D12) are not GDI compatible.
If it reads back screen data through D3D8/9 then it should work and if not then it's a bug I could look into.

Dege wrote on 2022-08-21, 14:42:

Btw, I've just tried to repro the issue. I copied dgv D3D9.dll (2.79.2) to the game folder, selected Direct3D9 and SMAA (medium) in the options and ran the client. I got to the ship selection menu, SMAA was active because my rotating character was nicely antialiased. Then Alt-Backspace to the main menu but it worked fine.
Since I had to update my PSOBB client to the latest version, do I have the workaround fix (with fogenable and lighting disabled) you mentioned and that's why I don't have the issue?
The client version is Ephinea v1431 if that helps.

Oh, I patched it in the DLL for everyone. Damn.

Let me prepare an unpatched DLL for you... I'll post it here in a few minutes.

Right now, I just do this for everyone, dgVoodoo or not

t_d3d9->GetRenderState(D3DRS_LIGHTING, &lv); t_d3d9->GetRenderState(D3DRS_FOGENABLE, &fv); t_d3d9->SetRenderState(D3DRS_LIGH […]
Show full quote

t_d3d9->GetRenderState(D3DRS_LIGHTING, &lv);
t_d3d9->GetRenderState(D3DRS_FOGENABLE, &fv);
t_d3d9->SetRenderState(D3DRS_LIGHTING, 0);
t_d3d9->SetRenderState(D3DRS_FOGENABLE, 0);
smaa->go(render_combo_texture9, render_combo_texture9, real_backbuffer_surface9, SMAA_input);
t_d3d9->SetRenderState(D3DRS_FOGENABLE, fv);
t_d3d9->SetRenderState(D3DRS_LIGHTING, lv);

BUT! I'll post one with that disabled, so you can see! I need like 10 minutes and I'll make another post OR just edit this one.

Also, just gunna answer your 2nd post. Yeah, we captured with GDI previously to capture peoples' addons and such in the photo. Now, when people are utilizing dgVoodoo, I just save from the backbuffer. It works, but they can no longer capture their addons.

OK, here is a specially prepared DLL for you https://files.pioneer2.net/ephinea_smaa_dgvfogissue.zip

It's the same as 1431, except I've commented out the get/set renderstates before and after smaa->go.

You'll see the white screen issue if you reach ship select and then return to the title screen with ALT+Backspace.

You'll need to launch PSOBB.exe directly instead of online.exe in order to utilize this DLL after unzipping it to your Ephinea folder, otherwise the launcher will overwrite it.

Thanks! I tried it but it still worked fine... both with D3D11/12.
Could you plz check it out with the MS WARP software renderer, just to make sure?

Yes, it still happens with WARP when the workaround is disabled.

Here's a video I took of the phenomenon. https://youtu.be/0-OwkbERQo8

The video starts off showing my configuration settings through registry and my dgVoodoo.conf file.

It shows the issue happening with 11.0 FL 11.0 and 12.0 FL 11.0

Then I edit the registry and use d3d8to9 instead.

Then I show the issue NOT happening.

Then I go back to dgVoodoo and use the WARP renderer.

The issue happens again.

Then I go back to d3d8to9 and show the issue not happening again.

I'm shocked at how you're not able to reproduce it since it's so incredibly easy to reproduce. (At least when you don't use my workaround with the official DLL.)

I'd love to know what kind of GPU you're using.

So far, I know it happens to NVIDIA cards because I don't know anyone personally who has an AMD GPU, but the people I know who had the issue ran dgVoodoo and NVIDIA cards with SMAA at Ultra. (I don't think the SMAA level matters, but I'm also running ultra in this video as you can see by the registry settings.)

Ok, I succeeded to reproduce it. When

• HKEY_CURRENT_USER\SOFTWARE\SonicTeam\PSOBB\Ephinea\USE_D3D9 is set to 1 (which was my default)
  
  Then the game loads d3d9.dll. So, when I simply copied dgv D3D9.DLL to the game folder, it worked as the native D3D9.
  FOGENABLED and LIGHTING renderstates indeed enabled when SMAA is called but they have no effect because SMAA uses a vertex shader and pixel fog is disabled (FOGTABLEMODE set to 0 previously).
  
  <
• HKEY_CURRENT_USER\SOFTWARE\SonicTeam\PSOBB\Ephinea\USE_D3D9 is set to 2
  
  Then the game loads dgVoodoo_d3d9.dll and the white screen issue comes.
  The cause is that pixel fog is enabled (FOGTABLEMODE set to 3 previously) when calling into SMAA, so the pixel pipeline does some fogging calculated from the position z or w coordinate.

The game seems to apply different configs depending on what d3d9.dll is in usage.

AH YES! I forgot about that part! I mentioned it in a news post yesterday. Haha. https://www.pioneer2.net/community/index.php?posts/188299

We cannot use Vertex shading with dgVoodoo because Vertex shading doesn't work with dgVoodoo AT ALL. (Mentioned earlier in this thread.)

So now, as of the latest DLL, I force Pixel Fog on all users who are using dgVoodoo that was loaded by Ephinea.

You can also confirm this by using your regular d3d9.dll and using Vertex fog, then quickly going to Cave 1 in PSO.

The rooms have no fog at all, but only when using Vertex fog with dgVoodoo. (Use your own d3d9.dll)

However, if you use Pixel Fog, there is fog now... so... I've forced pixel fog for all users because it's not just the caves that experience this.

And how can I get into Cave 1? Do I have to create a party or sg like that? (I'm dumb to this game...)