VOGONS


dgVoodoo 2 for DirectX 11

Topic actions

Reply 3180 of 3949, by lowenz

User metadata
Rank Oldbie
Rank
Oldbie

"Centered" started NOT working recently, but maybe it's the connection (HDMI vs DVI?) using the top 4:3 resolution (1440x1080 on a 1920x1080 panel) or my NVCP scaling settings.
Got to test further!

Using a custom 1440x1080 (correctly added through NVCP) it doesn't show in DVG2CP.....and in Windows Resolutions too. Still selecting it, in NVCP, as Windows Desktop resolution.....it works!
Lastest drivers (385.28) + HDMI connection to monitor.

Last edited by lowenz on 2017-08-20, 15:58. Edited 1 time in total.

Reply 3181 of 3949, by lowenz

User metadata
Rank Oldbie
Rank
Oldbie

With 382.xx and a 750 Ti the behaviour is the one intended.

1) GPU scaling (driver) + centered (dgV2) = 2) GPU scale-forcing (driver) + unspecified (dgV2) ==> 1440x1080 perfectly working (forced through dgVoodoo2 for Diablo 2) with 1) or 2)

Reply 3182 of 3949, by lowenz

User metadata
Rank Oldbie
Rank
Oldbie
lowenz wrote:

Using a custom 1440x1080 (correctly added through NVCP) it doesn't show in DVG2CP.....and in Windows Resolutions too. Still selecting ir, in NVCP, as Windows Desktop resolution.....it works!
Lastest drivers (385.28) + HDMI connection to monitor.

Update: after a COMPLETE reboot (not a sign-out from the account) it's working as expected.

So for NV:

1) choose "GPU scaling" with NO forcing in NVCP
2) declare a custom resolution in NVCP
3) test it with the Windows Desktop
4) REBOOT the system
5) now you can check the added resolution(s) in dgVoodoo2 list
6) choose "centered" in dgVoodoo2

OR

1) choose "GPU scaling" with forcing in NVCP
2) declare a custom resolution in NVCP
3) test it with the Windows Desktop
4) REBOOT the system
5) now you can check the added resolution(s) in dgVoodoo2 list
6) choose "unspecified" in dgVoodoo2

Reply 3183 of 3949, by galneon

User metadata
Rank Newbie
Rank
Newbie

(I edited my previous post to reflect I was talking about MM6 which scales perfectly, not MM5 (sorry--I just finished playing through MM4+5).)

Dege wrote:

Well, the whole process can be divided into 2 phases:

...

So, if you want sharp output appearance then your best choose is selecting 'centered' scaling mode. Additionally, you can force the game resolution to 'Max ISF' to make the output image as large as possible.

This produces the same result as unspecified scaling + Max ISF for me, I believe because I have scaling set to GPU 'no scaling' mode in the driver control panel. 640x480 becomes 1280x960 with bilinear applied in MM7-8, and 640x480 becomes 1280x960 with pixels cleanly doubled (nearest 2x) in MM6 like I want. These all come out 1:1 with black borders on all sides as intended by the way, something I should have specified previously. I never use hardware scaling because my eyes just won't allow me--guaranteed migraine after a few minutes reading fuzzy text. This makes older text-heavy Win32 games on an LCD off-limits to me, whereas I can use integer locked nearest neighbor in DOSBox and console emulators. I only wish it was just a matter of snobbery. 😜

For some sad reason 'Centered' doesn't work for me on nVidia and AMD. I always get some stretched garbage. Works perfectly on Intel though. DXGI scaling modes seem to be totally unreliable for me.
That's why I've just added a new 'Centered, keep AR' to dgVoodoo. Max ISF + Centered AR seem to work very well.

Your problem with centered on Nvidia/AMD is it stretches outside the aspect ratio? It maintains AR for me (GTX 970, latest drivers or nearly) so I guess I can expect Max ISF + Centered AR to perform the same in my case. If it matters I use DVI.

I don't know, isn't the game itself designed to render with nearest point? What if you force the texture filtering to bilinear, or enable 'Bilinear blit stretch'?

