Dolphin, the GameCube and Wii emulator - Forums

About force: Yes that is what I needed now I see what is wrong. The Logitech wheel needs at lease < 75 to make the wheel jerk noticeably left. > 185 or so right. In game mashing the left wall I get 113 and that is not enough to make it noticeable. I would suggest sensitivity setting, however I could alternatively make the compensation on my end.

About wheel, I dont think we are understand each other. The wheel still works in then GDPad test menu , Looks attached to Y axis left is +y and R is -y. Though in game it no longer works since that last build you made.

The sensitivity is not controlled by the emulator. The game controls the sensitivity. The emulator is using the maximum force that DirectX allows which means that it is at the most sensitive setting. The emulator could have a setting that makes the forces weaker.

Yes, I have changed the steering to be mapped to the X axis, mapped to left and right on the main stick. Would you make a screenshot of the GCPad settings?

If you're saying that steering the wheel left and right makes Axis Y+ and Axis Y- appear in the button, then that is controlled by the controllers driver.

1)sensitivity.

Quote:The emulator is using the maximum force that DirectX allows which means that it is at the most sensitive setting.

So if the game says I hit a wall produce a force of 113 ( just a nudge to the left ) then DX is sending 1 ( full sensitivity left )? If this is correct why, DX support sensitivity, why not use it? Just send the 113... :Confused:

Process chart as it should be
Game ---> issueForce ---> SendAForce(113:int8) ---> sendFroceToDXConstantForce(113:int16)---> HIDConstantForceReceived ---> sendToHidDevice( 113:uchar) ---> BlissBoxReceivedCForceAmount---> sendWheelFroce(113:uchar)


Process chart asyou just described above.
Game ---> issueForce ---> SendAForce(113:int8) ---> sendFroceToDXConstantForce(1:int16)---> HIDConstantForceReceived ---> sendToHidDevice( 1:uchar) ---> BlissBoxReceivedCForceAmount---> sendWheelFroce(1:uchar)




As to the x vs y. The wheel itself is mapped to Y by Nintendo. Or more specifically by Logitech with Nintendo approval of sorts. In other words when I query for the buttons and analogs pressed from the wheel itself, it replies with +/- y not X. Since I dont have the pedals its impossible for me to say if they report on the X analog or not. My guess is that the paddles on the wheel are mapped to that C stick analogs. I'm not sure why you would make the users map the y -/+ to x -/+ ?. Doing that means you just have to map is back when you switch the the regular controller? My GCPad is set up for the controller and on the previous build all I had to do is select steering wheel and the wheel works in-game perfectly. The way you have it now I have to map Y to X and doing this means in controller mode I'm f*cked. So I have to un map it to play controller based games. Just seemly wrong to me. Why did you have to change it to X axis anyways?


This shot is me turning the wheel to the left.



Maybe this will explain it better. This is the reply from the GC controller and wheel.
Bit Function
0-2 Always 0
3 Start
4 Y
5 X
6 B
7 A
8 Always 1
9 L
10 R
11 Z
12-15 Up,Down,Right,Left
16-23 Joy X
24-31 Joy Y ( this is where the wheel left right shows up )
32-39 C Joystick X
40-47 C Joystick Y
48-55 Left Btn Val ( this is the left hand lever on the wheel )
56-63 Right Btn Val ( this is the right hand lever on the wheel )

The game swaps this for you , no need to make the emulator do it. If you were to plug in the wheel go to the setup screen calibration then swap out for a GC controller up and down make the wheel work not left right. On the other hand if you start the game with the controller it remaps it so left and right work the wheel. I'm positive its done that way for a reason. Most consoles like psx and saturn do the same thing.

(01-02-2013, 08:32 AM)ulao Wrote: [ -> ]So if the game says I hit a wall produce a force of 113 ( just a nudge to the left ) then DX is sending 1 ( full sensitivity left )? If this is correct why, DX support sensitivity, why not use it? Just send the 113... :Confused:

Process chart as it should be
Game ---> issueForce ---> SendAForce(113:int8) ---> sendFroceToDXConstantForce(113:int16)---> HIDConstantForceReceived ---> sendToHidDevice( 113:uchar) ---> BlissBoxReceivedCForceAmount---> sendWheelFroce(113:uchar)

