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**