VOGONS


dgVoodoo 2.7.x and related WIP versions

Topic actions

Reply 360 of 380, by lowenz

User metadata
Rank Oldbie
Rank
Oldbie
VoidsShadow wrote on 2021-02-22, 02:36:
Xp-era Fullscreen is Exclusive Fullscreen. The app takes full control of the display. Fake fullscreen is essentially a window th […]
Show full quote
lowenz wrote on 2021-02-21, 23:08:

Thanks Dege!

Can I ask a favour? Reading there "fake fullscreen" .....can you explain me (us) ALL the different type of "fullscreen" mode existing today and how they compare 1) to one another 2) to classic fullscreen of WinXP era?

Xp-era Fullscreen is Exclusive Fullscreen. The app takes full control of the display.
Fake fullscreen is essentially a window that covers the whole screen (Borderless Fullscreen Window) and inherits Windows' Desktop Window Manager traits (enforced double-buffer V-Sync, Aero Theme processing, et cetera). Display settings are managed by Windows' DWM/Aero and system settings.

unknown.png

I'm asking about ALL possible versions of "Borderless Fullscreen Mode". Don't know if "Fake (exclusive) fullscreen" is part of them only 'cause there's no control of gamma and other monitor features.
Take Unreal Engine 4: it has "fullscreen" and "bordeless fullscreen", so they translate into "fake fullscreen" and "desktop-expanded window" (so it's not possible what you're saying, fake and and expanded window are not equivalent).
Or maybe it's more complex and they're different kind of "borderless" and it's why I'm asking Dege about.

1) Exclusive fullscreen is fake fullscreen?
2) Fake fullscreen is FLIP fullscreen?
3) FLIP fullscreen is a kind of borderless mode but not equivalent to desktop-expanded window?

It's not so trivial, there is a big number of combinations about what's "borderless" and not.

Reply 361 of 380, by Narzoul

User metadata
Rank Newbie
Rank
Newbie
lowenz wrote on 2021-02-22, 10:11:
I'm asking about ALL possible versions of "Borderless Fullscreen Mode". Don't know if "Fake (exclusive) fullscreen" is part of t […]
Show full quote

I'm asking about ALL possible versions of "Borderless Fullscreen Mode". Don't know if "Fake (exclusive) fullscreen" is part of them only 'cause there's no control of gamma and other monitor features.
Take Unreal Engine 4: it has "fullscreen" and "bordeless fullscreen", so they translate into "fake fullscreen" and "desktop-expanded window" (so it's not possible what you're saying, fake and and expanded window are not equivalent).
Or maybe it's more complex and they're different kind of "borderless" and it's why I'm asking Dege about.

1) Exclusive fullscreen is fake fullscreen?
2) Fake fullscreen is FLIP fullscreen?
3) FLIP fullscreen is a kind of borderless mode but not equivalent to desktop-expanded window?

It's not so trivial, there is a big number of combinations about what's "borderless" and not.

This article might be a good starting point, with links to additional material: https://devblogs.microsoft.com/directx/dxgi-flip-model/
It's a bit programming-oriented, but you can probably get the gist of it without knowing much about the DX APIs.

Reply 363 of 380, by Dege

User metadata
Rank Oldbie
Rank
Oldbie
VoidsShadow wrote on 2021-02-22, 05:07:

WIP78 Release build's x86 d3d9.dll does nothing. No window/rendering changes take effect and the dgVoodoo logo is not present. The debug binary works as expected with the same ini configuration.

How can that be? I use the same right now and it works. Doesn't your AV deletes d3d9.dll before you could use it?

lowenz wrote on 2021-02-21, 23:08:

Thanks Dege!

Can I ask a favour? Reading there "fake fullscreen" .....can you explain me (us) ALL the different type of "fullscreen" mode existing today and how they compare 1) to one another 2) to classic fullscreen of WinXP era?

Classic 98/XP era:
Full screen could only be achieved in exclusive mode. Exclusive mode mimiced the old DOS days where multimedia applications had direct access to the (display) hardware, possessed all hw resources unlike standard windowed GDI applications.
So, the rendered backbuffers could be presented to the screen by a very fast 'flip' operation which only involved modifying a register (describing the visible screen-area) on the video card (or sending a single command to do that) (flip model).
In windowed mode the rendered offscreen back buffer could only be copied (by hw) into the game window which was a much more expensive operation, especially when the window-clip region had to be taken into account (blit model).

