Try using the D3D12 renderer

Thanks, apologies I missed this from the ReadMe documentation. I can see it's in there now. I wasn't experiencing this issue myself, just trying to help some others who have newer AMD cards and asking on their behalf.

What is the best way to change to D3D12 render
When I launch dgVoodoo control panel, the Output API doesn't let me select Direct3d 12

Do I need to manually edit the dgVoodoo.conf file and change this line?

OutputAPI = d3d12_fl11_0

is that the correct method? is FL11 or FL12 recommended in this case? ("d3d12_fl11_0", "d3d12_fl12_0")

I can see this from the "About" page

Hardware rendering at GPU feature level 12.0 (recommended but currently has some issues)
Hardware rendering at GPU feature level 11.0 (recommended)

Thanks again

Yes,

OutputAPI = d3d12_fl11_0

is what is needed, but if your GPU supports D3D12 FL11.0 then it should appear in the dropdown list in the CPL (Win10+).

Thank you. It seems this isn't working for some people. Would you have any ideas what else to try?

Here's information from someone that tried it out:

Settings: OutputAPI = d3d12_fl11_0
(refer to attached dgVoodoo.conf file used)

D3D8.dll file used was version 2.7.8.2

Newer versions had various issues (such as no 3d devices found, or black screens in various menus)

With the above configuration, they reported same blocks covering text menus in the game, and provided a pic of the issue

I asked them to run DXDiag tool and they did, here is a pic from the Display tab. They got an AMD Radeon RX 480 card

I don't have an AMD Radeon card myself, so my troubleshooting abilities are limited.

The game client that is being used is packaged up here: https://wiki.takp.info/index.php/Getting_Started_on_Windows

Refer to the TAKP Client v2.2 zip file. There is no game install, just unzip and run EQGame.exe
(you need to create a forum + game account before you can log in to fully launch the game client to the "character select screen" where the 3d graphics load)

In this package, we are trying to include dgVoodoo2 .dll and .conf that works for everyone, but it's proving a challenge. AMD Radeon card people keep having issues, and the "fix" is to delete d3d8.dll file which removes dgVoodoo2 completely, which isn't ideal.

Thank you for any suggestions or help you're able to offer.

As for the D3D11 buggy solid textures, nothing can be done for it. It's an AMD D3D11 driver bug. As far as I know the new drivers eliminates this bug (I got reports about that) but I don't know what AMD gpu architectures are affected.
I have an old R7 360, a pre-GCN3 gpu and D3D11 works properly (so, old architectures were ok).

What is more interesting is why D3D12 is not appearing in the dropdown list in the CPL. I've done a quick test with my AMD and it worked (Win10) as expected. Not with this game though, I cannot create an account to test it.

Btw, why deferred screenmode switch is required in the config?

Thanks for looking into it. I think older dgVoodoo2 used to work OK for Nvidia and Radeon cards, like version 2.54, but I'm trying to see if we can get a newer version working.

Deferred Screenmode was just an attempt at fixing a display crashing bug, but I don't think it's helping. It is not required.

The game switches resolutions when you go from in-game 3d mode (character select screen -> enter game world), back to the "server select screen" if you wanted to log in to another account.
It switches from proper 3d rendering mode back into basic 2d 640*480 mode, and DirectX crashes randomly around 10% of the time. You have to re-launch the game client every time. Just tried changing some settings to see if it would help (it doesn't seem to be).

Event Log error is logged when this happens.

1Application popup: Client1: Windows - Application Error : The instruction at 0x00000000770AF643 referenced memory at 0x0000000000000014. The memory could not be written.
2
3Click on OK to terminate the program

I don't think this is a dgVoodoo2 error, it just happens due to old game client, but I just tried playing with settings to see if it may help.

What is interesting is that newest versions of dgVoodoo2, version 2.8 onwards, seem to result in a "black screen" when this 3d -> 2d transition switch happens now.
Going from in-game 3d mode back to the 2d 640*480 "server select / login screen" results in just a black screen with the latest dgVoodoo2 d3d8.dll.
Slightly older versions, like version 2.7.93 , don't have this issue.

If you had time to try and investigate and help out, in order to be able to log in and create an in-game account to log in, you could check this Wiki entry:
https://wiki.takp.info/index.php?title=Getting_Started
Basically you have to first register on the TAKP forums by creating a forum account. Then after that you can create in-game login accounts.
This lets you log in and create a character to enter the world to render the game in 3d mode.

Ok, I managed to create an account and login into the character selection screen. I have some observation with this game:

• I don't know but the game itself seems to come out of the box with a dgVoodoo.conf and a Cpl app in its folder, but the config file version is 2.8 and the Cpl is 2.78.2. The problem with it is that config v2.8 can only be read by any dgVoodoo component (the dll's, Cpl) with version 2.8 or above. So, neither the included Cpl nor D3D8.dll's older than 2.8 can read the config file so the game probably runs with the default config and the Cpl 2.78.2 reads/writes config files in the default location, not the one in the game folder.

