[Backend] KeyDown is not working for DirectInput games - other than writing individual ANSI characters

[Turbine1991]

Currently for some games when you try to press a key such as Enter or ~ for console, it does not go though. However writing any letter does.

[JohnPeel]

This could be the game intercepting something, no idea, @MerlijnWajer ideas?

[ghost]

@Turbine1991: Can you provide a list of games which you tried? Which games accept alphabetic (or alphanumeric) input, and which do not accept any input at all?

@Turbine1991, @JohnPeel, @MerlijnWajer: If a game chooses to bypass the normal desktop input messages and instead uses the DirectInput API and subscribes to WM_INPUT messages in preference to normal WM_* messages there is very little that can be done to correct the behavior you are experiencing. The game is ignoring typical keyboard events and using the API made for joysticks to access the keyboard as an input device.

That normal characters go through is very interesting and something I'm not sure can be explained solely by referencing the API. A possible solution is to put synthetic WM_INPUT events into the program's event queue. Any solution to this problem is very Windows-specific.

[Turbine1991]

No 3d game I've tried seems to work on Windows. Rust, Natural Selection 2, Android emulator AMIDuOS - for a game.

Everything SCAR divi fails to pass inputs to.

Usually it's mouse clicks, but a lot of the time even key board inputs fail. Some other macro utilities inputs work like autohotkey.

[ghost]

@Turbine1991: See this.

It looks like AutoHotkey simulates WM_INPUT events or otherwise places itself in the event queue at a lower level than allowed by the top level Windows API. Searching hotkey.cpp for SendPlay pointed me towards some keywords that looked like AutoHotkey might be using SetWindowsHookEx to hook WH_KEYBOARD_LL and WH_MOUSE_LL but I can't find any source indicating that is the case. Spending more time reading the code or talking to the developers is probably the best option going forward.

[Turbine1991]

@R030t1

How hard would it be to implement it so we can test its effectiveness? Even as an alternative click function - to ensure compatibility in any regressive cases.

[ghost]

@Turbine1991: Implementation might be two weeks of off and on work with testing however actually figuring out the Windows API regarding how input is handled might take me another month. There are also some issues getting everything built around and for Simba ported to FPC 3.0.0 and Lazarus 1.6.4.

I'll be working on this fairly consistently and might get code committed but don't hold your breath. If you have actually found discrepancies in how programs treat input (e.g. letters work but some symbols and command keys don't) I need to know which programs as it provides valuable information about the Windows API.

There's a lot more going on under the surface than is readily apparent. I might need to create a suite of test programs just to make sure whatever gets added works properly.

[Turbine1991]

Sometimes it feels like Pascal is more trouble than it's worth. Considering how dead Pascal/Delphi is these days.

I've just tried NS2 using keypress, sendkeys and clickmouse - only sendkeys worked. I could write a string, but I could not write it using keypress or keydown functions.

[Edit]
I've just tried the free game, Fallout Shelter - it has the same issue.

The thing is, I don't know of any non-browser game which actually works.

[slackydev]

@Turbine1991 it's really not the programming language that is the issue. This is all backend stuff, just calls to the Windows/XLib API, more or less. We are by no means being limited in capabilities by Simba being written in FPC. Further more looking at popularity statistics for object pascal, it's by no means out of the picture, being in the top-10 @ TIOBE.
With the latest RC of Simba you can also do calls to native functions, meaning you might be able to work it out in a script itself, not that it makes it any simpler, because as I said this is all Windows API stuff.