Dear elishacloud, kindly ask for your help with the mouse input issue in Operation Flashpoint 1.96

[NATO2000]

@elishacloud Hello, it's been more than a year since we last contacted.

The D3DX tool you invented is amazing, used by a lot of people, and they all know your name

Thank you very much for your outstanding contribution to OFP

There are still some unresolved issues, can you find a way to add frame limit in D3DX?

Because the use of external software or RTSS for frame limiting, it will increase the game input lag and increase the threshold for some players

The game self-limits frames to achieve the lowest input latency. https://github.com/crosire/d3d8to9/issues/142

The second question, remember I once reported to you, there are some deadzone problems in OFP's mouse operation and aiming

By using the D3DX components you invented, turning off vsync, using a high-performance gaming mouse, and lowering the DPI to less than 200, you can significantly reduce the huge negative impact of deadzone, but the source of the problem has not been eliminated, and OFP still cannot achieve accurate mouse aiming and reaction speed like CS:GO.

I believe I consulted your posted input8 .dll, but it doesn't seem helpful for OFP

Let me describe the mouse features of OFP in detail:

The game engine seems to have a jumping phenomenon when processing mouse movements. A normal crosshair is a continuous tracking of movement

The mouse of OFP is normal when dragged at high speed, but when aiming accurately at low speed, it starts to freeze

If the CS:GO gaming mouse trajectory is a line (————————————————————————————) Then the OFP gaming mouse trajectory is more like （▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪ ）

Hope you will be interested in solving this problem

[mirh]

Did you try these? https://www.pcgamingwiki.com/wiki/Glossary:Mouse_acceleration#Issues_fixed

And if rivatuner isn't up to your tastest, try gedosato or specialk. But all of this seems pretty game specific.

[elishacloud]

The game engine seems to have a jumping phenomenon when processing mouse movements.

I used this program to solve the issue in other games: https://github.com/geeky/dinput8wrapper

Just use dinputto8 to redirect the game to use DInput8 and then use geeky's dinput8wrapper to fix the issue. It worked for me in Call to Power 2.

I would like to add this code to my dxwrapper program at some point. But I have too many things to do for now.

[elishacloud]

There are still some unresolved issues, can you find a way to add frame limit in D3DX?

For limiting the frame rate you can use dxwrapper to set the vsync rate to 60 FPS and then enable vsync. I know it is not a perfect solution, but I am not aware of a better solution without spinning the CPU waiting for a high performance timer, which is an unacceptable solution for me. I have experienced issues spinning the CPU on a number of games and I have not seen any issues using vsync.

[elishacloud]

I added an option to dxwrapper to allow custom per-frame FPS limiter that allows you to limit how long each frame will take. If you want to limit the frame rate to 240, for example, you can set LimitPerFrameFPS = 240.

Note: This uses a high performance timer and spins the CPU. This will reduce each frame to take a minimum of (1000 / 240 = 4ms) 4 milliseconds.

[mirh]

If the complaint is input lag, then it would seem strange that your 30 lines of fairly vanilla code could do already better than unwinder's work (especially if OP had also tried scanline sync too). For this reason I had recommended SK (which has latency sync) or gedosato (which has predictive capping).

p.s. btw Kal decided (for reasons I ignore, maybe just execution speed?) to switch to rdstc directly like last month

[elishacloud]

If the complaint is input lag, then it would seem strange that your 30 lines of fairly vanilla code could do already better than unwinder's work (especially if OP had also tried scanline sync too).

Both RTSS and vsync can cause lag. From everything I have read, RTSS causes one frame of lag. That will not happen with my solution. Also, vsync can cause lag because no matter when your frame is ready it has to wait for the next vertical blank before it can draw the frame. My solution does not need to wait for the next vertical blank and still draws the frame immediately. Instead there is a slight delay after the frame is drawn, which is more similar to how the game worked on older computers, which is what this game was made for and where it had no lag.

Furthermore, the solution I put in causes the delay to only be added if needed. If the frame has already taken a lot of time then no delay would be added. So the longer frames will have less delay added and the shorter frames will have more delay added. This helps normalize the frames to make them closer to the same amount of time per frame (consistent framerate). This also helps to reduce lag.

Finally, my solution will use a "busy-wait loop to let some time pass" as is mentioned on this thread, which is better than using "a 'sleep' or 'thread wait' system call to kill some time".

I am not saying my solution is perfect. But it does not have the same issue as some of the other solutions and it should help to solve the issue.

One note is that vsync should probably be disabled with my solution and instead use ~either~ fullscreen window mode ~or DisableMaxWindowedMode~ to remove screen tearing, which will also reduce the lag.

Edit: dxwrapper also offers ~both~ fullscreen window mode ~and DisableMaxWindowedMode~ to remove screen tearing on Direct3D9 without adding lag (at least on Windows 10/11).

[elishacloud]

@NATO2000, here is a new build with the frame limiter. I also enabled D3d8to9, Dinputto8 and FullscreenWindowMode (to remove screen tearing). I set the LimitPerFrameFPS to 141, but you can change that as desired.

I also recommend you try geeky's dinput8wrapper with this. Part of the lag could be caused by DirectInput caused by high frequency mice.

Here is the testing build: dxwrapper.zip

Let me know how this works for you.

[NATO2000]

@NATO2000, here is a new build with the frame limiter. I also enabled D3d8to9, Dinputto8 and FullscreenWindowMode (to remove screen tearing). I set the LimitPerFrameFPS to 141, but you can change that as desired.

I also recommend you try geeky's dinput8wrapper with this. Part of the lag could be caused by DirectInput caused by high frequency mice.

Here is the testing build: dxwrapper.zip

Let me know how this works for you.

FPS frame limit working NOT fully success

IF I choose limit FPS to 30，it is worked

BUT if I choose limit FPS to 90，it is going to 60

I forced the vertical synchronization to be turned off in both the NVIDIA driver panel and dxwrapper. ini, but it did not take effect.

