Add an additional disclaimer to README regarding DirectX 8 differences on the new Windows versions, GPU drivers, etc.

[HerMajestyDrMona]

As discussed in https://github.com/crosire/d3d8to9/issues/142#issuecomment-1109202254 Windows 10 / 11 is ignoring some of the game requests. For example, it results in disabled V-Sync in the DirectX 8 mode, while d3d8to9 actually follows the game requests. It may result in the false first-impression of performance with d3d8to9. I added some information about these differences to the README file, and also mentioned the amazing dxwrapper which could be useful for players who are trying to tweak older games, not only convert the API calls. Some English tweaks or shortening would be welcome. I apologize if mentioning the other project is not allowed, I just thought it's a good solution to prevent creating many game-specific issues in this project, which are usually already resolved in dxwrapper.

[mirh]

You shouldn't really blame Windows before having tested different versions in a VM with the same driver. Anyway W10 did indeed introduce breaking changes but the problem is likely a very specific one.

It's not like that even if you put the game in fullscreen mode, d3d8 doesn't v-sync anymore. It is that d3d8 no longer has a real fullscreen mode to begin with (you can verify this in PresentMon). And be it either the DWM not allowing what would amount to double syncronization, or dx never being meant to sync non-exclusively (I would have bet on the former, but it turns out there always was debate) that cannot become your frame limiter then.

On top of that, yes there can be other meddling. Windowed G-SYNC being the most famous one: when a non-fullscreen window is in-focus it will be synced to the monitor refresh rate (of note that games can still change this, even if Windows doesn't give them total control of the screen). Somewhat similarly IIRC (even though this really isn't going to apply to an old game) the Composed: Flip presentation mode should "force sync" you to integer multiples of the display frequency. Everything has a name and a surname eventually if you dig enough.

[HerMajestyDrMona]

The goal of this description change was to reduce the number of reported issues about the "FPS lock" in d3d8to9. Although it's too early to judge, it seems like it actually helped with it.

Since Windows 10 / 11 actually doesn't present the d3d8 parameters in the form expected by d3d8 game developers, I think it's safe to say that it's in simple words ignoring them. It doesn't really matter if the breaking changes were documented or not, the final effect is the same. It's nothing really blaming in it, just stating a fact that is easily understandable by all users.

I agree that it's good to know the root cause of the problems differences, but at the end it doesn't change much, at least in this case.

Do you propose some changes to the description in order to mention that it's caused by the lack of the real fullscreen mode? Or these are just extra information that the initial pull request is missing?

[mirh]

The goal of this description change was to reduce the number of reported issues about the "FPS lock" in d3d8to9.

If an application asks for vsync, of course that request should be abided. I get that people don't care about who's whos, and I know not all games offer a v-sync option, but (assuming I'm right of course) having a disclaimer to explain how vsync even works is really lame.

Since Windows 10 / 11 actually doesn't present the d3d8 parameters in the form expected by d3d8 game developers

I don't know. If this is Windows\DWM covertly suppressing v-sync calls on every non-exclusive fullscreen window then that would be correct. But if this had always been the default/vanilla d3d behavior for windowed mode (even though not all games may have officially supported it, but that's on them to be stupid) then it is all one big misapprehension.

I agree that it's good to know the root cause of the problems differences, but at the end it doesn't change much, at least in this case.

It kinda does, because in that case recommending an older dll (or perhaps filling a feature request against dxwrapper), or just telling people to disable v-sync, would be the proper course of action.

Do you propose some changes to the description in order to mention that it's caused by the lack of the real fullscreen mode?

I'd recommend testing, because the information inferred with lots of charity from bug reports wasn't exactly clear and explicit :)

[HerMajestyDrMona]

I tested 2 or 3 games on VMs with older versions of Windows (XP and 7) in DirectX 8 mode, and I could not get more than 60 FPS on them. Empire Earth 2 for example has no switchable V-Sync option by default. This makes me assume that some games wanted V-Sync to be enabled by default. It didn't really matter back then, because hardware limitations made them run at much lower framerate.