• The main menu is not rendered through DX. This is problem for D3D12 because once a window is rendered by D3D12 then it cannot transition back into its old (GDI compatible) state anymore, that's why it gets black. This is by design by MS. It's very unfortunate because this game is incompatible with dgVoodoo D3D12 in this form. I don't know if the game code could be modified but a solution for this would be releasing the window (HWND) and creating a new one when returning back to the main menu. So, whether it gets black or not, depends on running on D3D11 or 12 (see the config version problem).

• If I use a d3d8.dll that's emitted directly by the compiler then I can't even log in into the character selection screen because it crashes right after switching into d3d8 mode. This is because the game seems to hook D3D8 and does this by overwriting the virtual function table of the D3D8 COM object(s). TBH it's a very bad practice because the compiler puts vft's into a read-only memory section (that's why it crashes) and it's only by chance that it works with dgVoodoo releases (the executable packer makes those pages writable). Native D3D8 puts the vft into a dynamically allocated (writable) area that's why this hook method works with it.

Thank you for taking the time and all your investigations, that's good information!

There have been several attempts at packaging up a compatible client for people. It's an old emulated server using an in-era appropriate client from year 2002 for most parts, which has issues with modern computers and graphics cards (specificially with hybrid graphics support), hence why attempts at including dgVoodoo2 .dll files natively to fix things for people.
The mistake in dgVoodoo.conf version is my mistake, I didn't realise version mattered, and this would explain why the d3d12 settings may not be taking effect.

Would you recommend packging it up with an older version of dgVoodoo2 v2.54 which uses D3D11 renderer?

Edit: OK, tested some versions with a Radeon card with a wiling participant.

Version 2.54 works with Radeon, no bars covering text
However, the game just exits to desktop if you try to transition back from world / character select screen back to the server select screen.

Version 2.55 onwards has bars covering text
But it does not exit to desktop when you transition back from the game to server select screen

any newer version, like 2.7 onwards, has bars covering text unless you force D3D12 renderer mode
but it has a black screen when you transition from game back to the server/login screen

Doesn't look like there's a version that works with with Nvidia and Radeon cards without some issues 🙁

Unfortunately v2.54 was the last version that worked properly with those AMD drivers. 😐
The best would be to fix that bloody issue rather than struggling with old dgVoodoo versions. I already bought 2 old AMD cards just to reproduce and debug this problem, but I was unlucky because everything worked OK for me. 😀

Perhaps somebody in the community who could take D3D11 frame captures with Visual Studio with both the newest dgVoodoo version and 2.54?
(RenderDoc is not compatible with compressed dll's and the game crashes with uncompressed dll's...

I could compare the two and maybe figure out what the driver doesn't like. (It's not 100% at all if the root of the problem is not in the captured frame).

Dege wrote on 2023-05-22, 19:24:

Perhaps somebody in the community who could take D3D11 frame captures with Visual Studio with both the newest dgVoodoo version and 2.54?

Would you have some instructions how this can be done? If you have a reference article from the web somewhere, I could pass it on and see who could help collect this data for you.

Maybe it's a bit complicated after all... And I don't know if VS Community Edition has the graphics debugger. I'll check it out if it works at all.

Btw, another (much simpler) solution could be to capture a frame from another game that also has the texture problem.

The VS graphical debugger does not seem to work with this game either... 😐
So, let's drop this option.
Anyway, I'm almost sure that solid color textures in the 3D rendering comes from the fact that the textures themselves are white, containing 1.0 in all of the components.
Meanwhile it came to my mind that years ago I got a capture from another game with the same problem and that was what I saw in that capture.
White textures can only be produced by the 2D shaders, some of them must be interpreted incorrectly by the driver (who knows why) and values saturated to 1.0 must be written to the target texture.

I want to improve the 2D architecture with specialized shaders in the next version anyway, so I hope that'll fix this long-standing problem too.

awesome that's great, thank you for looking into it

looking forward to trying the new version when it's ready
great work as always

RimidalTAKP wrote on 2023-05-28, 05:33:

awesome that's great, thank you for looking into it

looking forward to trying the new version when it's ready
great work as always

Could you plz test the latest WIP with AMD cards?
Re: dgVodooo 2.7.x and related WIP versions (2)

It contains the fix for Vega GPU's, but I'm not sure if that's enough, so I might have to add other GPU architectures as well.

awesome thank you, I'll pass it on to some friends that use AMD cards to give it a try!

Hi there

Had a friend try it out, but unfortunately issue wasn't resolved. I'm guessing it's because the fix is only for Vega cards, and I think he has another chipset.
Looks like he has AMD processor on his laptop chipset 0x1636

Here is the DxDiag of his card:

Thanks!

I still had the old experimental version that always runs on the "fixed" path. It could be checked out to see if it indeed works:

http://dege.fw.hu/temp/dgVoodoo2_81_exp4.zip

I just got a report that the experimental DLL linked above works on the AMD card!

update: second confirmation this dll works from another AMD card person

Thanks! Then I'll include 0x1636 Renoir in the blacklist in the next version. Renoir seems to be the gpu architecture based on Vega in APU's.
If you know of any other device ID's that's not working with the latest version, plz share it and I'll include them too.