search

elishacloud / dxwrapper

Fixes compatibility issues with older games running on Windows 10/11 by wrapping DirectX dlls. Also allows loading custom libraries with the file extension .asi into game processes.
zlib License
1.15k stars 82 forks source link

Age of Empires Dd7to9 #177

Closed 9xtiger closed 1 year ago

9xtiger commented 1 year ago

All are perfect but the color of name player when i show the timeline changed from black to white. This make me disconect when i play with other player. Im using dd7to9 Age of empires. big thanks to you

elishacloud commented 1 year ago

Unfortunately, I don't have a copy of the game. This is a game I wanted to test with for a while but could not find a demo copy of it online. When you say it disconnects you from the other players, can you give me more details? What makes you think that it is dxwrapper that is causing you to get disconnected?

mirh commented 1 year ago

https://www.gamepressure.com/download.asp?ID=81940 https://download.cnet.com/Age-of-Empires/3000-7483_4-10013361.html https://www.moddb.com/games/age-of-empires/downloads/age-of-empires-trial-version

elishacloud commented 1 year ago

Thanks! I wonder if I can test the multiplayer issues with this demo?

elishacloud commented 1 year ago

All are perfect but the color of name player when i show the timeline changed from black to white.

Ok, I can reproduce this issue with the trial edition. I have seen this kind of issue before. Let me see if I can fix it.

elishacloud commented 1 year ago

It looks like this game is using a combination of GDI and DirectDraw to create the graphics. Direct3D9 does not play nicely with GDI when in exclusive fullscreen mode. Try enabling the FullscreenWindowMode option. That should solve this issue.

9xtiger commented 1 year ago

Unfortunately, I don't have a copy of the game. This is a game I wanted to test with for a while but could not find a demo copy of it online. When you say it disconnects you from the other players, can you give me more details? What makes you think that it is dxwrapper that is causing you to get disconnected? https://www.mediafire.com/file/fuaxaakhar6cc0d/game-de-che-1.zip/file I still cant play with other player. I think this dxwraper is casusing me to get Disconnected because it only disconnected when i use dxwraper. If i delete that, i can play it nomally. It only disconnect when i or other player click to show timeline - the one that differrent between us. "You were disconnected because of a sync error" - when i click the timeline show.

9xtiger commented 1 year ago

I just tired more by use 2 computers. It will be fine if 2 of players use dxwraper. It will disconnect when 1 of 2 players not use dxwraper. So if i want play online. Another player need to use dxwraper too.

mirh commented 1 year ago

Direct3D9 does not play nicely with GDI

IIRC from when I was banging my head on some OGL woe the DWM is more of a lingering variable than what the underlying api is per se, but don't quote me.

elishacloud commented 1 year ago

The issue is that starting with newer builds of Windows 10 Direct3D9 got changed and this change caused GDI to not be visible when Direct3D9 is in exclusive fullscreen mode. I guess that is probabby ok since few Direct3D9 games use both Direct3D9 and GDI. However, many DirectDraw games use GDI and even some Direct3D8 games, see here. Converting the game to windowed fullscreen mode fixes that issue.

I don't know if anyone has found a better solution for this. However, I have considered converting the GDI calls into Direct3D9 to solve this issue. But I have not looked into how much work that will be.

elishacloud commented 1 year ago

I just tired more by use 2 computers. It will be fine if 2 of players use dxwraper. It will disconnect when 1 of 2 players not use dxwraper.

This is weird. I am not sure what could be causing it. I did add a delay in writing to the screen with dxwrapper. Each write is not seen on screen until the next write happens. I disabled this delay to see if it is the cause.

Also, I noticed that Age of Empires uses DirectPlay for multiplayer games. dxwrapper hooks the CoCreateInstance() which is used by DirectDraw and DirectPlay. It is not needed for this game so I disabled that hook also.

Anyways, here is a new build for you to try. Let me know if this works: dxwrapper.zip

