dgVoodoo 2 for DirectX 11

General information and assistance with dgVoodoo.

Re: dgVoodoo 2 for DirectX 11

Postby lowenz » 2017-1-04 @ 10:53

Thanks!

So much beauty in this old lady from 2003 with the win10 compatibility thanks to dege, a widescreen fix and a touch of postprocessing :D
lowenz
Oldbie
 
Posts: 729
Joined: 2014-12-20 @ 01:30

Re: dgVoodoo 2 for DirectX 11

Postby lowenz » 2017-1-04 @ 14:59

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:
Image

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

So, as dege says, there's already some problems :p
lowenz
Oldbie
 
Posts: 729
Joined: 2014-12-20 @ 01:30

Re: dgVoodoo 2 for DirectX 11

Postby lowenz » 2017-1-04 @ 15:42

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
Image

SM 3.0
Image
lowenz
Oldbie
 
Posts: 729
Joined: 2014-12-20 @ 01:30

Re: dgVoodoo 2 for DirectX 11

Postby Dege » 2017-1-04 @ 19:35

UCyborg, thanks for your efforts!!

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

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:

SM 1.x
Image

SM 3.0
Image


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.
Dege
Oldbie
 
Posts: 904
Joined: 2003-9-04 @ 11:06

Re: dgVoodoo 2 for DirectX 11

Postby Dege » 2017-1-05 @ 13:00

Azarien wrote: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. :depressed:
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).
Dege
Oldbie
 
Posts: 904
Joined: 2003-9-04 @ 11:06

Re: dgVoodoo 2 for DirectX 11

Postby lowenz » 2017-1-05 @ 13:19

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.....
lowenz
Oldbie
 
Posts: 729
Joined: 2014-12-20 @ 01:30

Re: dgVoodoo 2 for DirectX 11

Postby Azarien » 2017-1-05 @ 16:38

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).
Azarien
Member
 
Posts: 301
Joined: 2015-5-14 @ 07:14

Re: dgVoodoo 2 for DirectX 11

Postby Kropotkin » 2017-1-05 @ 20:04

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?
Kropotkin
Newbie
 
Posts: 12
Joined: 2017-1-01 @ 06:35

Re: dgVoodoo 2 for DirectX 11

Postby lowenz » 2017-1-05 @ 21:21

dgVoodoo doesn't need Komat fix, enable the GeForce 4 preset and you're good to go.
lowenz
Oldbie
 
Posts: 729
Joined: 2014-12-20 @ 01:30

Re: dgVoodoo 2 for DirectX 11

Postby teleguy » 2017-1-05 @ 23:51

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 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. :depressed:
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
teleguy
Member
 
Posts: 347
Joined: 2004-2-28 @ 18:54

Re: dgVoodoo 2 for DirectX 11

Postby lowenz » 2017-1-06 @ 14:54

Can you share with us a WIP, dege? (to run 3DMark 2001 SE :p )
lowenz
Oldbie
 
Posts: 729
Joined: 2014-12-20 @ 01:30

Re: dgVoodoo 2 for DirectX 11

Postby Dege » 2017-1-06 @ 19:34

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 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. :depressed:
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...
Dege
Oldbie
 
Posts: 904
Joined: 2003-9-04 @ 11:06

Re: dgVoodoo 2 for DirectX 11

Postby Dege » 2017-1-06 @ 19:43

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.
Dege
Oldbie
 
Posts: 904
Joined: 2003-9-04 @ 11:06

Re: dgVoodoo 2 for DirectX 11

Postby daniel_u » 2017-1-07 @ 16:10

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.
User avatar
daniel_u
Member
 
Posts: 187
Joined: 2015-1-11 @ 12:19

Re: dgVoodoo 2 for DirectX 11

Postby Peixoto » 2017-1-08 @ 18:40

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/library/windows/hardware/ff542931(v=vs.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.
User avatar
Peixoto
Newbie
 
Posts: 32
Joined: 2013-6-13 @ 23:48

Re: dgVoodoo 2 for DirectX 11

Postby lowenz » 2017-1-08 @ 23:49

Do you have some examples of NV drivers going foobar with PS 1.x in D3D9 applications?
lowenz
Oldbie
 
Posts: 729
Joined: 2014-12-20 @ 01:30

Re: dgVoodoo 2 for DirectX 11

Postby Qbix » 2017-1-09 @ 21:13

*moved to new location*
Water flows down the stream
How to ask questions the smart way!
User avatar
Qbix
DOSBox Author
 
Posts: 10313
Joined: 2002-11-27 @ 14:50
Location: Fryslan

Re: dgVoodoo 2 for DirectX 11

Postby Dege » 2017-1-09 @ 22:04

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

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.
Dege
Oldbie
 
Posts: 904
Joined: 2003-9-04 @ 11:06

Re: dgVoodoo 2 for DirectX 11

Postby Myloch » 2017-1-12 @ 09:46

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"
User avatar
Myloch
Member
 
Posts: 350
Joined: 2007-4-18 @ 22:13

Re: dgVoodoo 2 for DirectX 11

Postby VicRattlehead » 2017-1-13 @ 09:42

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:
Image
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:
Image

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.
Image
Image
VicRattlehead
Newbie
 
Posts: 16
Joined: 2016-11-12 @ 08:08

PreviousNext

Return to dgVoodoo General

Who is online

Users browsing this forum: No registered users and 2 guests