At this moment, a new bug occurred, and the game screen became very dark, as if the gamma value was very low. However, all the brightness and gamma settings in the game had no response, and I couldn't find any other way to adjust the brightness and color of the screen

At the same time, at 60FPS, the operation delay is very strong

The second issue is that I downloaded dinput8.dll, which was indeed loaded by the game engine but did not make any improvements to the game

I carefully observed and studied the trajectory of the mouse device in OFP, and I determined that this is the classic Deadzone problem. When the mouse is slightly moved, the crosshairs in the game have no response, and when the movement speed is slightly increased, the crosshairs in the game will reposition themselves through a slightly jumping posture

I feel that it seems necessary for you to pay attention to whether a certain parameter of the OFP game engine can be optimized to solve the mouse deadzone problem.

Also. The mouse issue with OFP has a long history, as it was when he was born, even since the Windows 98 era

[elishacloud]

BUT if I choose limit FPS to 90，it is going to 60 I forced the vertical synchronization to be turned off in both the NVIDIA driver panel and dxwrapper. ini, but it did not take effect.

Yes, this is probably because it is running in fullscreen windowed mode. Since it is running as a window the game will not show more FPS than the desktop is showing. However, the game is allowed to send more than 60 FPS, they just won't show all the frames, only 60FPS will be shown. In other words, there is no delay added to any of the APIs the game is calling. This allows the game to run at a higher FPS internally, while preventing screen tearing. You can disable this by disabling FullscreenWindowMode in dxwrapper.ini.

At the same time, at 60FPS, the operation delay is very strong

If 60FPS causes too much delay then you can adjust the LimitPerFrameFPS to a higher number. This way the game is not limited to 60FPS. You may not see the difference in the FPS counter, but the game should feel different if it is running internally at a higher FPS. Ultimately, how the game feels is the only important thing. Don't worry about what the FPS counter says. 😊

At this moment, a new bug occurred, and the game screen became very dark, as if the gamma value was very low.

This could be because of FullscreenWindowMode. Gamma control in Direct3D8/9 does not work when running as a window. If the game is using Direct3D gamma controls then windowed mode won't look right with this game.

The second issue is that I downloaded dinput8.dll, which was indeed loaded by the game engine but did not make any improvements to the game The mouse issue with OFP has a long history, as it was when he was born, even since the Windows 98 era

If the mouse issue is not caused by high frequency mice then it could be game specific. I would need to test and debug the game to see what is happening. Maybe the game ignores small movements. If that is the case than the best thing is to modify the game code to have it stop ignoring small movements.

[CookiePLMonster]

If the mouse issue is not caused by high frequency mice then it could be game specific. I would need to test and debug the game to see what is happening. Maybe the game ignores small movements. If that is the case than the best thing is to modify the game code to have it stop ignoring small movements.

I've seen at least one game treat an input buffer overflow as a failure, while it's not - it just hints there is more data to be processed. This is obviously more likely to happen with higher polling rates.

[NATO2000]

Hello, there has been a mouse issue with OFP since the beginning

Since the time of Windows 98, from the earliest scroll mouse to the later photoelectric mouse.

It is due to a flaw in the game engine itself.

I heard that in the early versions of OFP games, the game mouse was similar to mainstream FPS games such as Counter Strike and Thor Hammer

But when the final version of the game was officially released, it was strange that there was a low-speed movement malfunction.

However, it should be noted that the mouse engine issue in OFP games is relatively hidden and difficult to detect. inexperienced players only feel that mouse targeting is laborious, but it can still operate normally

[NATO2000]

BUT if I choose limit FPS to 90，it is going to 60 I forced the vertical synchronization to be turned off in both the NVIDIA driver panel and dxwrapper. ini, but it did not take effect.

Yes, this is probably because it is running in fullscreen windowed mode. Since it is running as a window the game will not show more FPS than the desktop is showing. However, the game is allowed to send more than 60 FPS, they just won't show all the frames, only 60FPS will be shown. In other words, there is no delay added to any of the APIs the game is calling. This allows the game to run at a higher FPS internally, while preventing screen tearing. You can disable this by disabling FullscreenWindowMode in dxwrapper.ini.

At the same time, at 60FPS, the operation delay is very strong

If 60FPS causes too much delay then you can adjust the LimitPerFrameFPS to a higher number. This way the game is not limited to 60FPS. You may not see the difference in the FPS counter, but the game should feel different if it is running internally at a higher FPS. Ultimately, how the game feels is the only important thing. Don't worry about what the FPS counter says. 😊

At this moment, a new bug occurred, and the game screen became very dark, as if the gamma value was very low.

This could be because of FullscreenWindowMode. Gamma control in Direct3D8/9 does not work when running as a window. If the game is using Direct3D gamma controls then windowed mode won't look right with this game.

The second issue is that I downloaded dinput8.dll, which was indeed loaded by the game engine but did not make any improvements to the game The mouse issue with OFP has a long history, as it was when he was born, even since the Windows 98 era

If the mouse issue is not caused by high frequency mice then it could be game specific. I would need to test and debug the game to see what is happening. Maybe the game ignores small movements. If that is the case than the best thing is to modify the game code to have it stop ignoring small movements.

Yes，Let's focus on the mouse issue, which is the most critical one.

Do you need game engine files?

Do you need download link？

[NATO2000]

BUT if I choose limit FPS to 90，it is going to 60 I forced the vertical synchronization to be turned off in both the NVIDIA driver panel and dxwrapper. ini, but it did not take effect.

Yes, this is probably because it is running in fullscreen windowed mode. Since it is running as a window the game will not show more FPS than the desktop is showing. However, the game is allowed to send more than 60 FPS, they just won't show all the frames, only 60FPS will be shown. In other words, there is no delay added to any of the APIs the game is calling. This allows the game to run at a higher FPS internally, while preventing screen tearing. You can disable this by disabling FullscreenWindowMode in dxwrapper.ini.

At the same time, at 60FPS, the operation delay is very strong