Win Vista+ era:
When the desktop compositor, which is a fullscreen DX application itself, appeared then some things had to be changed.
For full screen exclusive the compositor had to be disabled for the given monitor output, giving the same access to the application as before. To my knowledge, legacy DXGI flip model still works this way in Win10, that's why gamma calibration still there.
For windowed presentation things got more complicated since it's the compositor who composes the final desktop image, so the blt-copy had to be redirected into a DWM-texture and allow the compositor to draw the window image from that texture later (at its own refresh rate) (blit model).
Or, if the application could declare that it's not interested in preserving the content of its backbuffers then the DWM could utilize directly the backbuffer for the texturing, omitting the copy-step, and allocating a new backbuffer to the app to be able to continue the rendering (blit-discard model for windowed mode).
This discard model as an option was backported to D3D9Ex too.

So, fake fullscreen always goes through the compositor and real full screen has the traditional direct fastest presentation technique.

BUT, MS also introduced the mix of the "discard blit" and the "flip" models: "flip discard" model. In this model the app has no longer direct access to the hw, the presentation always goes through the compositor and back buffer contents are discarded, no gamma calibration. So, it's basically the same as the blit-discard model for windowed mode. It's mandatory for D3D12.
AFAIR MS claimed in the blogs that they can do the presentation as fast as in real fullscreen thanks to the various optimizations in the compositor. I'm not sure if it's true because at insane frame rates (1000+) D3D11 seems to be faster for me.
I don't know if they introduced it in order to lower the margin for applications and letting the compositor always run to have better compatibility in the future or it's because of the fact that frame presenting must go through an application-created command queue and it cannot work in real flip-mode. I can't see into the deep internals of the graphics kernel and the compositor.

Fake fullscreen is the same as you can already achieve with borderless fullscreen size windowed mode except that it has mouse emulation enabled.
I think it's mostly useful for games that places other windows over the game window (like dialog boxes in Gruntz) because the rendering will not be pulled out from fullscreen-state and got minimized, etc.

So, what's the difference between real/fake fullscreen with D3D12 in dgVoodoo? I think basically nothing. "Real" fullscreen probably better for it though because D3D12 knows that it's in full screen state and can do any optimization it wants for frame presenting.

Reply 365 of 380, by lowenz

User metadata
Rank Oldbie
Rank
Oldbie
Dege wrote on 2021-02-21, 18:03:
- Changing the criterions for accepting incoming refresh rate values in DX: […]
Show full quote

- Changing the criterions for accepting incoming refresh rate values in DX:

  • Enumerate refrate enabled: any value accepted but replaced with the forced one
  • Enumerate refrate disabled: incoming value must match one or (one+1) (to workaround the problem of truncated/rounded rationals) from the internal list

http://dege.fw.hu/temp/dgVoodooWIP78.zip
http://dege.fw.hu/temp/dgVoodooWIP78_dbg.zip

NOT working in Pariah.

Still 60 Hz setting 75 and 75 setting 74 :p

Can you add one-1 ?

Reply 366 of 380, by Dege

User metadata
Rank Oldbie
Rank
Oldbie

The "problem" is with the game engine: it does not see the one+1 values in the enumerated list so if DesiredFrameRate is not found amongst them then it seems to pick up default 60 (or the lowest in the list) value.

Maybe a solution for that in dgVoodoo: let's have 60, 70, 72 and 75 Hz's as classic framerates. If the value-1 of them is available for the given resolution (coming from the physical adapter) then let's insert value into the list too, to have it seen by the application.

Reply 369 of 380, by Dege

User metadata
Rank Oldbie
Rank
Oldbie

I've released dgVoodoo 2.73.