Forcing texture filtering does nothing as the game has no hardware texturing, but bilinear blit stretch gives me the familiar awful fuzzy mess of MM7 and 8--so the game defaults to nearest with pixels doubled as desired under Max ISF, but if bilinear blit stretch is selected it scales blurry just like the latter games. I didn't think about games with fixed resolutions as having specified scaling, but I suppose the 1:1 rendering method and scaling method are one in the same--something is still rendered nearest even if it's 1:1 and not doubled (or multiplied by a non-integer). I was hoping it wasn't game-specific but API-specific which might have made it easier to override the scaling method of slightly newer games like MM7/8. 🙁

I had thought the wrapper was solely at the mercy of graphics drivers, but if the forced resolution scaling method is game-specific, I guess we may be screwed until graphics drivers (for Windows) come along that can achieve it when outputting to display without forcing the game's internal resolution. Nvidia just recently added nearest neighbor integer scaling to its Linux drivers. I am very jealous, and there's no guarantee it's coming for Windows. 😒

- If scaling modes 'Stretched, *' are selected then dgVoodoo does its own scaling. First it determines the native resolution of the output (in fact, it assumes that desktop resolution for the output in question is the same as its native resolution), and works with an output buffer with that size (similar to fake fullscreen).
In this way it's ensured that dgVoodoo's output is mapped by 1:1 to the screen and so the driver/display scaling process is omitted.

I'm probably misunderstanding the possibilities here and am clutching at straws, but is it possible to keep the game's internal resolution its native (640x480) while using non-existent dgVoodoo scaling mode 'Stretched AR, nearest'? I know nearest neighbor fullscreen is a problem because few games scale neatly to e.g. 1920x1080 or 1440x1080 (would need to be 720x540 internal resolution) and nearest neighbor with non-integer factors looks terrible, but if the output resolution could be specified upon launch, or desktop resolution is manually switched by the user to 1280x960 beforehand so that dgVoodoo can keep assuming desktop = native resolution, then... See where I'm going? If I set the desktop resolution to 1280x960 beforehand, what's to keep dgVoodoo, if it had the option, from doing nearest neighbor instead of bilinear since the GPU driver/display scaler is out of the loop? My change of desktop resolution would ensure it scales cleanly. I wouldn't be the only elated person if this were possible.

I really appreciate your taking the time. I'm a novice but really want to understand the hurdles here as I feel cut off from many of my favorite older games because I use an LCD for which ideal scaling is rarely possible, and I have little faith Nvidia or AMD will ever implement additional driver-level scaling options. Some have speculated they don't want to offer a way to make 1920x1080 look sharp on 4k displays because it would attenuate sales of monster cards capable of running games 4k @ 60 fps. The truth is such an option would be useful in more ways than one.

Reply 3184 of 3949, by lowenz

User metadata
Rank Oldbie
Rank
Oldbie

Man, you can ALREADY force the rendering resolution (apart from 2D elements -> HUD, etc.) to whatever you want. Why do you want resolution like 640x480 and a sharp rescaling?
Resolution-dependent effects? (Pandora Tomorrow, etc.) ?

I force MechWarrior 3 and MechWarrior 4 to 1440x1080, choosing "centered" option in dgV2 and GPU rescaling (keeping the Aspect Ratio) in NVCP (no forcing needed, NV offers the possibility to force it too).
Apart from 2D HUD elements, it's perfect with my 1920x1080 panel.

Reply 3185 of 3949, by ZellSF

User metadata
Rank l33t
Rank
l33t
lowenz wrote:

Man, you can ALREADY force the rendering resolution (apart from 2D elements -> HUD, etc.) to whatever you want. Why do you want resolution like 640x480 and a sharp rescaling?
Resolution-dependent effects? (Pandora Tomorrow, etc.) ?

2D games would be a huge reason. Not that I can think of any 2D game that only plays in dgVoodoo2 and not in either DXGL or DxWnd (both offer perfect integer scaling).

Also some people prefer to play 3D games at their original resolution.

galneon wrote:

Some have speculated they don't want to offer a way to make 1920x1080 look sharp on 4k displays because it would attenuate sales of monster cards capable of running games 4k @ 60 fps.

Those are stupid people, you should not be listening to them.

Reply 3186 of 3949, by galneon