If 60FPS causes too much delay then you can adjust the LimitPerFrameFPS to a higher number. This way the game is not limited to 60FPS. You may not see the difference in the FPS counter, but the game should feel different if it is running internally at a higher FPS. Ultimately, how the game feels is the only important thing. Don't worry about what the FPS counter says. 😊

At this moment, a new bug occurred, and the game screen became very dark, as if the gamma value was very low.

This could be because of FullscreenWindowMode. Gamma control in Direct3D8/9 does not work when running as a window. If the game is using Direct3D gamma controls then windowed mode won't look right with this game.

The second issue is that I downloaded dinput8.dll, which was indeed loaded by the game engine but did not make any improvements to the game The mouse issue with OFP has a long history, as it was when he was born, even since the Windows 98 era

If the mouse issue is not caused by high frequency mice then it could be game specific. I would need to test and debug the game to see what is happening. Maybe the game ignores small movements. If that is the case than the best thing is to modify the game code to have it stop ignoring small movements.

Major news! Big news!

I am excited to report a significant discovery to you.

Among OFP enthusiasts, some developed the 2.01 version of the exe client 5 years ago (unofficial. The official version is 1.99)

This client was not originally a novelty, and its upgrade instructions never mentioned any issues related to improving mouse accuracy.

However, just tonight, I unexpectedly discovered that this 2.01 exe game executable program has a high mouse accuracy!

Through repeated testing, I have successfully observed that the mouse accuracy of version 2.01 is exactly twice that of the official versions 1.99 and 1.96

Twice!

I was shocked, which means that the mouse accuracy issue of Flashpoint Operation is salvageable!

Unfortunately, despite the high mouse movement accuracy of version 2.01, there are still lingering deadzone issues

I believe you can solve it!

If you need a download address for the game and 2.01MOD, please let me know and I will send it to your email or provide a download link

[elishacloud]

I just added some features to my dxwrapper project that may help with this:

1. FixHighFrequencyMouse
2. DeviceLookupCacheTime

Enabling FixHighFrequencyMouse will help with a number of issues, including cases where the games frame rate is too slow or the mouse input speed is too fast. It also helps if the game does not correctly support DirectInput's buffer overflow code.

Setting DeviceLookupCacheTime to a larger number helps with games that try and enumerate the attached devices too often, leading to shuttering and other input slowdowns.

Try this update: dxwrapper.zip

[Joshhhuaaa]

Hi @elishacloud, sorry if this is a little off-topic from OFP's particular mouse input issue, but I've been looking into issues with high polling rate mice on other older games because I recently got a mouse that only supports 1000/2000/4000/8000Hz in its firmware.

Some Unreal Engine 1-2 games, particularly Splinter Cell games in my case, have worse mouse input when going above 125Hz. Technically, the engine samples the mouse at 120Hz (MouseSamplingTime=0.008333), but 125Hz is close enough to not cause any issues.

In Splinter Cell's case, you can't just adjust the sampling time, as far as I know. However, I've heard that games like Unreal Tournament 2004 can easily change this value to something like MouseSamplingRate=0.001 (1/1000Hz = 0.001), which improves the game's mouse performance.

What does the current FixHighFrequencyMouse actually do? Unfortunately, when I tried it, it didn't seem to fix my particular high polling issue. I was wondering if it is possible to trick the game into "downsampling" the mouse input so it receives input every 8ms, mimicking a 125Hz mouse. Thanks.

[elishacloud]

The code I added does a few things:

1. It ensures that all of the DirectInput buffer is read on each request so that the buffer gets cleared.
2. It always return DI_OK if successful. The native DirectInput could return S_FALSE which some games read as a failure.
3. It merges all the mouse movement buffers together to reduce the buffer and prevent mouse movement delays.
4. It caches the list of devices because some games will query too often and cause stuttering. See the "How This Works" section of this page here for more details on this.

I am not completely sure how to slow down the mouse frequency. I am not aware of any DirectInput function that can do that. However, I wonder if the game uses the event notification feature of DirectInput. Maybe DirectInput is triggering an event too often? I could add a buffer there and see if that helps.

BTW: about your question here:

There are still some unresolved issues, can you find a way to add frame limit in D3DX?

Yes, I did add a frame limiter to dxwrapper. It supports any float number, so for example you could put the frame limiter to 59.97.

[NATO2000]

The code I added does a few things:

1. It ensures that all of the DirectInput buffer is read on each request so that the buffer gets cleared.
2. It always return DI_OK if successful. The native DirectInput could return S_FALSE which some games read as a failure.
3. It merges all the mouse movement buffers together to reduce the buffer and prevent mouse movement delays.
4. It caches the list of devices because some games will query too often and cause stuttering. See the "How This Works" section of this page here for more details on this.

I am not completely sure how to slow down the mouse frequency. I am not aware of any DirectInput function that can do that. However, I wonder if the game uses the event notification feature of DirectInput. Maybe DirectInput is triggering an event too often? I could add a buffer there and see if that helps.

BTW: about your question here:

There are still some unresolved issues, can you find a way to add frame limit in D3DX?

Yes, I did add a frame limiter to dxwrapper. It supports any float number, so for example you could put the frame limiter to 59.97.

Hi，@elishacloud Regarding the mouse issue in Flashpoint, a friend named foie in the CWA channel on Discord made a minor modification to flashpoint.exe (he likely modified a string of hexadecimal code), and then a miracle happened - the mouse movement precision became very high (but still not comparable to traditional FPS games). However, the problem was not completely resolved. After setting the in-game mouse sensitivity in Flashpoint to the lowest setting, the in-game mouse cursor (including actual combat scenes) would still not move unless the mouse was moved with a significant amplitude and speed. This is a typical deadzone issue. Since foie believes that there is not much point in continuing to research the mouse (he is more interested in improving the frame rate stability in large battles), he is not willing to continue development. I can report the part of the changes he made to you. If you are interested, can you try to completely eliminate the deadzone?

[elishacloud]