FunkyFr3sh commented 1 year ago

I had out of sync errors with cnc-ddraw before with one game, the solution was D3DCREATE_FPU_PRESERVE ... Maybe give that a try as well. I haven't heard about any issues with AOE in combination with cnc-ddraw though (I don't use this flag by default, do you?)

elishacloud commented 1 year ago

Interesting. Thanks for the tip! I only use D3DCREATE_FPU_PRESERVE when requested specifically by the game. See here and here.

I just checked on this game and it sets DDSCL_FPUSETUP which means that D3DCREATE_FPU_PRESERVE shouldn't be set. However, I have a bug where I create the Direct3D9 device with D3DCREATE_FPU_PRESERVE enabled for this game, even though I shouldn't. I'll need to fix that.

mirh commented 1 year ago

with newer builds of Windows 10 Direct3D9 got changed and this change caused GDI to not be visible when Direct3D9 is in exclusive fullscreen mode

Are you sure the problem isn't the fact that exclusive fullscreen isn't really much that anymore actually? "Dumb windowed" mode could just be enjoying the advantage of still retaining bitblt presentation.

elishacloud commented 1 year ago

Are you sure the problem isn't the fact that exclusive fullscreen isn't really much that anymore actually?

The issue only happens on Direct3D9. The issue happens when you set the Windowed parameter of the D3DPRESENT_PARAMETERS to FALSE. If you do the same thing on Direct3D8 it works fine (no issue). Disabling fullscreen optimizations has no effect on this issue. There is no way in Direct3D9 for GDI graphics to be seen when Windowed is set to FALSE, as far as I have seen.

I would love to know if anyone has a fix for this because it affects lots of games when using dd7to9 and some games when using d3d8to9.

BTW: Setting Windowed to FALSE in D3DPRESENT_PARAMETERS is what's known as exclusive fullscreen mode. And whether it is a thing to not, the option still exists and still works. However, it just has this bug in it with GDI graphics.

elishacloud commented 1 year ago

@9xtiger, I fixed an issue based on @FunkyFr3sh's comments. Can you check this one out and see if it fixes the issue: dxwrapper.zip

mirh commented 1 year ago

The issue only happens on Direct3D9.

I mean.. Not like GDI was ever supposed/gonna to work with newer d3d, right?

Disabling fullscreen optimizations has no effect on this issue.

Mhhh, I see. But.. even put aside that I seem to remember there was at least some version of W10 that used to not give a damn about that checkbox, I'd exhort you to double check with presentmon the actual window mode that you are getting. EDIT: more like every one

BTW: Setting Windowed to FALSE in D3DPRESENT_PARAMETERS is what's known as exclusive fullscreen mode.

Except not really, as I just sighed yesterday in #59? There isn't actually any way (well, out of the box at least) to get d3d8 exclusive fullscreen on an updated windows. The dll that is shipped simply doesn't even have the corresponding functions anymore.

elishacloud commented 1 year ago

I mean.. Not like GDI was ever supposed/gonna to work with newer d3d, right?

Where is it documented that this is not going to work? It worked with d3d9 on every version of Windows (Including Windows 10) until the Windows 10 April Update. And it still works with d3d8 on every version of Windows.

But.. even put aside that I seem to remember there was at least some version of W10 that used to not give a damn about that checkbox

I just checked on the latest released version of Windows 10 and disabling fullscreen optimizations has no effect on this issue.

There isn't actually any way (well, out of the box at least) to get d3d8 exclusive fullscreen on an updated windows.

I understand. I know it is not true exclusive mode. But anyways that is what you are telling DirectX you want and that is the mode that is broken with GDI.

elishacloud commented 1 year ago

Where is it documented that this is not going to work?

I found it. The documentation is right here says that the "flip" model does not support "multiple different APIs producing contents, which all layer together into the same HWND ... An example of this would be using D3D to draw a window background, and then GDI to draw something on top".