In Windows 10 (I don't know if it started in some version or was this way since the beginning), DirectX 8 games (at least the ones I tested and the others that were reported by GitHub issues) run with more than 60 FPS by default (often 200+ since they're not very demanding). Enabling or disabling fullscreen optimizations had no effect on them.

Since d3d8to9 does an exact translation of d3d8 calls to d3d9, and makes games run with the limited FPS (V-Sync behavior), then it means that DX8 rendering behavior differs on modern version of Windows. This is probably because DX8 and older games are not really using the native API. They get converted using a similar thing to D3D9On12. I think NVIDIA indirectly mentions it on their support page.

It kinda does, because in that case recommending an older dll (or perhaps filling a feature request against dxwrapper), or just telling people to disable v-sync, would be the proper course of action.

I'm not sure if I understood it. Which older DLL? Was there some d3d8to9 version with the V-Sync forcefully disabled? Why recommending to disable the V-Sync, if d3d8to9 does the exact and correct translation? Such recommendations don't really fit the description page when it's d3d8to9 that is doing things correctly.

To be honest I think the current disclaimer is just fine. It is neutral, doesn't blame anything and is actually accurate to what everyone already knows about possible factors.

[mirh]

I tested 2 or 3 games on VMs with older versions of Windows (XP and 7) in DirectX 8 mode, and I could not get more than 60 FPS on them.

