I have a new WIP:

• Thanks to Firtasik, we were able to localize the code in the D3D11 backend that broke the texture upload on AMD. Unfortunately I found no other solution for this than blacklisting AMD Vega architectures (device ID's: 0x15DD and 0x15D8) and add a code path that are similar to the one in 2.54, less optimal than the current, but at least does not consume as many resources as 2.54.
  If other architectures turn out to be affected then plz report it and I'll add them into the blacklist. I added an option to suppress it to see if a new driver release fixed the issue (I wish....)
• I improved the existing rendering quality (DX default rendering format). Through a new option, various SDR/HDR color spaces can be selected for the image (swapchain) output. It's experimental because 'WCG SDR' and 'HDR' needs a display device with the proper capabilities so I couldn't really test it all. I don't know how it works on such devices and I also don't know if the OS Advanced Color mode itself applies the tone mapping to the output or not, and if it's completely unusable in the current state.
  The internal DX rendering precision (or quality) is adjusted to the selected color space by default. For ARGB2101010 color spaces 16 bit precision is used by default so the lowered alpha bits should not be a problem. And anyway, you can override the internal quality through option DirectXExt\Default3DRenderFormat. Though it may only be useful if you specify a high internal quality for a low quality color space to shift the precision loss to the image presentation phase.
  Color spaces:
  • ARGB:8888: legacy 32 bit output
  • ARGB:2101010: 32 bit output with extended precision
  • ARGB:2101010 WCG: The same as the previous but according to MS it's targeted for "specially provisioned SDR displays" and the OS Advanced Color mode handles it (Win11)
  • ARGB:16161616: true HDR output with float16 precision per component. I guess it's not handled by the OS auto HDR because on the one hand it's supported by Win10 and on the other hand Win11 auto HDR is for upscaling SDR outputs.
    So it may require a tone mapping from dgVoodoo side
  Anyway, any feedback is welcome.

=========================
WIP92:
=========================

• The root of the AMD D3D11 solid color texture issue is found, workarounding it by
  blacklisting Vega architecture (with ID 0x15DD and 0x15D8) and running on a less
  optimal but working code path
  Thanks Firtasik for the help!
• A new option DirectExt\SuppressAMDBlacklist to suppress it to see if a new driver
  release is solved it
• Optimalization and bugfixes in the 2D shader code generator
• Adding support for SDR/HDR colorspaces (experimental)
  • Option GeneralExt\ColorSpace to choose between SDR/HDR outputs
    (Precision of the internal DX rendering is adjusted to the colorspace by default)
  • Option DirectXExt\Default3DRenderFormat is modified to only control the internal
    rendering quality - you can override the default associated with the current colorspace
• Implementing a flip-chain incompatibility with MS DDraw (Seven Kingdoms II HD)
• A lot of internal changes

http://dege.fw.hu/temp/dgVoodooWIP92.zip
http://dege.fw.hu/temp/dgVoodooWIP92_dbg.zip

Update:

=========================
WIP92.1:
=========================

- Fixing a bug that breaks D3D8/9 rendering with certain pixel formats

http://dege.fw.hu/temp/dgVoodooWIP92_1.zip
http://dege.fw.hu/temp/dgVoodooWIP92_1_dbg.zip

Dege wrote on 2023-07-03, 19:31:

I have a new WIP: […]
Show full quote

I have a new WIP:

• Thanks to Firtasik, we were able to localize the code in the D3D11 backend that broke the texture upload on AMD. Unfortunately I found no other solution for this than blacklisting AMD Vega architectures (device ID's: 0x15DD and 0x15D8) and add a code path that are similar to the one in 2.54, less optimal than the current, but at least does not consume as many resources as 2.54.
  If other architectures turn out to be affected then plz report it and I'll add them into the blacklist. I added an option to suppress it to see if a new driver release fixed the issue (I wish....)
• I improved the existing rendering quality (DX default rendering format). Through a new option, various SDR/HDR color spaces can be selected for the image (swapchain) output. It's experimental because 'WCG SDR' and 'HDR' needs a display device with the proper capabilities so I couldn't really test it all. I don't know how it works on such devices and I also don't know if the OS Advanced Color mode itself applies the tone mapping to the output or not, and if it's completely unusable in the current state.
  The internal DX rendering precision (or quality) is adjusted to the selected color space by default. For ARGB2101010 color spaces 16 bit precision is used by default so the lowered alpha bits should not be a problem. And anyway, you can override the internal quality through option DirectXExt\Default3DRenderFormat. Though it may only be useful if you specify a high internal quality for a low quality color space to shift the precision loss to the image presentation phase.
  Color spaces:
  • ARGB:8888: legacy 32 bit output
  • ARGB:2101010: 32 bit output with extended precision
  • ARGB:2101010 WCG: The same as the previous but according to MS it's targeted for "specially provisioned SDR displays" and the OS Advanced Color mode handles it (Win11)
  • ARGB:16161616: true HDR output with float16 precision per component. I guess it's not handled by the OS auto HDR because on the one hand it's supported by Win10 and on the other hand Win11 auto HDR is for upscaling SDR outputs.
    So it may require a tone mapping from dgVoodoo side
  Anyway, any feedback is welcome.

=========================
WIP92:
=========================

• The root of the AMD D3D11 solid color texture issue is found, workarounding it by
  blacklisting Vega architecture (with ID 0x15DD and 0x15D8) and running on a less
  optimal but working code path
  Thanks Firtasik for the help!
• A new option DirectExt\SuppressAMDBlacklist to suppress it to see if a new driver
  release is solved it
• Optimalization and bugfixes in the 2D shader code generator
• Adding support for SDR/HDR colorspaces (experimental)
  • Option GeneralExt\ColorSpace to choose between SDR/HDR outputs
    (Precision of the internal DX rendering is adjusted to the colorspace by default)
  • Option DirectXExt\Default3DRenderFormat is modified to only control the internal
    rendering quality - you can override the default associated with the current colorspace
• Implementing a flip-chain incompatibility with MS DDraw (Seven Kingdoms II HD)
• A lot of internal changes

http://dege.fw.hu/temp/dgVoodooWIP92.zip
http://dege.fw.hu/temp/dgVoodooWIP92_dbg.zip

IIRC, one of my friend has a mobile RX560X and Interstate 76 rendered in white in his card. I no longer have access to his device, to test again correctly.

BEEN_Nath_58 wrote on 2023-07-04, 07:25:

Dege wrote on 2023-07-03, 19:31:

I have a new WIP: […]
Show full quote

I have a new WIP:

• Thanks to Firtasik, we were able to localize the code in the D3D11 backend that broke the texture upload on AMD. Unfortunately I found no other solution for this than blacklisting AMD Vega architectures (device ID's: 0x15DD and 0x15D8) and add a code path that are similar to the one in 2.54, less optimal than the current, but at least does not consume as many resources as 2.54.
  If other architectures turn out to be affected then plz report it and I'll add them into the blacklist. I added an option to suppress it to see if a new driver release fixed the issue (I wish....)
• I improved the existing rendering quality (DX default rendering format). Through a new option, various SDR/HDR color spaces can be selected for the image (swapchain) output. It's experimental because 'WCG SDR' and 'HDR' needs a display device with the proper capabilities so I couldn't really test it all. I don't know how it works on such devices and I also don't know if the OS Advanced Color mode itself applies the tone mapping to the output or not, and if it's completely unusable in the current state.
  The internal DX rendering precision (or quality) is adjusted to the selected color space by default. For ARGB2101010 color spaces 16 bit precision is used by default so the lowered alpha bits should not be a problem. And anyway, you can override the internal quality through option DirectXExt\Default3DRenderFormat. Though it may only be useful if you specify a high internal quality for a low quality color space to shift the precision loss to the image presentation phase.
  Color spaces:
  • ARGB:8888: legacy 32 bit output
  • ARGB:2101010: 32 bit output with extended precision
  • ARGB:2101010 WCG: The same as the previous but according to MS it's targeted for "specially provisioned SDR displays" and the OS Advanced Color mode handles it (Win11)
  • ARGB:16161616: true HDR output with float16 precision per component. I guess it's not handled by the OS auto HDR because on the one hand it's supported by Win10 and on the other hand Win11 auto HDR is for upscaling SDR outputs.
    So it may require a tone mapping from dgVoodoo side
  Anyway, any feedback is welcome.

=========================
WIP92:
=========================

• The root of the AMD D3D11 solid color texture issue is found, workarounding it by
  blacklisting Vega architecture (with ID 0x15DD and 0x15D8) and running on a less
  optimal but working code path
  Thanks Firtasik for the help!
• A new option DirectExt\SuppressAMDBlacklist to suppress it to see if a new driver
  release is solved it
• Optimalization and bugfixes in the 2D shader code generator
• Adding support for SDR/HDR colorspaces (experimental)
  • Option GeneralExt\ColorSpace to choose between SDR/HDR outputs
    (Precision of the internal DX rendering is adjusted to the colorspace by default)
  • Option DirectXExt\Default3DRenderFormat is modified to only control the internal
    rendering quality - you can override the default associated with the current colorspace
• Implementing a flip-chain incompatibility with MS DDraw (Seven Kingdoms II HD)
• A lot of internal changes

http://dege.fw.hu/temp/dgVoodooWIP92.zip
http://dege.fw.hu/temp/dgVoodooWIP92_dbg.zip

IIRC, one of my friend has a mobile RX560X and Interstate 76 rendered in white in his card. I no longer have access to his device, to test again correctly.

Ok, thanks! I'll add new architectures to the list if someone reports it first hand and tell me the device ID of the GPU (any feedback is welcome).

Btw, I added a little update to the latest WIP because I found a bug that breaks D3D8/9 rendering with certain pixel formats:
Re: dgVodooo 2.7.x and related WIP versions (2)

I'm going to switch to bugfixing and checking out reported problems.

I've been testing and fixing bugs, I have some fixed, so a little update:

=========================
WIP92.2:
=========================

• Fixing some D3D12 leaks + some internal D3D12 changes
• Fixing palette update on integrated GPU's in the D3D12 backend (CMRally)
• Generating more optimal vs/ps shaders for D3D9 along with some performance improvement, in certain cases
• Fixing broken clipping planes with D3D11 FL11.0 output (Tomb Raider Underworld)
• Fixes in the new 2D blitter shader code generator/code environment (intro Soldier of Fortune, Wizards and Warriors)
• DDraw fixes for forced resolution (Seven Kingdoms 2)

http://dege.fw.hu/temp/dgVoodooWIP92_2.zip
http://dege.fw.hu/temp/dgVoodooWIP92_2_dbg.zip

Yesterday I released dgVoodoo 2.81:

http://dege.fw.hu/dgVoodoo2/bin/dgVoodoo2_81.zip
http://dege.fw.hu/dgVoodoo2/bin/dgVoodoo2_81_dbg.zip

For the full change log, see:

http://dege.fw.hu/dgVoodoo2/ReadmeGeneral/#changelog

Thanks Dege, as always!

dgVoodoo2 is just impressive nowdays, here's Timeshift (2007 - Dx9) with forced MSAA 4x @2560x1440 on a RTX 3060.

Thank you Dege.
Your continued work on this project is very much appreciated.

Thank you all!

I split the 2.7.x topic and created a new one (this topic) for 2.8.x series and related WIP's. Plz let's continue here, I'm going to close the 2.7.x topic.

Btw, I found a regression bug in 2.81, and since it affects multiple modules and since there have been many downloads already, I did not want to re-release it with the update, but instead released a patch version:

• Fixing a regression bug that can break DirectShow movie playback
• Fixing another regression bug causing crash

http://dege.fw.hu/dgVoodoo2/bin/dgVoodoo2_81_1.zip
http://dege.fw.hu/dgVoodoo2/bin/dgVoodoo2_81_1_dbg.zip

Why did the version go from 2.8 to 2.81 to 2.82 back to 2.81(newer than first 2.81 and 2.82)?

WIP92 is not "82"

ELK wrote on 2023-07-28, 09:41:

Why did the version go from 2.8 to 2.81 to 2.82 back to 2.81(newer than first 2.81 and 2.82)?

2.8.2 is actually 2.80.2 but I keep my bad versioning scheme. So, a dgVoodoo version 2.x.y.z has the following meaning:

2: it's constant like, say, π
x: main version
y: subversion
z: patch version

But I write it as: 2.xy.z. Also, If "y" or "z" is "0" then I omit it from the string. 🙄

There's some problems with DDraw and starting videos.....Blood 2 (GOG) opening cinematics force the game window to their resolution and to switch back to the selected gaming one it's necessary to ALT+TAB

lowenz wrote on 2023-07-28, 13:25:

There's some problems with DDraw and starting videos.....Blood 2 (GOG) opening cinematics force the game window to their resolution and to switch back to the selected gaming one it's necessary to ALT+TAB

Sometimes happens for me, I don't know why. It's like something steals the window focus and the game window remains windowed.

Some minor fixes I wanted to share:

• Fixing a D3D12 cache bug (banded shadows in some games)
• Some D3D12 bugfixes (in both Glide and DX)
• Adding new AMD GPU architectures to the D3D11 blacklist (Renoir/RX4xx/RX5xx series)
• Fixing a deadlock when QuickTime player is active (regressive bug) (Septerra Core)
• Modifying some code handling vertex data to get better performance on new CPU architectures (Sacrifice stress test)
• Fixing a minor bug in the CPU code generator

http://dege.fw.hu/dgVoodoo2/bin/dgVoodoo2_81_2.zip
http://dege.fw.hu/dgVoodoo2/bin/dgVoodoo2_81_2_dbg.zip

Hello, Mr. dege.
I am Korean, and I am not good at English, so I leave a message through machine translation.

I want to contact you personally, but I couldn't find it, so I came to visit this place.
I was able to run some of the very old Korean games through dgVodoo released by dege.
However, I couldn't find out if the released data was freeware or not, so I thought about it.

I've been crafting old game mods with beginner skills for a while.
I'm preparing to distribute the game mode publicly.
I want to include some files from dgVodoo in this game.
Of course, I'm also releasing the data for free.

If this doesn't matter, would you allow it?

If there is no answer, I have no choice but to introduce dgVodoo as a separate program.
Then, game users have to go through the installation process.

Please allow us to tolerate the above content.
Thank you. 😀

N O V A TV wrote on 2023-08-23, 06:04:

Hello, Mr. dege. I am Korean, and I am not good at English, so I leave a message through machine translation. […]
Show full quote

Hello, Mr. dege.
I am Korean, and I am not good at English, so I leave a message through machine translation.

I want to contact you personally, but I couldn't find it, so I came to visit this place.
I was able to run some of the very old Korean games through dgVodoo released by dege.
However, I couldn't find out if the released data was freeware or not, so I thought about it.

I've been crafting old game mods with beginner skills for a while.
I'm preparing to distribute the game mode publicly.
I want to include some files from dgVodoo in this game.
Of course, I'm also releasing the data for free.

If this doesn't matter, would you allow it?

If there is no answer, I have no choice but to introduce dgVodoo as a separate program.
Then, game users have to go through the installation process.

Please allow us to tolerate the above content.
Thank you. 😀

Hi! No problem, you can include the dgVoodoo files into your games, I just like to know about it that's why I mention "asking permission" in the readme.
What games are those, btw? I'm just curious.

Thank you for your quick response.

The game name is 'Arcturus' RPG game. It was made in Korea about 23 years ago. It is a game known only in Korea and Japan.
It was a popular game, but it's been too long,In the current PC environment, it was difficult to run the game.

Then, I will make good use of your program.
Have a nice day. 😀

On the subject of Arcturus; you haven't reconsidering adding any hacks to make resolution forcing work better for some games, Dege?

DDrawCompat has some tweak-able hacks that allows for fixing some games that have issues in dgVoodoo with resolution forcing, for example the lines because of tiling issues in Arcturus's text boxes (though Arcturus looks sort of bad at times with DDrawCompat because of no way to force 24-bit zbuffer).

There's a sprite detection setting that can set separate clamping and filtering options based on Z coordinates.