Ok, try this update. I saw a similar issue with another game called Uprising 2. I put a change in that doubles the mouse movement speed and seems to have fixed the issue. I wonder if Flashpoint has the same issue?

dxwrapper.zip

[NATO2000]

@elishacloud FlashpointResistanceOriginal.zip No, it didn't work. It seems that there is an issue with the OFP exe file itself, and it may require "surgery" on the game's exe. This is the information I am reporting to you.

[NATO2000]

Ok, try this update. I saw a similar issue with another game called Uprising 2. I put a change in that doubles the mouse movement speed and seems to have fixed the issue. I wonder if Flashpoint has the same issue?

dxwrapper.zip

Foie — 2024/01/19 01:00 Version 1.99 It is an original file from Steam, not compiled. Only two 16-bit words have been changed in the file, nothing more:

[NATO2000]

Ok, try this update. I saw a similar issue with another game called Uprising 2. I put a change in that doubles the mouse movement speed and seems to have fixed the issue. I wonder if Flashpoint has the same issue?

dxwrapper.zip

Your D3DX hacked component has become a household name within the Flashpoint community. Some players have even gone so far as to say that this tool has saved a game that was on the verge of being abandoned due to new-era systems and hardware. We are very grateful for the immense contributions you have already made (perhaps one day in the future, DX8toDX12 may also be needed?). The mouse control issue is one of the oldest and most persistent problems in OFP. If it could be completely solved, it would truly benefit players around the world.

[elishacloud]

perhaps one day in the future, DX8toDX12 may also be needed?

There is already something like that in the dxwrapper build I gave you. If you enable the following options it will run the game in DX12 mode:

• d3d8to9
• ForceDirect3D9On12

[NATO2000]

perhaps one day in the future, DX8toDX12 may also be needed?

There is already something like that in the dxwrapper build I gave you. If you enable the following options it will run the game in DX12 mode:

• d3d8to9
• ForceDirect3D9On12 [d3d9] AnisotropicFiltering = 0 AntiAliasing = 0 EnableVSync = 0 ForceVsyncMode = 0 OverrideRefreshRate = 0 LimitPerFrameFPS = 0 EnableWindowMode = 0 WindowModeBorder = 0 SetInitialWindowPosition = 0 InitialWindowPositionLeft = 0 InitialWindowPositionTop = 0 FullscreenWindowMode = 0 ForceExclusiveFullscreen = 0 ForceMixedVertexProcessing = 0 ForceSystemMemVertexCache = 0 SetSwapEffectShim = 0 DisableMaxWindowedMode = 0 ForceDirect3D9On12 = 0 GraphicsHybridAdapter = 0

Oh, I see!

this ForceDirect3D9On12 is D8 to D9 then To D12? Am I correct?

DX12 Graphic Card with gain more FPS when ForceDirect3D9On12 is on?

And if there a version ForceDirect3D9On11 for DX11 users?

OFP D3DX Wrapper Tool.zip

OFP D3DX Wrapper Tool use D3DX.INI. not "dxwrapper.ini "

I believe you may need make a update about D3DX Wrapper Tool?

[elishacloud]

I just realized that I enable only the dinputto8 but this game may be using DirectInput8. If so then you would need to enable EnableDinput8Wrapper. I created a new build that adds a "padding" feature. This will allow you to customize the mouse movement better.

There are two features you can use here:

1. MouseMovementFactor - This is a float number that lets you slow down or speed up your mouse movement. Setting it to 2.0 will increase the mouse movement. Setting it to 0.5 will slow it down.
2. MouseMovementPadding - This is an arbitrary number that you can set to tell the game that the mouse has moved a little bit extra to help overcome the "dead zone" issue. Basically, if you set this to the same value as the dead zone then the dead zone issue should disappear. You can kind of think about this as acceleration. This number should probably be less than 20. I would start around 5 and then move up from there. Try different numbers until you get one that works for you.

Note: these settings will only work with DirectInput devices. If the game is not using DirectInput here then it will not help. Also, both of these features require FixHighFrequencyMouse. They won't work unless that feature is enabled.

Here is the new build: dxwrapper.zip

[elishacloud]

this ForceDirect3D9On12 is D8 to D9 then To D12? Am I correct?

d3d8to9 gets the game to DX9 and ForceDirect3D9On12 goes from DX9 to DX12. Once the game has been converted to DX9 then all the DX9 features I created will work on it. It does not matter if the game started on an older DX version.

DX12 Graphic Card with gain more FPS when ForceDirect3D9On12 is on?

It depends on the game and many factors. You can always try it and find out. I have seen it improve performance on some games. Keep in mind that D3D9On12 is created and maintained by Microsoft. So if there are issues using it then probably only they can fix it. Though it seems pretty stable for DX8 and DX9 games. It has some issues for older games.

I believe you may need make a update about D3DX Wrapper Tool?

I have been considering making a new release of dxwrapper. However, I don't have the means to do a full test of it at this time. Normally I test several hundred games before release.

[NATO2000]

I just realized that I enable only the dinputto8 but this game may be using DirectInput8. If so then you would need to enable EnableDinput8Wrapper. I created a new build that adds a "padding" feature. This will allow you to customize the mouse movement better.

There are two features you can use here:

1. MouseMovementFactor - This is a float number that lets you slow down or speed up your mouse movement. Setting it to 2.0 will increase the mouse movement. Setting it to 0.5 will slow it down.
2. MouseMovementPadding - This is an arbitrary number that you can set to tell the game that the mouse has moved a little bit extra to help overcome the "dead zone" issue. Basically, if you set this to the same value as the dead zone then the dead zone issue should disappear. You can kind of think about this as acceleration. This number should probably be less than 20. I would start around 5 and then move up from there. Try different numbers until you get one that works for you.

Note: these settings will only work with DirectInput devices. If the game is not using DirectInput here then it will not help. Also, both of these features require FixHighFrequencyMouse. They won't work unless that feature is enabled.

Here is the new build: dxwrapper.zip

