pboy0922 / x360ce

Automatically exported from code.google.com/p/x360ce
1 stars 0 forks source link

Vibration seems to be suffering from undefined behaviour or magic numbers.... #1062

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Build x86 release dll in VS2010
2. use with app version 2.1.2.191 or 2.2.3.203
3. Try a game known to vibrate

What is the expected output? 
Rumble to behave exactly like the x64 build

What do you see instead?
Inconsistent behavior, x86 dll either has no rumble at all or very weak rumble.
Toggling Vibration in 2.2.3.203 might being some rumble feedback, but nowhere 
near as powerful as x64 dll.

This happens across all rumble types on x86 dll.

Also on both x86 (after toggle) and x64 dll, left and right sliders vibrate 
both motors in Periodic(Sawtooth) mode.

Allowing 2.2.3.203 to generate its internal r975 dll, the rumble works 
perfectly.

Original issue reported on code.google.com by danialho...@gmail.com on 17 Dec 2014 at 12:50

GoogleCodeExporter commented 9 years ago

Original comment by danialho...@gmail.com on 17 Dec 2014 at 12:52

GoogleCodeExporter commented 9 years ago
might bring* (i dislike googles lack of editing)

Original comment by danialho...@gmail.com on 17 Dec 2014 at 12:53

GoogleCodeExporter commented 9 years ago
PS. Rumble works like x64 in x86 Debug.

Original comment by danialho...@gmail.com on 17 Dec 2014 at 12:53

GoogleCodeExporter commented 9 years ago
I wouldn't mind taking a look. Can you give more specific details? What 
controller do you have? What are the features of the controller? What is one 
instance where it worked with x64 and not x86? For instance, the x360ce app 
should accurately reflect problems with vibration. Which mode definitely worked 
in x64 and not x86? What was the behavior in each of those cases?

Original comment by ratanakv...@gmail.com on 25 Dec 2014 at 9:08

GoogleCodeExporter commented 9 years ago
MLG Xbox 360 pad using XBCD drivers
Rumble works fine in x86 r975 (currently included in ejocy's app) and lower.

the config app is where im first seeing the issue, x64 rumbles(although, 
incorectly), x86 does not rumble at all.

with r975, x86 and x64 testing left and right motors while using 
PeriodicSawtooth will drive the big and small motors individually.

with recent r1xxx revisions, the rumble has been re-factored and moved about, 
and now PeriodicSawtooth rumbles both motors in x64, and neither in x86.

It is hard to determine when this started to occur with quite a few revisions 
between the issue not occuring and now not being  buildable on VS100.

Original comment by danialho...@gmail.com on 26 Dec 2014 at 4:25

GoogleCodeExporter commented 9 years ago
Yes, motor separation can be broken, because FFB now uses only one effect, but 
is not limited to one, I used std::vector to pack all effect inside so any FFB 
method can use as many required.

Original comment by tapcio on 26 Dec 2014 at 10:40

GoogleCodeExporter commented 9 years ago
Regression Range

1043 - 1050

narrowing it down further...

Original comment by danialho...@gmail.com on 26 Dec 2014 at 11:39

GoogleCodeExporter commented 9 years ago
1045 - working like 975
1046 - does not build
1047 - no vibration in x86 build.

Original comment by danialho...@gmail.com on 26 Dec 2014 at 11:47

GoogleCodeExporter commented 9 years ago
Copy/copy-assign constructor was incorrect in r1047, should be fixed in r1048.

Original comment by tapcio on 26 Dec 2014 at 11:53

GoogleCodeExporter commented 9 years ago
There is no vibration in any x86 builds after 1047 though, right up to latest.

Original comment by danialho...@gmail.com on 26 Dec 2014 at 11:57

GoogleCodeExporter commented 9 years ago
ok, if i put the control right up to my ear, i can hear the motors ticking in 
x86 builds after 1047

Original comment by danialho...@gmail.com on 26 Dec 2014 at 12:00

GoogleCodeExporter commented 9 years ago
Force strength can be much lower, can you test with ForcePercent set to 200 ?

Original comment by tapcio on 26 Dec 2014 at 12:02

GoogleCodeExporter commented 9 years ago
in 1064 i can feel vibration again, but it is weak.

Original comment by danialho...@gmail.com on 26 Dec 2014 at 12:05

GoogleCodeExporter commented 9 years ago
"Force strength can be much lower, can you test with ForcePercent set to 200 ?"

I already did, and the strength should not require changing between x86 and x64 
dll's O.o, like i said, x64 vibration is as strong as it has always been.

Original comment by danialho...@gmail.com on 26 Dec 2014 at 12:06

GoogleCodeExporter commented 9 years ago
when i compile 1068 x86, i must untick enable forcefeedback, and then tick it 
back on before the motors will work.

Original comment by danialho...@gmail.com on 26 Dec 2014 at 12:09

GoogleCodeExporter commented 9 years ago
so two issues with x86 dll

#1 current code will not rumble on initial initialisation of x86 dll (x64 works 
from start)
#2 x86 rumble is much weaker than x64 when it finally does work.