User metadata
Rank Newbie
Rank
Newbie
lowenz wrote:

Man, you can ALREADY force the rendering resolution (apart from 2D elements -> HUD, etc.) to whatever you want. Why do you want resolution like 640x480 and a sharp rescaling?
Resolution-dependent effects? (Pandora Tomorrow, etc.) ?

I don't know how I could be clearer. If you've read my previous posts and still don't understand, then I cannot help you beyond stating: "simply doubling the internal resolution results in blurry bilinear upscaling for the majority of games".

I force MechWarrior 3 and MechWarrior 4 to 1440x1080, choosing "centered" option in dgV2 and GPU rescaling (keeping the Aspect Ratio) in NVCP (no forcing needed, NV offers the possibility to force it too).
Apart from 2D HUD elements, it's perfect with my 1920x1080 panel.

Ok. I'm glad you're happy with that.

If it's possible, nearest neighbor for dgVoodoo would be greatly appreciated by a lot of people. I linked to threads of people who would love this feature for older DX games, not all of which are covered by other wrappers.

There's no need to dump allover a reasonable request simply because you do not share my aesthetic sensibilities, or my eye-strain problem which limits what games I can play on a modern LCD. I also play old console games using nearest neighbor. Sharpness is much easier on my eyes.

ZellSF wrote:

2D games would be a huge reason. Not that I can think of any 2D game that only plays in dgVoodoo2 and not in either DXGL or DxWnd (both offer perfect integer scaling).

There are plenty of text-heavy 3D games that use pixellated (non-bitmap) fonts which get mangled by bilinear filtering but would otherwise scale neatly under integer ratios and nearest neighbor. This is well beyond the scope of dgVoodoo, but there are even recent examples, like FTL, which would scale perfectly at 2x on a 1440p display.

I had no luck with DXGL the other day, but I just tried with DxWnd with the usual settings to emulate fullscreen, and it does indeed work for MM8. Many years ago when I tried it with MM7 I had no luck. I assume it would work with MM7 as well now. So my MM6-8 troubles are ameliorated. Even with a different solution available, I think nearest neighbor has great value in dgVoodoo 2, if it's possible.

Reply 3187 of 3949, by lowenz

User metadata
Rank Oldbie
Rank
Oldbie

You're clear (-> "There are plenty of text-heavy 3D games that use pixellated (non-bitmap) fonts which get mangled by bilinear filtering but would otherwise scale neatly under integer ratios and nearest neighbor."), sorry 😉

For Dege: how about the DX 10/10.1/11 passthrough (with custom hooking for ReShade and similar shader managers) ?

Reply 3188 of 3949, by MetalBuffalo

User metadata
Rank Newbie
Rank
Newbie
Dege wrote:

I had a look at this game but it didn't render fog even natively. Ok, this can be because of broken D3D support but when I looked at youtube videos, I didn't see fog there too.

A number of posts on the Battlefront forums indicate that fog can be rendered, and the manual states that the weather graphics setting "Toggles the display of weather effects like rain, snow and fog".
I came across a couple of screenshots showing what the fog should like:
https://web.archive.org/web/20020604172359/ht … /hetzershot.jpg
https://web.archive.org/web/20020225035458/ht … OTD/geforce.JPG

Reply 3189 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t

Ok, I've been pondering on the scaling problem, especially how to make it as general as possible.