I need dinput8.dll+dxwrapper.zip to get correct test，it is correct？ Do I need d3d8.dll?

[elishacloud]

You can use any stub that works with the game. Since this is a Direct3D8 game using the d3d8.dll stub is probably best.

Note: all stubs work with all versions of dxwrapper so you don't need to switch out the stub. Just switching out dxwrapper will work, as the old stub will be able to load a new version of dxwrapper.

BTW: after testing this with Uprising 2, which sounds like the same problem as Flashpoint, you may want to set the following:

[Compatibility]
Dinputto8                  = 1
EnableDinput8Wrapper       = 1

[dinput8]
FixHighFrequencyMouse      = 1
MouseMovementFactor        = 0.5
MouseMovementPadding       = 1

I have attached a new dxwrapper with the d3d8 stub and the settings already to go: dxwrapper.zip

[NATO2000]

this ForceDirect3D9On12 is D8 to D9 then To D12? Am I correct?

d3d8to9 gets the game to DX9 and ForceDirect3D9On12 goes from DX9 to DX12. Once the game has been converted to DX9 then all the DX9 features I created will work on it. It does not matter if the game started on an older DX version.

DX12 Graphic Card with gain more FPS when ForceDirect3D9On12 is on?

It depends on the game and many factors. You can always try it and find out. I have seen it improve performance on some games. Keep in mind that D3D9On12 is created and maintained by Microsoft. So if there are issues using it then probably only they can fix it. Though it seems pretty stable for DX8 and DX9 games. It has some issues for older games.

I believe you may need make a update about D3DX Wrapper Tool?

I have been considering making a new release of dxwrapper. However, I don't have the means to do a full test of it at this time. Normally I test several hundred games before release.

I use dinput8.dll+dxwrapper.ini+dxwrapper.dll

MouseMovementFactor = 5.0 MouseMovementPadding = 20 （5.0 and 20 just a test for now）

and the deadzone are 50% less much！

The mouse pointer in the flashpoint，still no movement when mouse moving with little slow speed

I don't know If we make more achievements BUG： the enter in the numberpad area，were confused/mess with big enter key the Num Enter key was set to switch for 3rd view，now it is as same as Enter key now

and alt+F4 can shutdown game directly，now it‘s Functional failure

In addition, I would like to ask if the "padding" function mentioned in the current method will cause the mouse pointer accuracy to decrease?

