Fix XWING95/TIE95 keyboard input in bordered windowed mode or provide borderless "windowed" mode (was "DxWnd support")

[Danfun64]

As awesome as this is, it's annoying that it's stuck to full screen. I'd appreciate it if you found a way to get it to work under DxWnd, which can be found at https://sourceforge.net/projects/dxwnd/

Without the d3d11 wrapper, I'm able to use a windowed fullscreen mode. Unfortunately with my tests with X-Wing 95 and Tie Fighter 95, true windowed mode doesn't seem to work, but I am able to alt tab out of the window or get the cursor out of the window just fine. If you can get that at least working again, I'd really appreciate it. As it happens, it appears that new versions os XWAUCP and DSUCP come bundled with this by default, which makes it even more important for full compatibility.

[rdoeffinger]

Why do you need to use DxWnd? The wrapper doesn't use fullscreen mode at all, only borderless windowed mode, and in the config file you can change it to use bordered windowed mode and even specify an arbitrary desired size/resolution.

[Danfun64]

Actually, now that I tested it, bordered windowed mode runs just fine on XWA using only xwa_ddraw_d3d11, except for the mouse cursor wanting to go off the screen in the concourse menus.

Where using dxwnd is necessary is with X-Wing 95 and Tie Fighter 95, as the moment I alt-tab out of the game using windowed xwa_ddraw_d3d11 (which is necessary for fixing the window resolution with sizer4) keyboard input no longer works. Incidentally, there's a setting in DXWnd in the DirectX(2) menu called "Create a Desktop Win" which creates an actual window instead of a borderless fake windowed mode. With the "Create a Desktop Win" setting turned on, I get the error "Direct Input Keyboard Acquire FAILED", and so keyboard support stops working with the game immediately, thus I have to close it out.

Maybe instead of incorporating direct support for DxWnd, you can provide a borderless fake windowed option like DxWnd has, complete with the ability to set the position of the fake window in advance.

[bguthrie1]

This could be solved by the ddraw, but I've already solved it with a separate hook.

https://1drv.ms/u/s!AoEpIrw6LOkUjbZ6VxgzTcIc3fmWJQ

Place the files in the game directory. There is also config which allows you to freeze the game upon alt+tab if you wish.

[Danfun64]

The hook didn't make any difference with xwa_ddraw_d3d11 with either alt-tab setting.

Dxwnd with hook on breaks both mouse and keyboard, but I'm not getting any direct input failed errors anymore. The alt-tab setting also doesn't make any difference here.

[bguthrie1]

Does it work without Dxwnd? If it does, then that means Dxwnd is interfering or calling something in relation to the keyboard.

The way the hook works is that instead of calling a DI keyboard acquire (which is what the game does) is that it reinitializes the keyboard DI object. It also suppresses DI Keyboard errors. My theory is that the input buffers have a chance of getting corrupted after alt+tabbing, so reinitializing the device will restore the keyboard.

From what I can see about Dxwnd, it offers a ton of customization. Customization that would be a nightmare to build a dll around. Even more so, I see that there are options such as "Unaquire input devices on focus lost", which will absolutely interfere with the hook.

First, we don't even know anything about the customization you are using for Dxwnd. So any sort of troubleshooting isn't going to lead to anywhere. I also expect unpredictable results to occur using it inconjunction with Reimar's ddraw. Perhaps Reimar could implement my hook code into the ddraw, but it won't make a lick of difference if Dxwnd interferes with the devices themselves.

[Danfun64]

When I said "The hook didn't make any difference with xwa_ddraw_d3d11", I meant completely on its own with no Dxwnd whatsoever.

[bguthrie1]

Is this issue occurring in the concourse or In flight or both? My hook only fixes the issue in flight. But even still, if you're losing keyboard input after the first Alt+Tab then something (either a driver or some other application or dll) is interfering with DirectInput, which is how the game communicates with the keyboard.

[Danfun64]

I don't know about in flight, but it certainly occurs in the concourse, and if I didn't have a pre-existing pilot file there I would've been stuck.

[bguthrie1]

I can try to have my keyboard hook reinitialize the DirectInput keyboard (and mouse) object for the concourse if this issue is still occurring.

[bguthrie1]

I've updated my keyboard hook to respond if ALT+Tab is pressed in the concourse. It will reaquire the keyboard (and possibly the mouse).

https://1drv.ms/u/s!AoEpIrw6LOkUjbZ6VxgzTcIc3fmWJQ?e=DDlODY

You can close this Reimar if you wish. It shouldn't have to do anything with your ddraw at this point.

[rdoeffinger]

Ok, I am not really clear on the latest status, but I'll close for now. If there's something I should look into, reopen or (possible better) open a new issue.

[Danfun64]

Could you please reopen this? If I click out of the game or right click on the game's window, it still doesn't take keyboard input.

[bguthrie1]

So alt+tabbing back into the game does not restore keyboard input? Did you install my keyboard hook above?

[Danfun64]

It appears that alt-tab doesn't change whether it's the active window or not. All it seems to do is pause the game. The moment I actually change focus is when the game truly disconnects.

[Danfun64]

Just a reminder that this bug was never fixed on my end.