Question about the FullscreenWindowMode

[HerMajestyDrMona]

Hi.

I have a question about the FullscreenWindowMode in DX9 (using D8to9).

I noticed that sometimes in this mode, the Windows taskbar doesn't hide. I also noticed, that the game window will not minimize on ALT+TAB switching. I know that it's rather an expected behavior.

Some games that support the "Borderless fullscreen windowed mode" in their settings (e.g. awful example: League of Legends) can respond to ALT+TAB and don't have the visible taskbar problem. What is the difference? Were these games programmed to minimize the window on ALT+TAB, or they use some different mode than the one available in dxwrapper?

[mirh]

Pretty sure no game specifically addresses ALT+TAB.
You are probably experiencing some of the dozens possible interactions between windows compatibility shims, and fullscreen optimizations.
EDIT: ddraw may also play a role

[HerMajestyDrMona]

Thanks for the reply.

Seems like it was the other way around. The game I support (EE2) has some functions that are pausing the game window when it becomes inactive. There are also separate functions that are muting the audio when the window loses focus (even in the windowed mode). I fixed these issues with a new option that allows my injected DLL to modify game memory and fix these things when the game is in the windowed mode (and revers when it switches back to fullscreen on ALT+ENTER).

For now I also resigned from replacing d3d8to9 to dxwrapper, because I fixed the borderless windowed mode by the assembly myself. The game allows the windowed mode and switching between fullscreen and windowed mode with a hotkey. For the windowed mode I hijack the style and modify it to remove ~(WS_CAPTION | WS_THICKFRAME | WS_MINIMIZEBOX | WS_MAXIMIZEBOX | WS_SYSMENU). I was also able to support multiple displays by modifying the X, Y coordinates, depending on selected adapter window. In the past, I also made a hotkey that allows the mouse cursor to leave the game window (constrain cursor). So now, I'm finally satisfied how this game works on multiple monitors!

It's still tempting to migrate to dxwrapper for AnisotropicFiltering, ForceMixedVertexProcessing and other useful options, but I'm not sure if it's better for the performance and stability.

[mirh]

Oh, so that's why I seemed to remember you.
Alas the options from #111 still aren't doing a thing for me (putting aside I don't really think you'd need all that much of a bump for a 2005 RTS).
And TIL dxwrapper doesn't inherently use d3d8to9.

[HerMajestyDrMona]

Yeah, I detected that enabling ForceSystemMemVertexCache actually reduces performance a lot (huge FPS loss). Not sure about the ForceMixedVertexProcessing, since it doesn't make any difference to me. Maybe I'll better not touch options that are not needed.

I read the issue you linked, there was a discussion about the future ForceHardwareVertexProcessing option. Do you think the game by any chance uses the hardware vertex processing already?

[HerMajestyDrMona]

Nevermind, it seems like it's already using HARDWARE. I simply added a message box under else if (BehaviorFlags & D3DCREATE_HARDWARE_VERTEXPROCESSING) and it shows up :D

[elishacloud]

dxwrapper does not do anything special with the FullscreenWindowMode in DX9. Basically it just changes the following:

1. It changes the call into CreateDevice to tell DirectX to use windowed mode rather than fullscreen mode.
2. It updates the window style and location so that the window will appear in the correct size and location on the screen.
3. It changes the resolution of the system to match the resolution of the game.

Some games that support the "Borderless fullscreen windowed mode" in their settings (e.g. awful example: League of Legends) can respond to ALT+TAB and don't have the visible taskbar problem. What is the difference? Were these games programmed to minimize the window on ALT+TAB, or they use some different mode than the one available in dxwrapper?

dxwrapper does not do anything to handle this. I guess this may be the way the game works. More code would need to be added to solve this issue.

[elishacloud]

In DirectX9 displaying text could be done by this: https://github.com/apitrace/dxsdk/blob/master/Include/d3dx9effect.h

Edit: updated the link to the right one...

[HerMajestyDrMona]

Thanks. So this could be SetString, but it can't be found in d3d8to9? So maybe it's SetTexture? Either way, I think I wouldn't be able to workaround it. It seems to just be a bug in D3D9On12, and I bet they'll never fix it :D

[elishacloud]

These are done inside the d3dx9.dll file. You can check if this file is used. All of these calls (including SetString) ultimately call d3d9 functions, I believe. I just don't know which d3d9 functions they are translated into.

[HerMajestyDrMona]

@elishacloud If you get a chance, could you please take a look at apitraces which I posted here?: microsoft/D3D9On12#57 (comment) ? With your huge experience maybe you would notice something useful.

[HerMajestyDrMona]

Interesting. It seems like there might be something wrong in Direct3DDevice8::SetVertexShader -> hr = ProxyInterface->SetFVF(Handle) function. When I added Handle = D3DFVF_XYZ | D3DFVF_DIFFUSE | D3DFVF_TEX1; before it, then the fonts are not appearing even on the normal d3d8to9 version. I guess it's a good starting point.