This implies that the "Blt" model does support that (i.e. multiple different APIs producing contents, which all layer together into the same HWND). Dxwrapper's dd7to9 is using the Blt model so this should be supported. This issue with GDI and d3d9 not working together is clearly a bug in Windows 10.

9xtiger commented 1 year ago

Anyways, here is a new build for you to try. Let me know if this works: dxwrapper.zip

This one worked for me. Thank you very much. Its amazing!

@9xtiger, I fixed an issue based on @FunkyFr3sh's comments. Can you check this one out and see if it fixes the issue: dxwrapper.zip

And this 1 not worked. it got error in mutiplayer game. Mouse and Keyboard stuck and lagging.

FunkyFr3sh commented 1 year ago

Are you sure the problem isn't the fact that exclusive fullscreen isn't really much that anymore actually?

The issue only happens on Direct3D9. The issue happens when you set the Windowed parameter of the D3DPRESENT_PARAMETERS to FALSE. If you do the same thing on Direct3D8 it works fine (no issue). Disabling fullscreen optimizations has no effect on this issue. There is no way in Direct3D9 for GDI graphics to be seen when Windowed is set to FALSE, as far as I have seen.

I would love to know if anyone has a fix for this because it affects lots of games when using dd7to9 and some games when using d3d8to9.

BTW: Setting Windowed to FALSE in D3DPRESENT_PARAMETERS is what's known as exclusive fullscreen mode. And whether it is a thing to not, the option still exists and still works. However, it just has this bug in it with GDI graphics.

Doesn't "Direct3D9EnableMaximizedWindowedModeShim" in d3d9.dll fix the issue? I'm not too sure though, I always just use opengl for these games in cnc-ddraw

elishacloud commented 1 year ago

Doesn't "Direct3D9EnableMaximizedWindowedModeShim" in d3d9.dll fix the issue? I'm not too sure though, I always just use opengl for these games in cnc-ddraw

No. I tried disabling and enabling Direct3D9EnableMaximizedWindowedModeShim in d3d9.dll as well as disabling and enabling fullscreen optimizations and all combinations of those. Still does not work. I don't have an OpenGL option, instead I use fullscreen windowed mode to solve this issue.

elishacloud commented 1 year ago

@9xtiger, thanks for testing this. Can you test this one and let me know if this works also?

This one just removes the delay in writing to the screen with dxwrapper to see if this is the issue. I want to narrow down the issue to a single thing.

Here is the update: dxwrapper.zip

mirh commented 1 year ago

Where is it documented that this is not going to work? It worked with d3d9 on every version of Windows (Including Windows 10)

I said newer directx, not newer windows... Though I'll grant I was kind of misremembering the chart and its implication Glad that you eventually found something anyway, lol.

until the Windows 10 April Update.

Mhh, is this documented somewhere? Which april are we talking about?

Dxwrapper's dd7to9 is using the Blt model so this should be supported.

Well, that's what you ask. What you get isn't necessairly the same thing. That's why I told you to actually check the presentmode with presentmon.

Doesn't "Direct3D9EnableMaximizedWindowedModeShim" in d3d9.dll fix the issue?

