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.