It's basically the same as WIP78 except that I added the concept of 'classic refresh rates' to ease accepting those values. See readme for more.

  • Replacing the HLSL compiler in Glide ps shaders with an own code generator
    So now dgVoodoo does not need the external D3DCompiler at all
  • Optimizations in D3D sw vertex processing calcs
  • Optimizations in D3D state blocks + some minor D3D9 optimizations
  • Fixing a D3D9 shader incompatibility (Mass Effect)
  • Fixing a shader validator bug (Garfield - Lasagna World Tour)
  • Fixing a regression bug in D3D frontend (Crush)
  • Fixing another bug in D3D frontend
  • Fixing a D3D12 API driving bug
  • Fixing a bump mapping bug in FF shaders (Matrox G400 demo)
  • Fixing a cube texture resolution scaling bug (Colin McRae Rally 3)
  • Fixing a vs.1.x code generator bug (Splinter Cell 2)
  • Fixing D3D9 vs.3.x pointsize output (Fable 3)
  • Minor comparison sampling fix for D3D8/9 (Test Drive Unlimited 2) (D3D12 is recommended)
  • Fixing a D3D colorkeying bug (Restricted Area)
  • Changing the criterions for accepting incoming refresh rate values in DX (see the DirectX readme for details)
  • Fixing a bug in Glide D3D12 backend (Ultimate Race Pro)
  • Fixing an encountered Glide bug (texture chroma range)
  • Minor modification for Glide GrSstWinOpen to accept (and convert) more invalid buffercount combinations
  • Some debug layer fixings for Glide3 Napalm
  • Gamma ramps now automatically works with D3D12 (with underlying optimizations)
    - Color profile is always inherited because of calibration standards on modern systems
    - Option General\InheritColorProfileInFullScreenMode is only taken into account when a D3D11 output API is explicitly selected (compatibility mode for old hw)
  • Introducing option GeneralExt\FullscreenAttributes with attribute 'Fake' to enable fake fullscreen rendering
  • Enabling control tabbing + fixing tab-order for the CPL

http://dege.fw.hu/dgVoodoo2/bin/dgVoodoo2_73.zip
http://dege.fw.hu/dgVoodoo2/bin/dgVoodoo2_73_dbg.zip

Reply 370 of 380, by ZellSF

User metadata
Rank Oldbie
Rank
Oldbie

Not sure if you're keeping track, but the latest refresh rate changes fixes Sins of a Solar Empire. It was working, the settings weren't since it couldn't enumerate resolutions..

Edit: no this game is just weird.

Seems the game is saving something. It will only enumerate resolutions with the latest dgVoodoo version, but if you've run the game with that subsequent runs with earlier dgVoodoo versions will enumerate correctly. Really weird.

Reply 372 of 380, by Ivan89el

User metadata
Rank Newbie
Rank
Newbie
Dege wrote on 2021-02-26, 17:19:
I've released dgVoodoo 2.73. […]
Show full quote

I've released dgVoodoo 2.73.

It's basically the same as WIP78 except that I added the concept of 'classic refresh rates' to ease accepting those values. See readme for more.

  • Replacing the HLSL compiler in Glide ps shaders with an own code generator
    So now dgVoodoo does not need the external D3DCompiler at all
  • Optimizations in D3D sw vertex processing calcs
  • Optimizations in D3D state blocks + some minor D3D9 optimizations
  • Fixing a D3D9 shader incompatibility (Mass Effect)
  • Fixing a shader validator bug (Garfield - Lasagna World Tour)
  • Fixing a regression bug in D3D frontend (Crush)
  • Fixing another bug in D3D frontend
  • Fixing a D3D12 API driving bug
  • Fixing a bump mapping bug in FF shaders (Matrox G400 demo)
  • Fixing a cube texture resolution scaling bug (Colin McRae Rally 3)
  • Fixing a vs.1.x code generator bug (Splinter Cell 2)
  • Fixing D3D9 vs.3.x pointsize output (Fable 3)
  • Minor comparison sampling fix for D3D8/9 (Test Drive Unlimited 2) (D3D12 is recommended)
  • Fixing a D3D colorkeying bug (Restricted Area)
  • Changing the criterions for accepting incoming refresh rate values in DX (see the DirectX readme for details)
  • Fixing a bug in Glide D3D12 backend (Ultimate Race Pro)
  • Fixing an encountered Glide bug (texture chroma range)
  • Minor modification for Glide GrSstWinOpen to accept (and convert) more invalid buffercount combinations
  • Some debug layer fixings for Glide3 Napalm
  • Gamma ramps now automatically works with D3D12 (with underlying optimizations)
    - Color profile is always inherited because of calibration standards on modern systems
    - Option General\InheritColorProfileInFullScreenMode is only taken into account when a D3D11 output API is explicitly selected (compatibility mode for old hw)
  • Introducing option GeneralExt\FullscreenAttributes with attribute 'Fake' to enable fake fullscreen rendering
  • Enabling control tabbing + fixing tab-order for the CPL

http://dege.fw.hu/dgVoodoo2/bin/dgVoodoo2_73.zip
http://dege.fw.hu/dgVoodoo2/bin/dgVoodoo2_73_dbg.zip

Would you like to fix the problem?: Re: Problematic Windows games list
There is both on nvidia and on amd, to reproduce it, turn on the fog in the FFSETUP configurator

Reply 373 of 380, by FulValBot

User metadata
Rank Member
Rank
Member