I was going to tell you DXMaximizedWindowedMode just made fullscreen into borderless windowed (so it wouldn't have influenced the presentation mode).. but that was indeed created and promoted exactly to address cases like this.

instead I use fullscreen windowed mode to solve this issue.

I mean, that's kinda what maximized windowed mode should be AFAIK... I'm quite uneasy by this implication.

9xtiger commented 1 year ago

This one just removes the delay in writing to the screen with dxwrapper to see if this is the issue. I want to narrow down the issue to a single thing.

Here is the update: dxwrapper.zip

This one make disconnect. I want to note that if I turn "FullscreenWindowMode" on, the game will not be as smooth as when I turn it off, even though my device is i7-13700k

elishacloud commented 1 year ago

@9xtiger, thanks for checking. When you say it is not as smooth with "FullscreenWindowMode" on, is that true for the build that worked above or is it just this build that is not as smooth?

Can you test with this one? I hope this works: dxwrapper.zip

9xtiger commented 1 year ago

Can you test with this one? I hope this works: dxwrapper.zip

This one work well.

@9xtiger, thanks for checking. When you say it is not as smooth with "FullscreenWindowMode" on, is that true for the build that worked above or is it just this build that is not as smooth?

It getting not smooth for all of version dxwrapper. So i turned it off. Black and white name is not big problem with me. Thank you.

elishacloud commented 1 year ago

Thanks @9xtiger for checking on this. I added a fix for this issue into the project.

elishacloud commented 1 year ago

Mhh, is this documented somewhere? Which april are we talking about?

This issue was first introduced with Windows 10 Fall Creators Edition. I am not aware of any documentation stating this issue. As I showed with the previous documentation this should work (not just on Direct3D9 but also on DirectX10 and DirectX11). It is clearly a bug in Windows, AFAIK. BTW: I think we are rehashing some of the comments from the thread here.

I mean, that's kinda what maximized windowed mode should be AFAIK... I'm quite uneasy by this implication.

Yes, me too. Especially since the reports we are seeing is that maximized windowed mode isn't as smooth game play as exclusive fullscreen mode is.

elishacloud commented 1 year ago

Closing this issue as complete.

mirh commented 1 year ago

This issue was first introduced with Windows 10 Fall Creators Edition

I would recommend you to use build numbers next time, for better peace/clarity/easiness of mind (even because April isn't in Autumn.. is it?) With this said, I'm afraid every W10 release is basically its one special mix of quirks. 1709 specifically was kind of the "peak flip mode", since they allegedly decided (there and only there) to also upgrade windowed borderless to it. And there was hardly a working opt-out (see also my EDIT above). The subsequent Windows versions shouldn't have been that forceful, but you can bet the details are still devilish.

BTW: I think we are rehashing some of the comments from the thread https://github.com/crosire/d3d8to9/issues/61.

Good memory, that kind of interop talk was exactly what I had in mind. Though I'll grant my "brainstorming pitches" there sounds really stupid in hindsight... But now I really feel like I have quite the bombshell that I could drop for that, when I have time. ^^

Especially since the reports we are seeing is that maximized windowed mode isn't as smooth game play as exclusive fullscreen mode is.

... I believe last month I was going to tell you that you can't really be sure of which mode you are actually in, unless you actively check for it (and AFAIK that in turns could only mean using ETW to query Windows).

But does https://github.com/elishacloud/dxwrapper/compare/238d6db00bf3bcf4f539820edfeabd4ed3a2fe7c...91cb50669e06f78c956581b793096c580d83eb40 mean that, indeed, all our observation above were misplaced? And that maximized windowed never actually engaged?

elishacloud commented 1 year ago

I would recommend you to use build numbers next time

Agreed.

you can't really be sure of which mode you are actually in

True. But in this case it does not really matter. As long as you request exclusive fullscreen access by an app then this issue exists, whether or not you are actually in the mode doesn't matter. There must be some way to solve this, but I have not figured it out yet.

But does 238d6db...91cb506 mean that, indeed, all our observation above were misplaced? And that maximized windowed never actually engaged?

Yes, the setting in dxwrapper was broken, and maximized windowed never actually engaged. However, I have since fixed the issue and tested both with dxwrapper and with Windows compatibility mode. The issue still happens whether maximized windowed is engaged or not.

elishacloud commented 6 months ago

I found a real fix for this issue by calling Direct3D9SetSwapEffectUpgradeShim() with parameter of 0. This changes the present mode to "Hardware: Legacy Flip", which is the same mode that DirectDraw and Direct3D8 is using. For more details on the issue see comments here.

Here is the fix for this in dxwrapper: dxwrapper.zip

Edit: updated the build, last one had a bug in Windows 11.