In windowed mode? Because that's kinda the big doubt. I think DxWnd, 3D-Analyze and D3DWindower should be able to force it even if ALT+ENTER doesn't work (otherwise you could try games that don't require external tools like Mafia, Syberia, UT2003 or BF2142).

This makes me assume that some games wanted V-Sync to be enabled by default.

Probably more like they never thought/cared for it (even the super expert devs working on GNOME had to be told why yes, it's not so easy and automatic for it to make sense)

It didn't really matter back then, because hardware limitations made them run at much lower framerate.

Even more if your hardware risks not to keep up with VBI, vsync isn't so desirable. It almost seems like you think v-sync is supposed to be about frame limiting...

In Windows 10 (I don't know if it started in some version or was this way since the beginning),

Avoiding real fullscreen is a trend that might have started in W8 already actually (the source just mentions ddraw tbf, but d3d8 might have been on the table too)

Enabling or disabling fullscreen optimizations had no effect on them.

If you read literally my first link you see that DXPrimaryEmulation -DisableMaxWindowedMode was the fix (before 1809). FSO would only apply to d3d9+, and whatever the result (Hardware: Independent Flip AFAICT) that shouldn't affect vsync.

They get converted using a similar thing to D3D9On12.

D3D9On12 is a legit UMD/DDI replacement driver (i.e. the driver that processes the 3d commands), it doesn't wrap the runtime. As far as the other applications know (also including the windowing system and whatnot) everything is still perfectly native.

I think NVIDIA indirectly mentions it on their support page.

That is just a consequence of microsoft never having implemented a "dispatching api" like for d3d9 and newer. And be it for technical or just economical worthiness reasons (after all, in 2015 even atom graphics should have been able to compete with 2003 gpus) nvidia didn't feel like furthering their own hybrid hackjob.

Which older DLL?

You really didn't check my links... did you? If you restore an older version of d3d8.dll (one that didn't have exclusive fullscreen removed completely) presumably that should address your concerns.

Why recommending to disable the V-Sync, if d3d8to9 does the exact and correct translation?

Mhh, good question, sorry. Maybe brainstorming got to much ahead of me and I started to rave about every kind of use case.

Such recommendations don't really fit the description page when it's d3d8to9 that is doing things correctly.

I mean, with the same scrupulous token then no disclaimer would be needed at all, isn't it? Anyway I don't really have a writing pitch atm, just doubt to sate.

[HerMajestyDrMona]

In windowed mode? Because that's kinda the big doubt. I think DxWnd, 3D-Analyze and D3DWindower should be able to force it even if ALT+ENTER doesn't work (otherwise you could try games that don't require external tools like Mafia, Syberia, UT2003 or BF2142).

I'm referring to the full screen mode. I don't remember the windowed one, since I wasn't even interested in testing it back then.

D3D9On12 is a legit UMD/DDI replacement driver (i.e. the driver that processes the 3d commands), it doesn't wrap the runtime. As far as the other applications know (also including the windowing system and whatnot) everything is still perfectly native.

D3D9On12 uses the native d3d9 calls, but obviously does a lot of "conversions" in order to render it using DirectX 12. It results in many issues, such as this one. It's especially problematic, because new Intel drivers for 12th Gen GPUs don't support DX9 natively at all, so D3D9On12 is forced. I assume that a similar, if not the same thing was done to DirectX 8 calls since the first version of Windows 10. This is why there are some little, thankfully mostly unnoticeable differences. It's just my theory. I don't have sources to confirm it as I'm personally very little interested in DirectX. I was forced by the nature to focus on it for the unofficial patch for my favorite game, but nothing else.

You really didn't check my links... did you? If you restore an older version of d3d8.dll (one that didn't have exclusive fullscreen removed completely) presumably that should address your concerns.

Sorry, I thought you were referring to d3d8.dll that comes with d3d8to9 and is somewhere in older GitHub releases. Using .dlls from older versions of Windows is usually not recommended, even though this one would probably work fine. I got a bit confused by it. You mentioned that this method could be recommended in d3d8to9 description? It didn't make much sense for me to promote workarounds for unrelated things, that additionally use the same name as the project output DLL. This could confuse usually inexperienced users a lot. I also don't know if dxwrapper could legally include this old .dll that comes with older versions of Windows. From what I remember redistribution of Windows DLLs is strictly forbidden. And the final problem is that this would actually guide to use the native DirectX 8 instead of d3d8to9 (?), which in 99.9% of situations is a bad idea since d3d8to9 fixes many compatibility issues and allows old games to be actually supported by the updated graphics drivers. So promoting a method not to use the project on it's own page would be a bit strange.

I mean, with the same scrupulous token then no disclaimer would be needed at all, isn't it?

Since d3d8to9 does things correctly, the disclaimer is not needed. However, based on reported issues about the worse performance, and questions about disabling the V-Sync, I think it's a good thing to have. Especially since it gives the opportunity to mention dxwrapper which allows ordinary users to change things they want without d3d8to9 code modification and compilation.

I understand your goal in posting a feedback to this. It's actually a good debate, but moves to a philosophical subject instead of the practical one. For ordinary users, it doesn't matter if new Windows versions use the fake fullscreen mode or not. This fake fullscreen mode is still named "fullscreen" in Windows. So for the end-user it just gives a bad impression that d3d8to9 made their game run slower, while it actually makes the game behave more like it would on the old version of Windows, which is the correct and expected way.

I apologize for using some potentially inaccurate words. It's not always easy to write thoughts on the "paper", especially with a non-native vocabulary.

[mirh]

I don't remember the windowed one, since I wasn't even interested in testing it back then.

My point was that it's actually very important to know, if not any for the wording of the note. And in fact I'm very dumb, because in the third page they indeed confirm my suspects (even though I'm still unsure if it's just automatically the fact of using windowed mode to forego v-sync, or rather the DWM).

It results in many issues, such as https://github.com/microsoft/D3D9On12/issues/57.

I know ( ͡° ͜ʖ ͡°) But that's still exactly what I told you (and fundamentally different from what you are thinking).. it's just a "mundane bug" in the 3d processing not really dissimilar from any that could happen with a "true native" driver. It's not really that I enjoy playing the terminology-nazi cop, but having banged my head for over a decade on fixing games "imprecision snowballing into FUD" is a scourge.

Back in topic, like.. you wouldn't blame "direct3d" if nvidia borked their old shadow projection matrix in their drivers. Conversely, you would blame d3d9 instead, if starting with Vista clip planes were busted all across the board.

because new Intel drivers for 12th Gen GPUs don't support DX9 natively at all

As Squall noted at the end of the thread, they do now (alternating with DXVK depending on the game)... Did you forget? Putting even aside that it's kind of sophistry to try to distinguish between "real hardware" DDIs and "virtual" ones (as if outputting "gpu bytecode" as opposed to "d3d12 calls" was different).

I assume that a similar, if not the same thing was done to DirectX 8 calls since the first version of Windows 10.

Come on man. You can't really sell (literally) d3d8_do(stuff){d3d9_do(stuff)} repeated for every single function, as the same of d3d8_do(stuff){reinvent_the_wheel_in_a_totally_different_api(stuff)}. For as much as we know (well, at least originally) it may even be they only uniquely shimmed the fullscreen behaviour.

I got a bit confused by it. You mentioned that this method could be recommended in d3d8to9 description?

Yes and no. Assuming such and such assumptions, "new d3d8.dll" (which here is a dll name that I always ever used for the official one Windows ships) is the cause of the differences. And in mentioning this fact in the note, "the method of using an older dll existing" would be automatically more or less implied.

Not that I really know a reason people shouldn't use d3d8to9 anyway, but still.

I also don't know if dxwrapper could legally include this old .dll that comes with older versions of Windows.

No, I meant it as in: dxwrapper takes care of restoring exclusive fullscreen behaviour into the new d3d8.dll (@elishacloud).

Since d3d8to9 does things correctly, the disclaimer is not needed.

Yesn't, this is kinda of an "ethical" dilemma. It all depends on whether the "contract" with the system you believe is being "signed", is about technically "v-sync itself" or just the practical promise that "tearing won't happen".

So for the end-user it just gives a bad impression that d3d8to9 made their game run slower, while it actually makes the game behave more like it would on the old version of Windows

I mean, did I already said that v-sync is pretty crappy and it shouldn't be relied on for "gaming frametimes" purposes? Going from the DWM-friendly DXMaximizedWindowedMode to good old legacy exclusive bitblt v-sync (despite being an upgrade in many compatibility aspects) could also still be argued to be a downgrade. Even though it's not further impossible to promote it to the flip model presentation and whatnot.

[HerMajestyDrMona]

As Squall noted at the end of the thread, they do now (alternating with DXVK depending on the game)... Did you forget?

No, their newest drivers simply don't fix the issue. I asked a few 12gen users to test it, and it didn't help in any case. I don't have a possibility to test it myself, and I will probably avoid Intel for the rest of my life. So I don't know if this "restored native support" is real or not.

[mirh]

No, their newest drivers simply don't fix the issue.

I mean, it could even be that their replacement driver has in its turn that bug. For as much as odd.

So I don't know if this "restored native support" is real or not.

As I said, you should stop to focus on what kind of "actual backend" a legitimate driver has (in fact, you may even argue supporting D3D9On12 is a super good thing, if not any just because it's at least open source). Though you have a point, that if the claim is "the original driver or DXVK has been restored" and then you still see the bug (even though neither of them assumedly experienced it) one of the premises must be wrong eventually.

... Anyway long story short the factors should be (underlining again that version delimitation should be cross-checked):

• every d3d8 windowed application always had D3DPRESENT_INTERVAL_DEFAULT(0) (and windowed fullscreen isn't new?)
• fast forward to W8, Direct3D8EnableMaximizedWindowedModeShim was added
• then W10 rtm turned it on by default
• 1607 fixed some supposed problem (with.. borders?)
• 1809 dropped any support for exclusive modes

[Squall-Leonhart]

The D3D8 vsync issue mentioned here is not a driver issue, its a runtime issue within the Windows 10/11 D3D8 dll caused by bad logic changes in order to enable FSO promotion.

No changes to the UMD would have counteracted this behavior because the D3D8 runtime is altering the behavior prior to the driver handling it at the UMD.

[mirh]

Yes, I had been trying to underline above the difference between the actual device driver, and the runtime (I should probably have referenced this though, rather than crosire shallowly using the former term for everything)... Anyway, this is nothing else than what @UCyborg reported already 4 years ago in the first link I posted (but I wouldn't exactly describe "removing the FSE code altogether" as "bad logic" tbh).