VOGONS


dgVoodoo 2 for DirectX 11

Topic actions

  • This topic is locked. You cannot reply or edit posts.

Reply 2861 of 3949, by lowenz

User metadata
Rank Oldbie
Rank
Oldbie

About the state of pixel shaders 1.x in a D3D9 (not D3D8!) implementation on modern hardware/software (OS+D3D runtime+drivers), here's a good catch in SC(3): Chaos Theory

With PS 1.x:
splintercell3_2017_01_04_15_42_58_620.png

With PS 3.0 (but no HDR/Tone Mapping, no Parallax Mapping and no Soft Shadows - to avoid intended differences):
splintercell3_2017_01_04_15_44_37_405.png

So, as dege says, there's already some problems :p

Reply 2863 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t

UCyborg, thanks for your efforts!!

Now I can run 3DMark 2001 through dgVoodoo. 😎
I couldn't stand not to avoid rendering it in C64-style:
https://www.youtube.com/watch?v=d-Is0UKAJ4M&feature=youtu.be 😁 😁 😁

It also turned out that 'Nature' and 'Pixel shader' benchmark tests need Q8W8V8U8 texture format, I'll add support for it.

It's also nice to see Max Payne's working.

lowenz wrote:
Uhm, no, it seems an engine/shader code bug. Tested with SwiftShader ((SW rasterizer) by Google and the results are the same: […]
Show full quote

Uhm, no, it seems an engine/shader code bug. Tested with SwiftShader ((SW rasterizer) by Google and the results are the same:

SM 1.x
Swift_Shader_SM1.png

SM 3.0
Swift_Shader_SM3.png

In spite of that, I think it's no wonder if there are problems with ps/vs 1.x in DX9.
DX8 and 9 are probably mapped to the same DDI (device driver interface) internally, that's one of the reasons why Komat's fix is needed for SC1.

Reply 2864 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t
Azarien wrote:
Why is the screen in Jedi Knight always stretched to the whole screen (16:10) instead of 4:3? […]
Show full quote

Why is the screen in Jedi Knight always stretched to the whole screen (16:10) instead of 4:3?

Without dg the screen is correctly pillarboxed which is what I want.

In other words, why doesn't dg respect the setting in display drivers? I'd like to play in 1280x960 without any resolution magic or scaling on part of dgVoodoo (the driver and monitor would display this resolution correctly).
I can't use the scaling options in dg setup because then the mouse stops working in menus (as described earlier by someone in this thread).

Win10, HD5770.

PS. what I'm asking for is a "native resolution" mode: if the game asks for e.g. 640x480, then do exactly that, and let the drivers and hardware do the thing they are configured to - just like basically every game does without dgVoodoo.

Basically it's not a dgVoodoo issue but a DXGI one. For DX<=9 the display driver (or rather the operating system) respects the expected aspect ratio for the given resolution because AR as a term is not present in those early versions of DX's.
Starting with DX10 however, choosing aspect ratio is up to the applications themself - the only problem is that 'Stretching with keeping AR' as an option is not available, only 'Centering' and plain 'Stretching'. So, I treat it as a poor design on Windows side.
As I wrote in the readme, dgVoodoo's internal Stretch+AR mode is not sterling, that's why mouse doesn't work for that game. The only solution is chosing 'unspecified' scaling in dgVoodoosetup and let the driver do what is does.
I'm aware that this is a problem for AMD. On nVidia control panel you can force the required stretching mode, and let the driver override the mode chosen by application. This is the recommended way.
But it doesn't work for AMD as there is no 'override application scaling mode' option for that. 😢
So, for this game currently there is no workaround on AMDs. 🙁
The only solution would be trying to add a fix in dgVoodoo, if possible (I didn't check that game yet, so I don't know).

Reply 2865 of 3949, by lowenz

User metadata
Rank Oldbie
Rank
Oldbie

In lastest AMD drivers I have some problems with "Centering" in DX9 applications too (Borderlands 2, so it's not related to dgVoodoo2).
I've switched from the otherwise good HD 7850 to a 1050 Ti :p

Not a particular leap ahead in overall performance but the drivers work.....

Reply 2866 of 3949, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie
Dege wrote:
Azarien wrote:

The only solution would be trying to add a fix in dgVoodoo, if possible (I didn't check that game yet, so I don't know).

I think it might work if dgVoodoo allowed to specify different scaling modes for different resolutions. Jedi Knight uses hardcoded 640x480 in menus (where the mouse problem occurs, but wrong AR is tolerable) and the user selected resolution in gameplay (where there's no mouse cursor so it shouldn't be a problem).

So as a hack use what is set in dgVoodoo config but fall back to "unspecified" in 640x480 only (and then select anything but 640x480 in gameplay).

Reply 2867 of 3949, by Kropotkin

User metadata
Rank Newbie
Rank
Newbie
Dege wrote:

In spite of that, I think it's no wonder if there are problems with ps/vs 1.x in DX9.
DX8 and 9 are probably mapped to the same DDI (device driver interface) internally, that's one of the reasons why Komat's fix is needed for SC1.

How combine his fix with dgVoodoo?

Reply 2869 of 3949, by teleguy

User metadata
Rank Member
Rank
Member
Dege wrote:
The only solution is chosing 'unspecified' scaling in dgVoodoosetup and let the driver do what is does. I'm aware that this is a […]
Show full quote

The only solution is chosing 'unspecified' scaling in dgVoodoosetup and let the driver do what is does.
I'm aware that this is a problem for AMD. On nVidia control panel you can force the required stretching mode, and let the driver override the mode chosen by application. This is the recommended way.
But it doesn't work for AMD as there is no 'override application scaling mode' option for that. 😢
So, for this game currently there is no workaround on AMDs. 🙁

Actually the unspecified scaling mode is working properly on AMD now. I don't know for how long this has been the case, I only noticed it recently. You just have to manually add a profile for the game in question and then you can set the scaling mode in the profile. While the driver controlpanel may have already automatically created a profile for the game, I found setting the scaling mode in that existing profile has no effect most of the time. Same goes for the global setting in the drivers display mode panel.

In the case of JK it's also necessary to run the game without the windowgui parameter.

´

Attachments

  • scaling.jpg
    Filename
    scaling.jpg
    File size
    36.61 KiB
    Views
    1479 views
    File license
    Fair use/fair dealing exception

Reply 2871 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t
Azarien wrote:
Dege wrote:
Azarien wrote:

The only solution would be trying to add a fix in dgVoodoo, if possible (I didn't check that game yet, so I don't know).

I think it might work if dgVoodoo allowed to specify different scaling modes for different resolutions. Jedi Knight uses hardcoded 640x480 in menus (where the mouse problem occurs, but wrong AR is tolerable) and the user selected resolution in gameplay (where there's no mouse cursor so it shouldn't be a problem).

So as a hack use what is set in dgVoodoo config but fall back to "unspecified" in 640x480 only (and then select anything but 640x480 in gameplay).

That would be a bit difficult on a GUI setup, I think I should write the text-based .ini-file variant of the config and place advanced config stuffs there.

teleguy wrote:
Dege wrote:
The only solution is chosing 'unspecified' scaling in dgVoodoosetup and let the driver do what is does. I'm aware that this is a […]
Show full quote

The only solution is chosing 'unspecified' scaling in dgVoodoosetup and let the driver do what is does.
I'm aware that this is a problem for AMD. On nVidia control panel you can force the required stretching mode, and let the driver override the mode chosen by application. This is the recommended way.
But it doesn't work for AMD as there is no 'override application scaling mode' option for that. 😢
So, for this game currently there is no workaround on AMDs. 🙁

Actually the unspecified scaling mode is working properly on AMD now. I don't know for how long this has been the case, I only noticed it recently. You just have to manually add a profile for the game in question and then you can set the scaling mode in the profile. While the driver controlpanel may have already automatically created a profile for the game, I found setting the scaling mode in that existing profile has no effect most of the time. Same goes for the global setting in the drivers display mode panel.

In the case of JK it's also necessary to run the game without the windowgui parameter.

Good to know! Thanks for the info, I'm going to check it out on my AMD next week.

lowenz wrote:

Can you share with us a WIP, dege? (to run 3DMark 2001 SE :p )

Q8W8V8U8 is not working yet...

Reply 2872 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t
Kropotkin wrote:
Dege wrote:

In spite of that, I think it's no wonder if there are problems with ps/vs 1.x in DX9.
DX8 and 9 are probably mapped to the same DDI (device driver interface) internally, that's one of the reasons why Komat's fix is needed for SC1.

How combine his fix with dgVoodoo?

They can't be combined together. Either Komat's or dgVoodoo.
What I meant earlier, was putting the same fix for missing shadows into Komat's fix that are already present in dgVoodoo.

Reply 2873 of 3949, by daniel_u

User metadata
Rank Member
Rank
Member

Hi Dege,
Nice to find out you are still commited to this project.

Will this refactoring bring smething new in terms of features or will help development in others areas?
Can this refactoring provide a more easy developement of features/bug fix for SC 1 & 2 games? 😀

Looking forward to the new WIP/version.

Reply 2874 of 3949, by Peixoto

User metadata
Rank Member
Rank
Member
Dege wrote:

In spite of that, I think it's no wonder if there are problems with ps/vs 1.x in DX9.
DX8 and 9 are probably mapped to the same DDI (device driver interface) internally, that's one of the reasons why Komat's fix is needed for SC1.

Indeed they are, but the runtime informs the DDI witch version of of DirectDraw\Direct3D is running:
https://msdn.microsoft.com/en-us/librar ... s.85).aspx
so the driver should be able to handle differences between the Direct3D versions correctly, but the Nvidia drivers
don't even check that info.

Reply 2877 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t

Thankfully to Qbix and Admins of Vogons, dgVoodoo just got a complete new section to post to: 😎

Board: dgVoodoo
Subforum: dgVoodoo General

Please create new tematic threads instead of posting into this one to avoid growing further this one.
If you'd like to continue a subtopic from thread 'dgVoodoo2 for DirectX11' then let's quote the last or important post(s) related to that in the starting post of the new thread. Maybe it's better than trying to split the old thread into multiple threads.

Reply 2878 of 3949, by Myloch

User metadata
Rank Member
Rank
Member

More technicolor problems (weird palette swappings) during fade in - fade out and low performance problems with old directdraw game Kujira Monogatari when using force resolution

"Gamer & collector for passion, I firmly believe in the preservation and the diffusion of old/rare software, against all personal egoisms"

Reply 2879 of 3949, by VicRattlehead

User metadata
Rank Newbie
Rank
Newbie

From what I understand, the DX wrapper already forces color depth to 32-bit, however I noticed that Slave Zero still runs with 16-bit color depth. It's known that the DX renderer of the game is limited to only 16-bit color, but I thought that dgVoodoo2 would have been able to work around that. And I know that the game does have 32-bit color textures because they appear as such with nGlide (dgVoodoo2's Glide wrapper fails to run the game!)

I also noticed what appears to be some sort of LOD problem with certain games that seem to have some connection with the color depth. I first noticed this in Sacrifice. If the in-game color depth is set to 16-bit, graphical errors(?) like this appear:
16_bit_color_Sacrifice_exe_2017_01_13_17_03_58_2.jpg
This is much more noticeable in motion because those sharp shapes keep shifting while the camera or viewpoint is moving.
For comparison here is a screenshot with in-game color depth set to 32-bit:
32_bit_color_Sacrifice_exe_2017_01_13_17_02_23_0.jpg

I noticed something similar as well in MechWarrior 3, it's far less noticeable and only seems to happen with vehicles and mechs. Unfortunately for that game, it isn't possible to change the color depth in-game so I can't determine if it's related to the issue in Sacrifice. It's difficult to capture it in one screenshot so I took two to show how parts of the highlighted area are shifting.
mech3_exe_2017_01_13_17_21_40_151.jpg
mech3_exe_2017_01_13_17_21_41_354.jpg