There is a problem with 320x200 resolution... dgvoodoo2 detect it as a 640x400 (for example with hexen II if i try to use these resolution when i try to use integer scaling these can scale only 2x; and this is wrong with 320x200 resolution... 640x400 can scale to 1280x800 and that's normal with my 1080p display, but 320x200 why can scale only to 1280x800? And this is happening with 2x mode... So dgVoodoo2 is detecting 320x200 as a 640x400 resolution, and it's wrong)

Reply 374 of 380, by ZellSF

User metadata
Rank Oldbie
Rank
Oldbie

Forcing resolution to 320x200 seems to work around that, but eh... you really shouldn't be doing what you're suggesting in the first place. That 320x200 doesn't output 320x200 is of course a valid concern, but Hexen II corrects aspect ratio for 320x200, so it is a 4:3 resolution like it should be. The only valid integer scaling factors to maintain the correct aspect ratio is 1600x1200 (x:5, y:6) or 3200x2400 (if you have a 5K screen).

Unless of course you were intending to use dgVoodoo's option to force 4:3. But then the difference in scaling quality between a starting resolution of 320x200 (1600x1000) or 640x400 (1920x1200) should be rather minimal.

Reply 375 of 380, by FulValBot

User metadata
Rank Member
Rank
Member

I have only a 1080p screen, so no 1600x1200 here...

I have tried a custom 1600x1000 and a custom 1280x1000 but are both affected by a bad bilinear filter... (and 1600x1000 has a wrong aspect ratio)

When i select Max available Integer scale factor it scale only to 1280x800, this for both 320x200 and 640x400 (the same happen when i select 2x mode; i can't use 3x or 4x mode with 320x200 because with 3x i got a 1920x1200 and with 4x i got a 2560x1600, i don't know why...)

Reply 376 of 380, by ZellSF

User metadata
Rank Oldbie
Rank
Oldbie

Set dgVoodoo to force resolution to 320x200 first, then in the integer scale factor box type "x:4,y:5" (1280/1000 = 1.28 , not far away from 4/3 which is 1.33). That's the best integer scale you can do on a 1080p monitor:

integer.png
Filename
integer.png
File size
61.46 KiB
Views
138 views
File license
Fair use/fair dealing exception

Not sure why you would want to stick to integer scaling, I see no noticeable sharpness difference stretching it to fullscreen to get rid of black bars (this is with resampling set to Lanczos-3):

fullscreen.png
Filename
fullscreen.png
File size
1.04 MiB
Views
138 views
File license
Fair use/fair dealing exception

Also disable the deframer, I obviously didn't in the screenshot.

Edit: for reference, the "simple" way (set Scaling mode to "Stretched, 4:3 Aspect ratio" and set Integer scale factor to 3):

3x.png
Filename
3x.png
File size
264.23 KiB
Views
129 views
File license
Fair use/fair dealing exception

Reply 377 of 380, by FulValBot

User metadata
Rank Member
Rank
Member

Yes i can confirm that it works fine when i manually force that resolution and when i use x:4, y:5 as integer; i don't know why this is required... (but i think because 320x200 it's a 16:10 resolution, not a 4:3; if i try to select Max scale it scale to 1600x1000, so i have to manually use x:4, y:5)

Without integer scaling it can got some distorsions (or at least with some games, i don't know about Hexen II, i need more testing...)

A serious problem with all Pain Engine games (this at least with 640x480 resolution, that i can't recommend...) when i try to select a scaler (it works fine only with "Unspecified" but with that i got a very small screen; if i change it i got a very large incomplete screen and i can't use it... this happen also when i select a integer valor (also when "Unspecified" scaler is selected)

Last edited by FulValBot on 2021-02-28, 23:10. Edited 4 times in total.

Reply 379 of 380, by Dege

User metadata
Rank Oldbie
Rank
Oldbie

Isn't 320x200 is implemented with physical 640x400 with in-game renderer pixel duplication and that's why no difference between 320x200 and 640x400 with this game?

I tried 320x200 with 1920x1080 desktop resolution and it worked as expected.

109	2172.931380	17424	BOOST.EXE	[dgVoodoo] INFO: DirectDraw (006E0148)::SetDisplayMode: Display mode 320x200, 16 bit, 60 Hz is set but refresh rate is forced to 59Hz.
110 2172.931469 17424 BOOST.EXE [dgVoodoo] INFO: DirectDraw (006E0148)::SetDisplayMode: Integer factors applied for pixel multiplying are 5x5

You can test it with this ddraw demo and the dbg version of the ddraw.dll
http://www.pouet.net/prod.php?which=3709