(For example, because we have deceived the game engine, the mouse's ability to accurately locate has decreased.)

[elishacloud]

Try disabling DeviceLookupCacheTime. Maybe that setting does not work well with this game.

In addition, I would like to ask if the "padding" function mentioned in the current method will cause the mouse pointer accuracy to decrease?

If you are able to set the "padding" to the exact number that the game is using for "dead zone" then there should not be any decrease in accuracy. Basically you are just bypassing or skipping the dead zone and having the game directly read the mouse movement.

still no movement when mouse moving with very very slow speed

This probably means the dead zone is still too small? That seems like a pretty large dead zone, though. But you can set it to any value that works. If you set it too large then the tiniest movement on the mouse will move it across the screen,

I would also try reducing the MouseMovementFactor. I think that 5.0 may be a bit too large and cause the mouse to move too fast. Keep in mind that MouseMovementFactor should not be used to reduce the dead zone, just to speed up or slow down the mouse speed.

(For example, because we have deceived the game engine, the mouse's ability to accurately locate has decreased.)

I don't know what was changed in the game so I cannot really comment on this.

Edit: You can tell when MouseMovementFactor and MouseMovementPadding are both correct because you should be able to move the mouse a single pixels at a time and the movement speed should be at the desired speed. Keep adjusting the values until it gets to that point.

[NATO2000]

this ForceDirect3D9On12 is D8 to D9 then To D12? Am I correct?

d3d8to9 gets the game to DX9 and ForceDirect3D9On12 goes from DX9 to DX12. Once the game has been converted to DX9 then all the DX9 features I created will work on it. It does not matter if the game started on an older DX version.

DX12 Graphic Card with gain more FPS when ForceDirect3D9On12 is on?

It depends on the game and many factors. You can always try it and find out. I have seen it improve performance on some games. Keep in mind that D3D9On12 is created and maintained by Microsoft. So if there are issues using it then probably only they can fix it. Though it seems pretty stable for DX8 and DX9 games. It has some issues for older games.

I believe you may need make a update about D3DX Wrapper Tool?

I have been considering making a new release of dxwrapper. However, I don't have the means to do a full test of it at this time. Normally I test several hundred games before release.

Oooooooooooooooooooooh！

I use dinput8.dll+dxwrapper.ini+dxwrapper.dll

MouseMovementFactor = 5.0 MouseMovementPadding = 20 （5.0 and 20 just a test for now）

and the deadzone are less much！

The mouse pointer in the flashpoint，still no movement when mouse moving with very very slow speed but I believe it is OK

BUG： the enter in the numberpad area，were confused/mess with big enter key the Num Enter key was set to switch for 3rd view，now it is as same as Enter key now

Try disabling DeviceLookupCacheTime. Maybe that setting does not work well with this game.

In addition, I would like to ask if the "padding" function mentioned in the current method will cause the mouse pointer accuracy to decrease?

If you are able to set the "padding" to the exact number that the game is using for "dead zone" then there should not be any decrease in accuracy. Basically you are just bypassing or skipping the dead zone and having the game directly read the mouse movement.

still no movement when mouse moving with very very slow speed

This probably means the dead zone is still too small? That seems like a pretty large dead zone, though. But you can set it to any value that works. If you set it too large then the tiniest movement on the mouse will move it across the screen,

I would also try reducing the MouseMovementFactor. I think that 5.0 may be a bit too large and cause the mouse to move too fast. Keep in mind that MouseMovementFactor should not be used to reduce the dead zone, just to speed up or slow down the mouse speed.

(For example, because we have deceived the game engine, the mouse's ability to accurately locate has decreased.)

I don't know what was changed in the game so I cannot really comment on this.

Edit: You can tell when MouseMovementFactor and MouseMovementPadding are both correct because you should be able to move the mouse a single pixels at a time and the movement speed should be at the desired speed. Keep adjusting the values until it gets to that point.

**I noticed that our conversations on GitHub don't seem to be updated in real time. I need to wait a while to see your replies. I have updated my description, you can take a look. At the moment, I have set both MouseMovementFactor values to 50.0, but they still cannot completely eliminate the deadzone. However, compared to before the fix, the deadzone has been weakened by 50%.

BUG： the enter in the numberpad area，were confused/mess with big enter key the Num Enter key was set to switch for 3rd view，now it is as same as Enter key now

and alt+F4 can shutdown game directly，now it‘s Functional failure**

[Joshhhuaaa]

I just realized that I enable only the dinputto8 but this game may be using DirectInput8. If so then you would need to enable EnableDinput8Wrapper. I created a new build that adds a "padding" feature. This will allow you to customize the mouse movement better.

@elishacloud Oh wow, I completely overlooked that setting when testing my game earlier. I wasn't noticing any difference, and that was why. I'm also testing some DX8 games with DirectInput8.

[Compatibility]
Dinputto8                  = 1
EnableDinput8Wrapper       = 1

[dinput8]
FixHighFrequencyMouse      = 1

When using the config above, I get much better results at 1000/2000/4000/8000Hz. I think 1000Hz might actually be perfect. Typically, the sensitivity gets slower and slower the higher the polling rate in my game. I believe this fix makes it have faster sensitivity than even 125Hz used to, which is not a problem but interesting.

I'm noticing a problem with 2000/4000/8000Hz, which might be an issue at 1000Hz, but it's too hard to notice yet. The issue gets progressively worse at higher polling rates. There is an occasional stutter when moving the mouse. Here is a video of some examples. At the start, I show how the mouse is barely usable in the default game and how well your fix works. At the end, I show the stutter problem.

The video shows 8000Hz as its the most obvious example of stuttering, but I can trigger it at 2000Hz sometimes. I'm unsure if it's possible at 1000Hz yet. If 1000Hz doesn't have this problem, then honestly this is already a great workaround! 2000/4000/8000Hz are pretty unnecessary, and even newer game engines struggle with them, so I won't be surprised if it's something related to this game being on a 20+ year old engine.

[elishacloud]

@Joshhhuaaa,

I think 1000Hz might actually be perfect.

Great. It sounds like I am getting there.

I'm noticing a problem with 2000/4000/8000Hz, which might be an issue at 1000Hz, but it's too hard to notice yet. The issue gets progressively worse at higher polling rates.

I am not completely sure what is happening, or even if it is something I can fix. I cannot reproduce the same issue. It's possible that the issue is because the buffer on DirectInput reached the end and the mouse movements are lost because of that. I increased the buffer size and made some other changes to try to prevent buffer overflow.

Try this update and see if it helps: dxwrapper.zip

[elishacloud]

@NATO2000,

I have set both MouseMovementFactor values to 50.0, but they still cannot completely eliminate the deadzone.

At that factor you should be able to move the mouse slightly and it should shoot across the screen. I wonder if you are using an old build before I added the MouseMovementPadding?

the enter in the numberpad area，were confused/mess with big enter key the Num Enter key was set to switch for 3rd view，now it is as same as Enter key now

The changes I did are hard coded to mice only. Are you sure this is related to my changes? I don't have a numberpad to test with at the moment. Try with the latest build and try enabling and disabling FixHighFrequencyMouse and let me know if the issue goes away when FixHighFrequencyMouse is disabled but still exists when FixHighFrequencyMouse is enabled.

Here is the update: dxwrapper.zip

[Joshhhuaaa]

@elishacloud

I just tried the updated one, but I didn't notice an improvement. However, I did discover some things about the issue. It's possible to trigger this kind of "stutter" at 1000Hz, and I noticed it gets worse the lower the framerate, which might provide some clues.

The video example was all recorded at 30 FPS as I typically play the game at that because minor things tied to the FPS can break. However, I tested 60-90 FPS and the issue is much less of an issue even for 8000Hz polling rate. And then I tried 15 FPS, and it became a bigger problem for 1000Hz.

I'm not sure if the game is actually stuttering but rather my mouse input is just being ignored for a millisecond then comes back.

I was also interested in applying this fix to the sequel of the game I was originally testing, which shares the polling issue and was released a year later. This sequel runs on the same Unreal Engine 2 but was upgraded from DirectX8 to DirectX9. For some reason, when the game receives any mouse input with dxwrapper hooked, it essentially freezes like this until I stop moving the mouse. Do you have any idea why that might be? If you're interested in looking into it, I have an "enhanced" build of the game available for download here.

[elishacloud]

For some reason, when the game receives any mouse input with dxwrapper hooked, it essentially freezes like this until I stop moving the mouse.

What do you mean by "dxwrapper hooked"? Have you tried disabling all dxwrapper features? Is there a specific feature that causes this issue?

[Joshhhuaaa]

For some reason, when the game receives any mouse input with dxwrapper hooked, it essentially freezes like this until I stop moving the mouse.

What do you mean by "dxwrapper hooked"? Have you tried disabling all dxwrapper features? Is there a specific feature that causes this issue?

I was using the same dxwrapper.dll/dxwrapper.ini that you've included with your update build an hour ago. I was using d3d9.dll as the stub. These were the only options enabled and the game was freezing like that.

Dinputto8                  = 1
EnableDinput8Wrapper       = 1
FixHighFrequencyMouse      = 1

Disabling FixHighFrequencyMouse fixed the freezing, so it's related to that. I want to use FixHighFrequencyMouse for my 1000Hz polling, but I’m not sure why it’s freezing for this particular game.

[elishacloud]

it essentially freezes until I stop moving the mouse.

BTW: I can see the same thing on Call to Power 2. But it has nothing to do with dxwrapper because the same thing happens without dxwrapper.

I did discover some things about the issue. It's possible to trigger this kind of "stutter" at 1000Hz, and I noticed it gets worse the lower the framerate, which might provide some clues.

Yes, that sounds like a buffer issue. The higher the Hz or the lower the FPS the more buffer is required to hold the data.

I'm not sure if the game is actually stuttering but rather my mouse input is just being ignored for a millisecond then comes back.

Again, this sounds like a buffering issue. Once the buffer is full then the rest of the mouse inputs are ignored.

I made another build. This one has a much larger buffer, it removes the thread locks (not safe) and it adds some extra debug logging.

Here is the testing build: dxwrapper.zip

[Joshhhuaaa]

BTW: I can see the same thing on Call to Power 2. But it has nothing to do with dxwrapper because the same thing happens without dxwrapper.

In Splinter Cell: Double Agent's multiplayer, the high polling rate doesn't cause the game to freeze naturally like Call to Power 2. This issue only happens when FixHighFrequencyMouse is enabled. Splinter Cell: Chaos Theory's multiplayer, the game we were originally looking at has no problem with FixHighFrequencyMouse, it works fine except for the buffer issue.

I made another build. This one has a much larger buffer, it removes the thread locks (not safe) and it adds some extra debug logging.

This build continues to have the buffer issue, increasing the frame rate of the game seems to lessen the issue again.

Here is a log for Chaos Theory's buffer issue, if it helps at all: dxwrapper-scct_versus.log

And here's a log for Double Agent's mouse freezing the game: dxwrapper-scda_online.log

[elishacloud]

Thanks for the logs they help. There is definitely not a buffer issue here. There was no buffer overflows in either log. Actually, I did not see anything wrong. But this did help me.

I rewrote the entire function and added some logs to time the activities. On some of the games I tested with I am seeing the call to DirectInput to get the mouse data sometimes returns slowly. I am not sure if there is anything I can do about that.

Here is a new build to test, with extra logging: dxwrapper.zip

[Joshhhuaaa]

Hey, here are the logs for Chaos Theory with that new build: dxwrapper-scct_versus.log

It seems that Double Agent's issue got fixed, the game is no longer freezing when moving the mouse. dxwrapper-scda_online.log

Both games seem to have the "stutter" / "dropout" issue at 30 FPS at least. I usually only play Double Agent at 60 FPS so it's not much of a problem. Chaos Theory's 30 FPS matters because the host of the online sessions typically have to play at 30 to prevent any issues with the clients.

Thanks for taking the time to help, I appreciate it

[elishacloud]

All of those logs came back perfect. Every call took less than 1ms, as it should, at least from the logs. Can you confirm that you saw the stutter issue with game play from these logs? Because I don't see any sign of stuttering from the logs.

One thing you could try is to reduce the mouse speed in dxwrapper by setting the MouseMovementFactor to a fractional number, like 0.5 or 0.75.

Also, I did make some minor changes, I don't think it will solve the issue but just to make sure you are using the latest: dxwrapper.zip

[Joshhhuaaa]

For the Chaos Theory log I sent, there was definitely some stuttering going on. The Double Agent log I sent didn't seem to have any because I was at 60 FPS, but when going to 30 FPS, I began noticing it.

Double Agent at 30 FPS with stuttering issue on latest version: dxwrapper-scda_online.log

The log doesn't seem to pick up anything different than the previous one though.

[NATO2000]

You can use any stub that works with the game. Since this is a Direct3D8 game using the d3d8.dll stub is probably best.

Note: all stubs work with all versions of dxwrapper so you don't need to switch out the stub. Just switching out dxwrapper will work, as the old stub will be able to load a new version of dxwrapper.

BTW: after testing this with Uprising 2, which sounds like the same problem as Flashpoint, you may want to set the following:

[Compatibility]
Dinputto8                  = 1
EnableDinput8Wrapper       = 1

[dinput8]
FixHighFrequencyMouse      = 1
MouseMovementFactor        = 0.5
MouseMovementPadding       = 1

I have attached a new dxwrapper with the d3d8 stub and the settings already to go: dxwrapper.zip

@elishacloud

@NATO2000,

I have set both MouseMovementFactor values to 50.0, but they still cannot completely eliminate the deadzone.

At that factor you should be able to move the mouse slightly and it should shoot across the screen. I wonder if you are using an old build before I added the MouseMovementPadding?

the enter in the numberpad area，were confused/mess with big enter key the Num Enter key was set to switch for 3rd view，now it is as same as Enter key now

The changes I did are hard coded to mice only. Are you sure this is related to my changes? I don't have a numberpad to test with at the moment. Try with the latest build and try enabling and disabling FixHighFrequencyMouse and let me know if the issue goes away when FixHighFrequencyMouse is disabled but still exists when FixHighFrequencyMouse is enabled.

Here is the update: dxwrapper.zip

@elishacloud Hello，I think I need report to you

Summary of Progress and Request for D3DX Integration

Due to the utilization of various versions and the integration of the original D3DX tools, the current setup has become somewhat intricate. To provide a clearer overview, I'll summarize the current file deployment:

D3dx.ini Dxwrapper.ini d3d8.dll (modified d3d8tod9) d3dx.dll dinput8.dll dxwrapper.dll + d3d8.dll Keybind Issues and Deadzone Mitigation

The keybind issue stems from dinput8.dll. When placed in the root directory, dinput8.dll leads to key interference and malfunction. The previous Dxwrapper.zip you provided did not include dinput8.dll, thus avoiding this issue.

Currently, the latest dxwrapper.dll + dinput8.dll can effectively reduce deadzone by 50%, but it cannot completely eliminate it. Similarly, dxwrapper.dll + d3d8.dll also achieves 50% deadzone reduction but falls short of complete elimination.

Conflicting Files and D3DX Limitations

Due to a conflict between the provided dxwrapper.dll + d3d8.dll and the original D3DX's d3d8.dll (modified d3d8tod9), further testing is hindered. Additionally, the outdated D3DX version and the lack of D9onD12 support in D3DX.INI limit further development.

Proposal for D3DX Integration

I propose a new D3DX version, 2.0, with the following features:

D3D8toD9 + D9toD12

Compatibility with D3DX.dll (preserving original DXDLL functionality)

Stable FPS frame rate limiting

Stable windowed gaming functionality

Deadzone solution

Bug fix: Enable D3DX components without affecting game recording by Windows 10's built-in recording software (OBS compatibility is maintained)

(Optional) Bug fix for DXDLL: Address potential crashes when minimizing the game (an issue originating from DXDLL, not D3DX) when this bug shows up，users will receive this hint：

I kindly request your consideration and effort in integrating these features into a new D3DX version. Your expertise will be invaluable in achieving a comprehensive solution for the outlined challenges.

D3DX（D3DX is a component that you created in 2022.） OFP D3DX Wrapper Tool.zip

[elishacloud]

@Joshhhuaaa, I am not sure if this will help or not but I updated the build and created a thread that pulls for mouse input at 125Hz and caches the output in a buffer. Then when the game queries for mouse input I can return the cached data. I am hoping this make for more stable input at any FPS.

Here is the updated build: dxwrapper.zip

[Joshhhuaaa]

@Joshhhuaaa, I am not sure if this will help or not but I updated the build and created a thread that pulls for mouse input at 125Hz and caches the output in a buffer. Then when the game queries for mouse input I can return the cached data. I am hoping this make for more stable input at any FPS.

Here is the updated build: dxwrapper.zip

@elishacloud This is much worse. It’s not the same problem anymore, there's no stuttering, however when I tested with 8000Hz to see a worst case scenario, there's so much input lag that I can flick my mouse and then noticeably watch the game finish the flick even after the mouse has already stopped. Using 1000Hz didn’t have as severe as a input lag problem but strangely the mouse was slow again like the default game. I assume when the "stutter" happens, it is replaced with the input lag issue I’m seeing at 8000Hz. So, it’s probably not a good solution.

[elishacloud]

@Joshhhuaaa,

It’s not the same problem anymore, there's no stuttering,

Since this does not stutter I am pretty sure that the stuttering issue is coming from DirectInput.

This is much worse. [...] Using 1000Hz didn’t have as severe as a input lag problem but strangely the mouse was slow again like the default game.

Ok, too bad. I could increase the pulling speed to something more than 125Hz, but I don't think that is the issue. Let's try a couple more things.

RawInput:

I created a build that can support using raw input rather than DirectInput for mouse activity. It does not work on all games but you can test this and see if it helps: dxwrapper_raw_input.zip

ThreadPriority

I created a build that uses threading but sets the priority to high to ensure that even when the system is busy the mouse data is still able to be retrieved: dxwrapper_high_priority.zip

[Joshhhuaaa]

RawInput:

I created a build that can support using raw input rather than DirectInput for mouse activity. It does not work on all games but you can test this and see if it helps: dxwrapper_raw_input.zip

Stuttering seems to happen on this raw input build as well. I would say this build feels very similar to the previous build before you tried caching the output, other than mouse side buttons such as Mouse4 and Mouse5 seem to be disabled in raw input.

ThreadPriority

I created a build that uses threading but sets the priority to high to ensure that even when the system is busy the mouse data is still able to be retrieved: dxwrapper_high_priority.zip

This build feels like the caching build, it has this sluggish/input lag feel and sensitivity feels a bit slow like the default game's behavior with high polling.

[elishacloud]

@NATO2000,

d3d8.dll (modified d3d8tod9)

What exactly is modified on d3d8to9? I have that module included in dxwrapper so if you could use the dxwrapper version it could simplify this.

The keybind issue stems from dinput8.dll. When placed in the root directory, dinput8.dll leads to key interference and malfunction. The previous Dxwrapper.zip you provided did not include dinput8.dll, thus avoiding this issue.

You don't need to use the dinput8.dll as a stub. Dxwrapper only needs a single stub. If you are already using d3d8.dll as a stub then you don't need dinput8.dll.

Due to a conflict between the provided dxwrapper.dll + d3d8.dll and the original D3DX's d3d8.dll (modified d3d8tod9), further testing is hindered.

How about if you use d3d9.dll as the stub to load dxwrapper? d3d8to9 loads the local version of d3d9.dll, so you don't need to use d3d8.dll as a stub.

Proposal for D3DX Integration

The d3dx tool is a copy dxwrapper. Did I put custom code in there? I think you can just replace all the functionality with dxwrapper instead. The current version is newer. Just set the same options in dxwrapper.ini that you had set in d3dx.ini.

[elishacloud]

Stuttering seems to happen on this raw input build as well. I would say this build feels very similar to the previous build before you tried caching the output,

Ok, then I am not sure there is much I can do. I think it is system or game related. I am not seeing that on any of my games.

other than mouse side buttons such as Mouse4 and Mouse5 seem to be disabled in raw input.

Yeah, the raw input build only uses the first 3 mouse buttons.

This build feels like the caching build, it has this sluggish/input lag feel and sensitivity feels a bit slow like the default game's behavior with high polling.

Ok, then scratch that. I think the previous build (before the threading) was the best. I am not sure what else can be done here. BTW: have you tried other things? Like changing resolutions, graphics modes, etc. to see if anything else can help?

[Joshhhuaaa]

There isn't too much to mess around with this game's graphics/resolutions, I gave it a shot and no differences.

I'm just going to blame the game/engine for the strange behavior, it's probably not possible to fix entirely without looking into the game itself. I assume you'd be able to replicate the issue on your own system for these particular games, but yeah most games probably won't ever experience it.

Nonetheless, thanks for taking the time again, the fix works well at 60 FPS so for Double Agent, I think I'll be using the fix for that game, the stutters are only noticeable at 30 FPS. It is frustrating because despite the stuttering problem, it is so close to perfection for Chaos Theory as well now.