Original comment by danialho...@gmail.com on 26 Dec 2014 at 12:12

GoogleCodeExporter commented 9 years ago
Check this.

Original comment by tapcio on 26 Dec 2014 at 12:14

Attachments:

GoogleCodeExporter commented 9 years ago
this may be relevant

http://stackoverflow.com/questions/23281405/how-to-use-a-stdvectorunique-ptrt-as
-default-parameter

Original comment by danialho...@gmail.com on 26 Dec 2014 at 12:14

GoogleCodeExporter commented 9 years ago
unhandled exception at startup of x360ce.exe

See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.Exception: Attempted to read or write protected memory. This is often an 
indication that other memory is corrupt.
   at SharpDX.XInput.XInput.XInputGetState(Int32 dwUserIndex, State& pState)
   at x360ce.App.Controls.PadControl.UpdateForceFeedBack()
   at x360ce.App.MainForm.ReloadLibrary()
   at x360ce.App.MainForm.UpdateTimer_Elapsed(Object sender, ElapsedEventArgs e)

Original comment by danialho...@gmail.com on 26 Dec 2014 at 12:17

GoogleCodeExporter commented 9 years ago
oh, also, like i said, the issue is not present in debug dll. Rumble works 
first time and is full strength when using debug x86 dll. magic behavior ;3.

Original comment by danialho...@gmail.com on 26 Dec 2014 at 12:20

GoogleCodeExporter commented 9 years ago
Hym, dunno, works in RumbleController.exe (DXSDK sample).

Original comment by tapcio on 26 Dec 2014 at 12:24

GoogleCodeExporter commented 9 years ago
The effects vector stores plain old pointers, so it does not suffer from the 
problem in that article (which is an issue with vectors that store class 
instances).

Original comment by ratanakv...@gmail.com on 26 Dec 2014 at 12:25

GoogleCodeExporter commented 9 years ago
Hym, there is something wrong with Controller object:
Controller::~Controller() m_pDevice is nullptr, but in 
ForceFeedback::~ForceFeedback() called after it's invalid pointer, this cause 
crash at exit.
And deinitalization order seems to be incorrect...

Original comment by tapcio on 26 Dec 2014 at 12:43

GoogleCodeExporter commented 9 years ago
Darksouls.exe
http://pastebin.com/Zw085GXR

x360ce.exe (can't seem to get the right symbols, but dllmain is in stack)
http://pastebin.com/wBX6aM8B

Original comment by danialho...@gmail.com on 26 Dec 2014 at 12:47

GoogleCodeExporter commented 9 years ago
i mailed you the dump files btw.

Original comment by danialho...@gmail.com on 26 Dec 2014 at 12:48

GoogleCodeExporter commented 9 years ago
I noticed that problem too. Do you have dinput8.dll in the directory? It might 
have something to do with that.

Original comment by ratanakv...@gmail.com on 26 Dec 2014 at 12:51

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
the dinput8 crash is in the systems dinput8.dll, not the dinput8 bundled with 
x360ce.

the crash comes up in several games, and and dark souls is the only one that 
'may' require the dinput8.dll on some systems... occurs in USF4 and DMC for 
instance, but neither requires the dinput8.dll.

Original comment by danialho...@gmail.com on 26 Dec 2014 at 12:58

GoogleCodeExporter commented 9 years ago
It crashes at start ?

Original comment by tapcio on 26 Dec 2014 at 1:00

GoogleCodeExporter commented 9 years ago
also, it doesn't affect x64 applications either O.o

Original comment by danialho...@gmail.com on 26 Dec 2014 at 1:02

GoogleCodeExporter commented 9 years ago
oh, comment 28 and 30 was about the known crash in dinput8.dll that you 
mentioned awhile back. I cannot reproduce it in the x64 dll with x64 
applications, but x86 dll built on the same code does crash in x86 applications 
on exit (excepting x360ce.exe)

with dll in comment 17, Dark souls and X360CE crash before any notification 
beep is heard

Original comment by danialho...@gmail.com on 26 Dec 2014 at 1:05

GoogleCodeExporter commented 9 years ago
r1103

Original comment by tapcio on 26 Dec 2014 at 1:29