My first idea was creating a new 'Stretched, keep aspect ratio (ISF)' scaling mode which would scale the output image (coming from Glide/DirectX) by the largest possible integer factor (with nearest point filtering).
However it's not a general solution at all, + would always force dgVoodoo's own additional scaling (e.g. unspecified, centered modes couldn't be available).

So I think the best solution would be adding a new step to the output process instead:

Output image (coming from Glide/DirectX) ----> Scale it up by an integer factor ------> Output the image to the screen applying the currently selected scaling mode

The scaling factor could be an arbitrary integer (or 'max', leaving determinating it to the wrapper) but could be available only through the text version config file (not on the CPL).
Of course its usage only makes sense with a centered scaling mode, because for example, if one of the stretched modes or modes with forced 4:3 AR is selected then the integer-scaled image potentially gets scaled further with linear filtering.

lowenz wrote:

For Dege: how about the DX 10/10.1/11 passthrough (with custom hooking for ReShade and similar shader managers) ?

Unfortunately very slowly. I had no or very little time for that recently but I already did some development on things I intend to be public, later.

MetalBuffalo wrote:
A number of posts on the Battlefront forums indicate that fog can be rendered, and the manual states that the weather graphics s […]
Show full quote
Dege wrote:

I had a look at this game but it didn't render fog even natively. Ok, this can be because of broken D3D support but when I looked at youtube videos, I didn't see fog there too.

A number of posts on the Battlefront forums indicate that fog can be rendered, and the manual states that the weather graphics setting "Toggles the display of weather effects like rain, snow and fog".
I came across a couple of screenshots showing what the fog should like:
https://web.archive.org/web/20020604172359/ht … /hetzershot.jpg
https://web.archive.org/web/20020225035458/ht … OTD/geforce.JPG

Thanks! Finally a pivot point! 😀

Reply 3191 of 3949, by galneon

User metadata
Rank Newbie
Rank
Newbie

Great news on the scaling front. 😀

Reply 3193 of 3949, by lowenz

User metadata
Rank Oldbie
Rank
Oldbie

About the scaling, Sacred Gold 2.28 actually has a really strange behaviour and maybe Dege can take a look (when he can).

Using "aspect ratio" option in NVCP with *NO* forcing and "centered" option in dgVoodoo2 I would expect the a centered but stretched frame ('cause D3D11 and *NO* forcing).....but it's the only game I found that creates a centered 1024x768 frame NOT stretched. Why this behaviour without the *forcing* option?

Reply 3194 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t
Firtasik wrote:

Thx!
I haven't yet checked out the game, but actually it seems to be bad news (the same issue as NFS3 DX6 renderer had).
If the projection matrix is not set properly then z-fog is assumed. Citation from DX7 docs:

When eye-relative fog is supported, the system will automatically use eye-relative depth in favor of z-based depth if the provided projection matrix produces z-values in world space that are equivalent to w-values in device space. (You set the projection matrix by calling the IDirect3DDevice7::SetTransform method, using the D3DTRANSFORMSTATE_PROJECTION value and passing a D3DMATRIX structure that represents the desired matrix.) If the projection matrix isn't compliant with this requirement, fog effects will not be applied properly.

If the game had fog in spite of it, then it seems to be an old broken driver issue which should be emulated somehow.

Reply 3195 of 3949, by Firtasik

User metadata
Rank Oldbie
Rank
Oldbie

That's unfortunate. BTW, have you checked the Carmageddon's menu fix?

11 1 111 11 1 1 1 1 1 11 1 1 111 1 111 1 1 1 1 111

Reply 3196 of 3949, by Blobby

User metadata
Rank Newbie
Rank
Newbie
Dege wrote:

Thx!
I haven't yet checked out the game, but actually it seems to be bad news(the same issue as NFS3 DX6 renderer had).
If the projection matrix is not set properly then z-fog is assumed.

Firtasik wrote:

That's unfortunate. BTW, have you checked the Carmageddon's menu fix?

I don't understand all this negativity.

The latest DDrawCompat fix WORKS! It FIXES the 'no fog displayed' 'bug' for CMBB and CMBO and probably CMAK too. For Nvidia and Intel HD graphics at least anyway. Apparently, later AMD drivers work without needing this fix, natively.

You have to download the latest experimental release with commit 179 applied. Unfortunately to date, the date of release text hasn't been updated, but the binaries ARE up to date.

I also don't know why Dege says 'IF the game had fog...'. Yes of course it does have fog effects. It always did have fog effects. It's just that later drivers failed to display it for whatever reason- Narzoul's explanation here: https://github.com/narzoul/DDrawCompat/commit … cd8537fa41e3564

And as I already said previously here, a scenario has to specifically use the 'fog' weather effect, which can be set to 'fog' or heavy fog' for it to be seen in game. Not all scenarios use the effect by default. So, quite obviously, if a scenario is not using it, it cannot be seen. 😉

The problem was that if a scenario was using the effect you couldn't see it - on Nvidia cards etc. Hope this is now clear as to what the problem was.

Narzoul understood all of this in a few minutes, and FIXED it. 😀 So, I'm sure that dgVoodoo2 could be adapted likewise?

Reply 3197 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t
Blobby wrote:
I don't understand all this negativity. […]
Show full quote

I don't understand all this negativity.

The latest DDrawCompat fix WORKS! It FIXES the 'no fog displayed' 'bug' for CMBB and CMBO and probably CMAK too. For Nvidia and Intel HD graphics at least anyway. Apparently, later AMD drivers work without needing this fix, natively.

...

Narzoul understood all of this in a few minutes, and FIXED it. 😀 So, I'm sure that dgVoodoo2 could be adapted likewise?

I'm pretty sure me too understand the problem, which is the following:
D3D supports 2 kinds of pixel fog: Z-based and W-based (eye-relative). The D3D standard clearly states that a w-compliant (simple perspective) projection matrix has to be provided to achieve W-fog.
Otherwise D3D doesn't have information on W, it all is coming from plain maths. This all is needed even when the application feeds D3D with pretransformed vertices having W component.

If a D3D driver produces W-fog in spite of that all, then the driver is broken in repspect to the D3D standard (like AMD and old Win98/XP drivers). Intel driver is the one working properly here.
Narzoul forced W-fog by fooling the driver, to achieve compatibility with broken ones, but it's not a fix but a hack, breaks the standard on the other side. If this 'fix' is game specific (Combat Mission), then it's ok after all.

dgVoodoo has no game specific fixes, so the question turns up: should dgVoodoo be compatible with old drivers or the D3D standard? I chosed the latter.
So, the only solution is having an option in dgVoodoo for forcing W-fog for such (rare) cases. With that enabled, Combat Mission has fog with dgVoodoo.

Update: forcing w-fog could be tied to old card types too (ATI 8500 or GeForce) as those profiles already contain some old driver specific hacks...

Reply 3198 of 3949, by Blobby

User metadata
Rank Newbie
Rank
Newbie

@Dege

Thank you for the explanation.

While I was searching for a solution for this problem, I came across this post from Intel:

https://www.intel.com/content/www/us/en/suppo … /000007288.html

They state here that "Fog table emulation is automatically enabled in these (new) graphics drivers". This is also the thing that RivaTuner used to have as an optional toggle to make old AMD drivers able to see fog effects again, which had been 'disabled' in those drivers (and thus caused people to complain on the Battlefront forums about not seeing fog effects).

This would suggest that even Intel admit that the driver was NOT working 'properly' before (well that particular one at least)?

It further suggests that up to date Intel drivers are not working properly either if Pixel fog effects are not showing up!

Later and most recent AMD drivers seem to have done the same thing as the Intel fix and 'enabled' Fog table emulation yet again, by default.

So, is it really a broken driver issue? I suppose you could call it a compatibility mode maybe?

But, whether it is or not, the hack/fix or whatever you want to call it , WORKS. Surely, from a gaming perspective that's far more valuable than just adhering to the D3D standard verbatim.

If you could add an option to force this 'hack' then I don't see why anyone would object to the slight corruption of the D3D protocol.

Options are always good. 😀 And this is where dgVoodoo2 has the advantage over DdrawCompat because of the GUI options that the user can set. Pretty cool.

BTW, isn't this lack of fog effect also an issue in the early Thief games too?

Reply 3199 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t

Thx, maybe I'm lagging behind new-fashioned fogging customs... 😁 😁 😁

I didn't intend this option on the CPL GUI because (as far as I know) it's a rare issue with some games.

BTW, isn't this lack of fog effect also an issue in the early Thief games too?

Uhmm..., I don't know...

My first idea was the option, but as the 'driver' of the internal virtual card strictly follows the D3D standard, and others like GeForce/ATI/Matrox cards are present in order to bias the implementation toward chip-specific features/properties and contemporary driver implementations, I decided to put forcing of W-fog into GeForce/ATI profiles. I'm not sure if it's the best solution, might change it later, we'll see.

I also implemented the integer scaling of output images (but that option is not available on the CPL, only via the INI file because I find this kind of scaling rarely and exceptionally used).