113:int8 -> 113:int16 is not correct. It should be scaled to int16, not cast.

128 - 113 = 15
15 / 128 = 0.1171
0.1171 * 10000 = 1171

113:int8 -> 1171:int16

Maybe try changing the deadzone to 0 instead of 15. DX should be sending 1171, not 1.

(01-02-2013, 08:32 AM)ulao Wrote: [ -> ]I'm not sure why you would make the users map the y -/+ to x -/+ ?. Doing that means you just have to map is back when you switch the the regular controller?

Not everybody has a blissbox and GC steering wheel. We are emulating the steering wheel with an equivalent PC device. Kinda like how people emulate the wiimote using PS2 DualShock controllers. If we were to keep the mapping of the steering wheel to the Y axis, this would be quite confusing for users that do not have a blissbox. And if they have a blissbox and GC steering wheel, and they want to play a Windows DirectX game, do you want the player to remap their steering wheel to the game?

You can map the wheel to the X axis and then save the profile using the buttons on the top right hand corner of the GCPad settings, and switch between these when a wheel or other device is connected.

********************
* update on usb sniffer *
********************
Turns out Dolphin is not sending rumble commands for collision at all? In the first build is was but the second its only sending a force when I hit the a button. Originally I though it was the magnitude but now I can see there are no forces coming over the usb for collision ( like hitting a wall ). I can show you how to check this on your end if you like. USBTrace does the trick but you godda cr4ck it or your limited by a log of 255 lines.
***********
*end update*
***********

Quote:Not everybody has a blissbox and GC steering wheel. We are emulating the steering wheel with an equivalent PC device.

I see, I thought to goal was to emulate the GC wheel. Would it be a simple option to add "PC Wheel" and "GC wheel" to the list of controllers?

Quote:And if they have a blissbox and GC steering wheel, and they want to play a Windows DirectX game, do you want the player to remap their steering wheel to the game?

Well in the hardware world you dont mess with design. If you have drivers with hardware then you can give addition options there. In my case if someone wanted to use the Bliss-Box on a PC game, yes they would do the mapping there. The entire point in what I do is allow the computer to interface with the actual hardware where possible. Things like writing to an lcd screen ( dream cast controller ) would entail some software assisting. In the case of emulators, typically the user gets to set up the controller the way they see it best. Just like dolphin does. So in that sense I agree. In this case dolphin natively expects to see steering on the Y axis, the console wheels typical use the Y axis but PC wheels evidently use the X access. So you made a special fix in the core emulation to make it easy for PC wheels so they dont have to go in and change mappings. ehh, ok.

I think your good to go then. Looks like Dolphin has a wheel option. I'll work out my FFB issues later on, does not look to be on your in in that last description of what you said but there is one thing left I dont get.

Quote:128 - 113 = 15
15 / 128 = 0.1171
0.1171 * 10000 = 1171

the GC sends a unsigned int (0 to 255 ) not a signed int (-128 to 128 )?
255 - 113 = 142
142 / 255 = 0.5568627450980392
0.5568627450980392 * 10000 = 5568.627450980392

example from your logs:
11:40:957 Src\HW\SI_DeviceGCController.cpp:266 E[SI]: unknown direct command (0x300697)
11:44:777 Src\HW\SI_DeviceGCController.cpp:266 E[SI]: unknown direct command (0x3006aa) 0xaa is 170 proving is uses numbers > 128 so it must be sending 0x00 to 0xff
11:44:891 Src\HW\SI_DeviceGCController.cpp:266 E[SI]: unknown direct command (0x300480)

in C++ all ints are signed right, so you would have to use as uint or are you putting the hex value from the direct command in to a signed int, preserving all data?
0x0A should be -118
0xA0 should be 32
0xFF then would be 128

also this implies you are putting it to a size of 10,000

Quote:0.1171 * 10000 = 1171

The range is -10,000 to 10,000 yes? So you would need to do
0.1171 * 20000 = x
then x - 10000
otherwise you are ways sending a positive number ( unsigned ).

Just trying to be constructive here of course.

