Open GoogleCodeExporter opened 9 years ago
Original comment by danialho...@gmail.com
on 17 Dec 2014 at 12:52
might bring* (i dislike googles lack of editing)
Original comment by danialho...@gmail.com
on 17 Dec 2014 at 12:53
PS. Rumble works like x64 in x86 Debug.
Original comment by danialho...@gmail.com
on 17 Dec 2014 at 12:53
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
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
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
Regression Range
1043 - 1050
narrowing it down further...
Original comment by danialho...@gmail.com
on 26 Dec 2014 at 11:39
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
Copy/copy-assign constructor was incorrect in r1047, should be fixed in r1048.
Original comment by tapcio
on 26 Dec 2014 at 11:53
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
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
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
in 1064 i can feel vibration again, but it is weak.
Original comment by danialho...@gmail.com
on 26 Dec 2014 at 12:05
"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
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
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
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
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
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
Hym, dunno, works in RumbleController.exe (DXSDK sample).
Original comment by tapcio
on 26 Dec 2014 at 12:24
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
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
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
i mailed you the dump files btw.
Original comment by danialho...@gmail.com
on 26 Dec 2014 at 12:48
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
[deleted comment]
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
It crashes at start ?
Original comment by tapcio
on 26 Dec 2014 at 1:00
also, it doesn't affect x64 applications either O.o
Original comment by danialho...@gmail.com
on 26 Dec 2014 at 1:02
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
r1103
Original comment by tapcio
on 26 Dec 2014 at 1:29
Original issue reported on code.google.com by
danialho...@gmail.com
on 17 Dec 2014 at 12:50