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.
crosire/d3d8to9#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.

[Joshhhuaaa]

It is frustrating because despite the stuttering problem, it is so close to perfection for Chaos Theory as well now.

Yes, I feel the same way. I will have to test out these games myself and see if I can figure it out. Right now I just have my old laptop.

However, I had one last possible change. I doubt this will help but just in case. This basically also updates the timestamp and sequence number when merging the buffer entries: dxwrapper.zip

@elishacloud Yeah, unfortunately that didn't do the trick.

If you ever get the chance to test the games in the future, I have enhanced releases that you can use for testing:

Enhanced SCCT Versus - 30 FPS is commonly used in Chaos Theory due to 60 FPS causing issues so its higher priority. Also, most people care about this game getting fixed before Double Agent, it has more players. We do use dgVoodoo2 for this particular game to fix lighting and dsound.dll for EAX support, but I don't believe they are conflicting with the mouse.

Enhanced SCDA Online - Double Agent also has a stuttering issue at 30 FPS but most people play at 60 FPS anyways. Enhanced SCDA comes with a dinput8.dll stub for ASI patch currently, so make sure to use d3d9.dll for dxwrapper.

The games aren't particular demanding obviously being almost 20 years old, but I think you will need a 1000Hz+ polling mouse to be able to troubleshoot the issue yourself. 1000Hz doesn't have the issue too severely but if you move your mouse around for about 30 seconds or so, you'll begin noticing them. 8000Hz makes it very noticeable, almost every 5 seconds.

Thanks for the help, hopefully we'll figure it out sometime.

[elishacloud]

I am going to move this issue to dxwrapper, since it is related to that project.

[elishacloud]

This issue is now under dxwrapper.

[elishacloud]

@NATO2000, I went through the ticket and memory lane. I see the confusion. The d3dx.dll is just a renamed version of dxwrapper.dll and d3dx.ini is just a renamed version of dxwrapper.ini.

Here is what I suggest:

1. Delete dxwrapper and dinput8.dll from the package (at least the dinput8.dll stub that came with dxwrapper you can use a different dinput8 if you like)
2. Take note of all the settings in the d3dx.dll file (especially the WrapperMode = d3d8.dll setting, that needs to be set or the game won't even work).
3. Replace the d3dx files (dll and ini) with the dxwrapper files, renaming both dxwrapper files to d3dx.
4. In the new d3dx.ini set all the setings that you noted in step 2. You can also set other settings, like the FixHighFrequencyMouse or the MouseMovementPadding.

This will allow the new dxwrapper to replace the old d3dx files. This should give you all the functionality of the old d3dx but with the new functionality of the new dxwrapper.

Here is the latest dxwrapper fo you to use. I pre-enabled some of the settings for you: dxwrapper.zip

[elishacloud]

@Joshhhuaaa, I do have the GOG version of Splinter Cell. Can the same issue be repeated on this version?

I also tried downloading Enhanced SCCT Versus but the mouse is so choppy it is unplayable for me. Even in the starting menus the mouse just jumps around and it is hard to even get it over the right button to press. I tried forcing vsync to be off I tried using d3d8to9 instead of dgVoodoo2 I tried a few other things. I'm not sure if my laptop is too slow or if something else is happening.

[Joshhhuaaa]

@Joshhhuaaa, I do have the GOG version of Splinter Cell. Can the same issue be repeated on this version?

I also tried downloading Enhanced SCCT Versus but the mouse is so choppy it is unplayable for me. Even in the starting menus the mouse just jumps around and it is hard to even get it over the right button to press. I tried forcing vsync to be off I tried using d3d8to9 instead of dgVoodoo2 I tried a few other things. I'm not sure if my laptop is too slow or if something else is happening.

@elishacloud I just gave it a shot, and yeah, it is possible on the original Splinter Cell at 30 FPS with 1000 polling or higher. Splinter Cell 1 has a 200 FPS engine cap, so issues might not be noticeable when playing at that high of a framerate. To really expose the problem, just be sure to cap the FPS at 30.

The GOG version should come with 3 DLC missions at the bottom of the levels tab (already unlocked on new profiles), you probably want to load into Kola Cell so you can test immediately with no cutscenes/training mission forces you through some stuff before having control of your character. You can press "E" to draw your weapon which might make it easier to notice than third person. I would recommend lowering the in-game mouse sensitivity a bit as well just so you can flick your mouse easier to notice the stutter without the game doing constant spinning.

---

Edit: After testing some more, it seems the mouse stutters more often when I have keys pressed down, like holding W and A keys down for forward strafing while moving the mouse. Even a single key held down seems to do the trick as well, it can just be A or D without W. This seems to cause it to overload more easily.

[elishacloud]

it is possible on the original Splinter Cell at 30 FPS with 1000 polling or higher. Splinter Cell 1 has a 200 FPS engine cap

How do I set the game to 30 FPS? I don't see any options for that in the game's menu.

Edit: After testing some more, it seems the mouse stutters more often when I have keys pressed down, like holding W and A keys down for forward strafing while moving the mouse. Even a single key held down seems to do the trick as well, it can just be A or D without W. This seems to cause it to overload more easily.

Ok, that is interesting. DirectInput uses a sequential method to keep track of the key press order. I merged the mouse movement records and basically ignored the sequence number. However, the game may take advantage of the sequence number and when it sees things out of sequence then it drops the records or it is not able to handle it.

I made an update to try keep the sequence order. This will only merge records that have consecutive sequences.

Note: with this you may want/need to set the MouseMovementPadding to some number. One of the games I tested with drops inputs that are only an increment of 1. When the mouse has higher frequency then the chances the mouse movement is only 1 is much higher. By setting the padding we can ensure that the game always accepts the movement.

Here is the new build: dxwrapper.zip

[elishacloud]

Ok, I forced Splinter Cell to 30 FPS using the Nvidia control panel. I am using dxwrapper's built-in d3d8to9 feature and setting FixHighFrequencyMouse to 1 and MouseMovementPadding to 1. I am not seeing any issues on my laptop with the latest build.

Edit: I tried with 6400Hz mouse.

[Joshhhuaaa]

Your latest build somehow really slowed down the Y-axis movement on Enhanced SCCT Versus, it's basically unusable on that game. I didn't experience that issue on Splinter Cell 1 but the stuttering does happen still.

How do I set the game to 30 FPS? I don't see any options for that in the game's menu.

The game doesn't have a built-in FPS cap option, I was using Nvidia Control Panel as well.

Edit: I tried with 6400Hz mouse.

I've never heard of a 6400Hz polling rate mouse, are you talking about DPI? That shouldn't matter as far as I know, but I use 1600 DPI. I had a few friends with 1000Hz mice also experience the stutter just to be sure it wasn't related to my system/mouse.

2000/4000/8000Hz polling mice are still relatively new. 1000Hz mice have existed for awhile now and is good enough to test for the issue though.

[elishacloud]

Your latest build somehow really slowed down the Y-axis movement on Enhanced SCCT Versus, it's basically unusable on that game. I didn't experience that issue on Splinter Cell 1 but the stuttering does happen still.

Sounds like you may need to increase the MouseMovementPadding value? The game may be ignoring input on the Y-axis because it is too small because I am not merging as many records as before. Adding padding that equals the value the game ignores will prevent the game from dropping the values.

I've never heard of a 6400Hz polling rate mouse, are you talking about DPI?

Yes, good call. It is DPI. My mouse only goes up to 1000Hz:

[Joshhhuaaa]

@elishacloud Okay, well I feel dumb now... so I tried without anything hooked to Splinter Cell 1, just using DirectX8 at 30 FPS with 1000Hz polling rate again, and the stutters are still happening. It seems to be a game engine issue I would say, dxwrapper isn't directly causing it.

I can't really blame myself though because Enhanced SCCT Versus when at 1000-8000Hz, the mouse speed is so slow that you can't even trigger a stutter on the default game. Splinter Cell 1 doesn't have the issue of higher polling rate resulting in slower mouse speed.

I'm not sure if this is something that can even be fixed if it's not your wrapper directly causing it. Regardless, not sure why you can't replicate it on your end.

[elishacloud]

Okay, well I feel dumb now... so I tried without anything hooked to Splinter Cell 1, just using DirectX8 at 30 FPS with 1000Hz polling rate again, and the stutters are still happening.

Ok, no problem. I was tearing out my hair trying to figure out what I did wrong. Sounds like this is not related to dxwrapper at all.

Regardless, not sure why you can't replicate it on your end.

Yeah, I just tried with 20 FPS and 1000Hz with 1600 DPI mouse speed on Splinter Cell and played for 10 minutes and did not see a single stutter.

I'm not sure if this is something that can even be fixed if it's not your wrapper directly causing it.

Did you try with out dgVoodoo2 and without EAX sound? I am just using non-EAX sound and d3d8to9.

BTW: I undid the sequencing change. This should fix the Y-axis: dxwrapper.zip

[Joshhhuaaa]

Okay, well I feel dumb now... so I tried without anything hooked to Splinter Cell 1, just using DirectX8 at 30 FPS with 1000Hz polling rate again, and the stutters are still happening.

Ok, no problem. I was tearing out my hair trying to figure out what I did wrong. Sounds like this is not related to dxwrapper at all.

Regardless, not sure why you can't replicate it on your end.

Yeah, I just tried with 20 FPS and 1000Hz with 1600 DPI mouse speed on Splinter Cell and played for 10 minutes and did not see a single stutter.

I'm not sure if this is something that can even be fixed if it's not your wrapper directly causing it.

Did you try with out dgVoodoo2 and without EAX sound? I am just using non-EAX sound and d3d8to9.

BTW: I undid the sequencing change. This should fix the Y-axis: dxwrapper.zip

Yeah, for Splinter Cell 1, I tested it without dgVoodoo2/EAX, just running the game in its standard DirectX8 capped at 30 FPS using RivaTuner (since Nvidia's cap requires DX9+). The 1000Hz does still cause stuttering. It might be hard to notice, but it's obvious to me when it happens. My friend also noticed it on his end, it even happens at 250Hz polling rate according to him, just very rare. So, it seems those games really want your mouse to update at ~120-125Hz. 60 FPS immediately fixes the stutter issue as far as I can tell, I'm not sure if it can be fixed for 30.

Your builds still feel helpful for Chaos Theory and Double Agent high polling when the game is at 60 FPS, so it wasn't a complete waste of time haha, but sorry for wasting your time with all those builds, I appreciate all the help.

[elishacloud]

Your builds still feel helpful for Chaos Theory and Double Agent high polling when the game is at 60 FPS, so it wasn't a complete waste of time haha, but sorry for wasting your time with all those builds, I appreciate all the help.

Ok, no problem. I am going to call this case closed for now. At least for the games I can test with I am not getting any stuttering and the FixHighFrequencyMouse definitely helps with these games.

[elishacloud]

@Joshhhuaaa, it a little bit bothered me that the stuttering only happened when the mouse frequency was high and the FPS was low. From what I can tell, the game is likely reading the mouse movements less often, since it seems to be reading the movements once per frame.

One thing I noticed with these games is that they only read one record from the mouse movement table at a time. However, the less often the table is read from the more chances that records will accumulate. That is because each time the records are read I merge only the new records and add them to the end of the table.

However, since the mouse frequency is so high and the FPS is so low that increases the chance that there will be two new records (one for X movement and one for Y movement) added to the table each frame. Since the game only reads one record on each frame it is possible that the records are building up and slowly become more and more out of date (older).

You mentioned that the issue happens more often when you have a key pressed, like 'W' or 'A'. If the mouse movements are getting older and the game detects that the key press from 'A' or 'W' is more out of sync (using the sequence numbers) with the mouse movement, the game may drop the old mouse movement records, causing the stuttering.

Anyways, that is just a theory. But, I did make a change today that doesn't just merge the new records. I also merge the old records with the new records. This should help the mouse movement get less out of sync and might help offset the fact that the records are read less often.

Here is the new build with this change in it: dxwrapper.zip

[Joshhhuaaa]

@Joshhhuaaa, it a little bit bothered me that the stuttering only happened when the mouse frequency was high and the FPS was low. From what I can tell, the game is likely reading the mouse movements less often, since it seems to be reading the movements once per frame.

One thing I noticed with these games is that they only read one record from the mouse movement table at a time. However, the less often the table is read from the more chances that records will accumulate. That is because each time the records are read I merge only the new records and add them to the end of the table.

However, since the mouse frequency is so high and the FPS is so low that increases the chance that there will be two new records (one for X movement and one for Y movement) added to the table each frame. Since the game only reads one record on each frame it is possible that the records are building up and slowly become more and more out of date (older).

You mentioned that the issue happens more often when you have a key pressed, like 'W' or 'A'. If the mouse movements are getting older and the game detects that the key press from 'A' or 'W' is more out of sync (using the sequence numbers) with the mouse movement, the game may drop the old mouse movement records, causing the stuttering.

Anyways, that is just a theory. But, I did make a change today that doesn't just merge the new records. I also merge the old records with the new records. This should help the mouse movement get less out of sync and might help offset the fact that the records are read less often.

Here is the new build with this change in it: dxwrapper.zip

The stutter issue remains present in that build. I grabbed an old mouse of mine that supports 125/250/500Hz to confirm, and yeah, even 250Hz and 500Hz can cause stuttering at 30 FPS. It seems only 125Hz is optimal for Unreal Engine 2, at least when running at 30 FPS.

I might go test some other Unreal Engine 2 games to see if I can learn more, although it's likely a widespread issue. Since Splinter Cell 1 and SCCT Versus are built on entirely different builds of Unreal Engine 2 and the multiplayer was developed separately by a different team with their own codebase, they shouldn't share exactly the same bugs.

[elishacloud]

Thanks for testing. I kept the change because I think it is a good change even if it does not help in your case. I wonder if there is an issue with the way the game handles timers. See here for an example: #175

Timers don't always function now exactly as they did in the past (when these games were made). Furthermore, things happen so much faster on computers now then they did before it can throw off the game's code. For example, the game starts to wait for something that was completed even before the game started to wait for it because the activity happened much faster than expected. Sometimes setting single process affinity can help, but other times other fixes need to be made.

[mirh]

Stuttering should be pretty noticeable (and quantifiable) if you just enable reporting of 1 and 0.1 percentiles in afterburner. Maybe you can notice some relative improvement for starters.
Also notable that the program has like 4 different types of frame rate limiting...

p.s. UE2 source code for many of the builds has been leaked over and over again during the years (for as much as ubisoft might have then done its own modifications)

[Joshhhuaaa]

Well, some bad news for Splinter Cell haha. I guess my assumption was wrong that it would likely be engine wide. The multiplayer developers must've stole some code from the single player developers and exclusively only these games are broke.

• Splinter Cell
• Splinter Cell: Pandora Tomorrow
• Splinter Cell: Pandora Tomorrow (Versus Mode)
• Splinter Cell: Chaos Theory
• Splinter Cell: Chaos Theory (Versus Mode)
• Splinter Cell: Double Agent
• Splinter Cell: Double Agent (Versus Mode)

All of these have the stutter issue, I haven't bothered testing Splinter Cell: Conviction (2010) and Splinter Cell: Blacklist (2013) but they run on the same Unreal Engine 2 foundation from the original game with tons of modifications to the engine. I wouldn't be surprised if they have the issue.

I tested Unreal Tournament 2004 and it had no issues, but it does run on a very late build of Unreal Engine 2 that could've seen improvements that Ubisoft didn't decide to integrate back into their older build of Unreal Engine 2. However, I just tested Rainbow Six 3 from Ubisoft and it didn't have the stutter issue and it's a build very close to the original Splinter Cell, so they must've just broke Splinter Cell's mouse code somehow.

p.s. UE2 source code for many of the builds has been leaked over and over again during the years (for as much as ubisoft might have then done its own modifications)

Yeah, I've got some Unreal Tournament 2004 builds of the source code. Interestingly, UT 2004 isn't showing the issue, so it might not be useful. It seems like the problem is specific to Splinter Cell. I do have the UnrealScript for SCPT Versus, but not the actual C++ source code, so that might not be as helpful.

Edit: Here's one more example of Splinter Cell: Pandora Tomorrow completely dying at 30 FPS with 8000Hz, this is a worst case scenario, but really shows what's going on if it's hard to notice on lower polling rates.

SCPT.Stutters.Example.mp4

Stuttering should be pretty noticeable (and quantifiable) if you just enable reporting of 1 and 0.1 percentiles in afterburner.

I should clarify that the game isn't actually stuttering. It feels more like your mouse is randomly dropping out or encountering a severe dead zone. I've been calling it the "stutter" problem, just for simplicity but I think it's more about input being ignored.

28-06-2024, 15:42:40 SplinterCell2.exe benchmark completed, 450 frames rendered in 15.000 s
                     Average framerate  :   29.9 FPS
                     Minimum framerate  :   30.0 FPS
                     Maximum framerate  :   30.0 FPS
                     1% low framerate   :   30.0 FPS
                     0.1% low framerate :   30.0 FPS

15 seconds of the mouse experiencing the issue at 8000Hz polling seems to hold a consistent 30 FPS.

[mirh]

All the games from Epic itself have been updated plenty of times since their release day (unless you are installing them from cd?). Deus ex invisible war, postal 2 or SWAT 4 would be probably better.

---

Holy moly maccaroni, that's NOT what stuttering is. In fact it looks like what 100% normally happens when a mouse has super duper sensitivity, and to counteract that you set in-game sensitivity to the lowest possible.

[elishacloud]

and to counteract that you set in-game sensitivity to the lowest possible.

I did add an option called MouseMovementFactor that can be set to a fractional value, like 0.5 to reduce the mouse speed/sensitivity. I also recommend pairing this with MouseMovementPadding, if you set the movement factor to a very small number.

[Joshhhuaaa]

All the games from Epic itself have been updated plenty of times since their release day (unless you are installing them from cd?). Deus ex invisible war, postal 2 or SWAT 4 would be probably better.

Holy moly maccaroni, that's NOT what stuttering is. In fact it looks like what 100% normally happens when a mouse has super duper sensitivity, and to counteract that you set in-game sensitivity to the lowest possible.

Yeah it's not stuttering at all, so I shouldn't refer to it as the "stutter" problem anymore haha. The issue happens on very low sensitivities as well, I know cranking sensitivity in older engines is typically a disaster. But this is not a result of that, this is caused by polling rate while also being on 30 FPS, 125Hz doesn't have the problem.

I installed UT 2004 from the Steam version, I assume that would be the latest. I can test SWAT 4 GOG later.

[mirh]

That's also granted to be very much patched.

"Immediate skipping" or "digital moving" could be better names perhaps.

[elishacloud]

My suggestion for the Splinter Cell games is that they get patched to fix the issues at 60 FPS or higher so that we can solve both issues.

[Joshhhuaaa]

My suggestion for the Splinter Cell games is that they get patched to fix the issues at 60 FPS or higher so that we can solve both issues.

That would be the ideal solution but least likely, there's not enough interest in Splinter Cell, nobody's going to make patches for it especially Versus modes.

[mirh]

I wouldn't really hope on patches (both because the games are old, but also because AFAICT more often than not games break in multiple ways and the more framerate increases and the more everything starts to get loose apart).

Anyway, maybe we should back up a little.. trying to sum up what happens, especially after this enormous fail (and also because I'm not even sure how we went from OFP to SCCT)

@0xvpr do you have any insight over the input code?
@Methanhydrat are you still up into the game?

[NATO2000]

@NATO2000, I went through the ticket and memory lane. I see the confusion. The d3dx.dll is just a renamed version of dxwrapper.dll and d3dx.ini is just a renamed version of dxwrapper.ini.

Here is what I suggest:

1. Delete dxwrapper and dinput8.dll from the package (at least the dinput8.dll stub that came with dxwrapper you can use a different dinput8 if you like)
2. Take note of all the settings in the d3dx.dll file (especially the WrapperMode = d3d8.dll setting, that needs to be set or the game won't even work).
3. Replace the d3dx files (dll and ini) with the dxwrapper files, renaming both dxwrapper files to d3dx.
4. In the new d3dx.ini set all the setings that you noted in step 2. You can also set other settings, like the FixHighFrequencyMouse or the MouseMovementPadding.

This will allow the new dxwrapper to replace the old d3dx files. This should give you all the functionality of the old d3dx but with the new functionality of the new dxwrapper.

Here is the latest dxwrapper fo you to use. I pre-enabled some of the settings for you: dxwrapper.zip

@elishacloud
**I'm reporting the latest test results. I renamed dxwrapper.ini and dxwrapper.dll from the zip you provided according to the instructions. Here's what I found:

Vertical sync function is abnormal. Even though I've forced global VSync off in the NVIDIA control panel and set EnableVSync to 0 or 1, the game's framerate remains at 60 FPS. Only when I set ForceVsyncMode = 1 does VSync disable, and the game's framerate exceeds 60 FPS.

The game won't launch when I set ForceDirect3D9On12 = 1

Please check out what happend**

;; Config file for DirectX DLL Wrapper
;;
;; For details, see: https://github.com/elishacloud/dxwrapper/wiki/Configuration
;;
[General]
RealDllPath = AUTO
WrapperMode = d3d8.dll
LoadCustomDllPath =
ExcludeProcess =
IncludeProcess =
RunProcess =
WaitForProcess = 0
DisableLogging = 0

[Plugins]
LoadPlugins = 0
LoadFromScriptsOnly = 0

[Compatibility]
Dd7to9 = 0
D3d8to9 = 1
DDrawCompat = 0
Dinputto8 = 1
DisableGameUX = 0
EnableDdrawWrapper = 0
EnableD3d9Wrapper = 0
EnableDinput8Wrapper = 1
EnableDsoundWrapper = 0
HandleExceptions = 0
SingleProcAffinity = 0

[DDrawCompat]
DDrawCompat20 = 0
DDrawCompat21 = 0
DDrawCompat32 = 0
DDrawCompatDisableGDIHook = 0
DDrawCompatNoProcAffinity = 0

[ddraw]
ConvertToDirectDraw7 = 0
ConvertToDirect3D7 = 0
DdrawOverrideBitMode = 0

[Dd7to9]
DdrawAutoFrameSkip = 0
DdrawEmulateSurface = 0
DdrawEmulateLock = 0
DdrawForceMipMapAutoGen = 0
DdrawFlipFillColor = 0
DdrawFixByteAlignment = 0
DdrawDisableByteAlignment = 0
DdrawRemoveScanlines = 0
DdrawRemoveInterlacing = 0
DdrawReadFromGDI = 0
DdrawWriteToGDI = 0
DdrawDisableDirect3DCaps = 0
DdrawLimitDisplayModeCount = 0
DdrawCustomWidth = 0
DdrawCustomHeight = 0
DdrawUseNativeResolution = 0
DdrawOverrideWidth = 0
DdrawOverrideHeight = 0
DdrawIntegerScalingClamp = 0
DdrawMaintainAspectRatio = 0

[d3d9]
AnisotropicFiltering = 16
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 = 1
GraphicsHybridAdapter = 0

[FullScreen]
FullScreen = 0
ForceWindowResize = 0
WaitForWindowChanges = 0

[dinput8]
DeviceLookupCacheTime = 0
FilterNonActiveInput = 0
FixHighFrequencyMouse = 1
MouseMovementFactor = 0
MouseMovementPadding = 0

[dsound]
Num2DBuffers = 0
Num3DBuffers = 0
ForceCertification = 0
ForceExclusiveMode = 0
ForceSoftwareMixing = 0
ForceHardwareMixing = 0
ForceHQ3DSoftMixing = 0
ForceNonStaticBuffers = 0
ForceVoiceManagement = 0
ForcePrimaryBufferFormat = 0
PrimaryBufferBits = 16
PrimaryBufferSamples = 44100
PrimaryBufferChannels = 2
AudioClipDetection = 0

d3dx-flashpointresistance.log

this is the Failed report