(01-04-2013, 02:40 AM)ulao Wrote: [ -> ]128 - 113 = 15
15 / 128 = 0.1171
0.1171 * 10000 = 1171

The math above is working out the distance from the center. The value sent to DInput would have been -1171 in that case.

(01-04-2013, 02:40 AM)ulao Wrote: [ -> ]the GC sends a unsigned int (0 to 255 ) not a signed int (-128 to 128 )?

0x0A should be -118
0xA0 should be 32
0xFF then would be 128

In hardware, there are no signed and unsigned, there are only bytes. The emulator interprets the bytes to be -128 to 128, yes, as per your three examples.

(01-04-2013, 02:40 AM)ulao Wrote: [ -> ]in C++ all ints are signed right, so you would have to use as uint or are you putting the hex value from the direct command in to a signed int, preserving all data?

Remember that Dolphin is using the DirectInput library. the lMagnitude parameter for Constant effects is a LONG, which is signed. The hex value has to be translated to something the PC can understand (in the example above, it would be -1171). We cannot preserve all data because the PC does not understand GC hardware signals.

(01-04-2013, 02:40 AM)ulao Wrote: [ -> ]also this implies you are putting it to a size of 10,000

The 10000 comes from dinput.h in the DirectInput library and it represents DI_FFNOMINALMAX, the maximum force produced by the game controller.[/quote]

(01-04-2013, 02:40 AM)ulao Wrote: [ -> ]Turns out Dolphin is not sending rumble commands for collision at all? In the first build is was but the second its only sending a force when I hit the a button.

Do you mean hitting a button in game, or hitting the button in the Test Rumble window of the GCPad settings?

I have not changed how forces are sent in the second build. Have you changed the deadzone to zero yet? If not, try doing that.

One thing that comes to mind is that the driver of the blissbox might be configured to be DIEDFL_FORCEFEEDBACK. In my Logitech wheel, the driver responds to force feedback signals even without the DIEDFL_FORCEFEEDBACK flag. Is there something you can change there (in the driver) related to DIEDFL_FORCEFEEDBACK?

No I mean in game.

Quote:One thing that comes to mind is that the driver of the blissbox might be configured to be DIEDFL_FORCEFEEDBACK. In my Logitech wheel, the driver responds to force feedback signals even without the DIEDFL_FORCEFEEDBACK flag. Is there something you can change there (in the driver) related to DIEDFL_FORCEFEEDBACK?

I have not seen any mention of this on the usb PID spec by Microsoft. Though normal rumble works, can you show me a code segment from the type of force you are using for the wheel that differs from rumble?
Also again, this is not a bliss-box thing. I'm sniffing the usb protocol and its sending the correct type of FFB command like it should. Though like I said all of a sudden no calls when hitting walls. Also on the old version the wheel would shake a bit at idle ( even the dolpihn logs shows this ) but no FFB calls are being sent.

One theory here could be that you are using the drive specific call? Meaning your implementation will only work on that wheel. I would suggest using HID force feed back calls so all FFB device will work. Only a guess.

Also the Fedit program made by microsoft works. So my implementation agrees with there usage.

I'll keep investigating with it.

what dead zone? there is no such thing for FFB? Dont tell my its the output setting?

The deadzone setting is in this dialog:



Change the deadzone setting from 15 to 0 and retry.

Dolphin does not use any USB/HID code for the controllers. It is all handled via an intermediate library like DirectInput, XInput, or SDL. The library is responsible for sending the force feedback message to the device driver.

That is what I figured about direct input, since that the case it should work fine.

those dedzones are for the analogs not FFB, I dont follow the logic.



what dead zone? there is no such thing for FFB? Dont tell my its the output setting?

Oh and for the love of @#$%@#$, who wrote that code in the rumble dialog box? It seems "range" is not for testing it actually effects something?

setting 0: basically makes the wheel force hard left during any FFB command and never stops? ( in game )
setting 256: Makes the wheel force hard left during any FFB command fore one second( in game )
setting 500: Makes the wheel force hard left ( two pulses ) during any FFB command fore half second each.( in game )

What the heck is this slider for? Please explain the authors intent here because "range" is not clear. And these results are even more confusing.