Qemu USB plugin (formerly known as USBqemu-wheel)
#11
Some configuration options (linux version is half done). GT3 seems to work. Two players should be supported, untested.
Latest binary: https://github.com/jackun/USBqemu-wheel/...er/Release

Buttons: for some reason HidP_GetUsages sometimes returns an error, so buttons toggle on/off Wacko Logic error somewhere...
Reply

Sponsored links

#12
First, disclaimer, This is an old microsoft wheel and IIRC never had proper drivers for windows 7. But when I plugged it the first time to my laptop, windows detected it and installed some driver, and at the gamepads at the control panel it seems to respond well, except that the axis setup is weird: wheel left-right is the X axis (middle when wheel is at the center), one pedal is the Y axis (0 when the pedal is fully up), and the other pedal is the Z axis (also 0 when that pedal is fully up).

So I tried it with GT4 after compiling it myself, and was able to see and choose my wheel at the config. First, for some reason, if I boot with the plugin enabled, PCSX2 runs very very slow (10fps) with the CPU at 3%. If I disable the plugin and enable it after GT4 starts, then it runs at full speed (120fps before the game starts).

Then, GT4 somehow detects the wheel. I can turn the wheel left and right, and it moves the cursor within the game. But the default driver in win7 somehow maps the axis badly as I noted above, so maybe GT4 had issues with it.

Then, in the game, it didn't respond to the wheel itself, but gas and break did work. However, gas was like on-off, and breaks was analog, but only over a very small range of the full range (like only uses the 45-55% section, where above it is 100% and below it is 0%).

Also, when I drove into a wall, I couldn't feel any force feedback whatsoever.

TBH, it's better than what I expected, though still not useable as-is with my wheel Smile
Reply
#13
Hehe, uncomment the fprints and see what wheel axis does what. Buttons are snafu'd for some reason. Get the code from github, if you haven't. I think ReadFile and WaitForSingleObject (or whatitsnamewas) are slowing it down. Late night changes so haven't got to testing it yet Tongue

Another option is to create a hidden window for raw input api and capture input from there.

E: Eh i haven't pushed the code with lower timeout, but see if smaller timeout works: https://github.com/jackun/USBqemu-wheel/...32.cpp#L51

Also to note is currently wheel's X axis value should be 0 to 1023 and brake/gas 0 to 0xFF and pedals are depressed if value is 0xFF for some weird reason.
Reply
#14
I did take it from guthub, but few days ago. I'll try to update and test again but not before next week. If you could add some axis setup to the config (like, turn the wheel fully left, now fully right, now push the gas pedal.. etc) before I get to test it again, it would be great! Tongue2
Reply
#15
Eventually should have some axis/button mapping.

I don't know if i should do some cycle dec/inc, but messing with PSXCLK and USBasync() cycle counts seems to affect framerate. But stuff gets a bit stuttery with frame limiter even though PAL version sits at 50fps Wacko
Reply
#16
From the little I tested, it only affects frame rate if it's enabled WHILE booting (and it just keeps slow). But if I disable the plugin, boot, and then enable the plugin right away, then it doesn't affect the frame rate. I'll maybe try to debug it a bit, but only next week.
Reply
#17
Thank you for this. I tried it with my Fanatec GT3 wheel, with Gran Turismo 4. For the most part it works, but something is not working correctly with the steering. It works ok for the first few degrees but after that the steering goes in another direction and the wheel oscillates as if data types are not matching or some misalignment in the descriptor.

On the Win32 side one could generalize this a whole lot by using DirectInput.

I'm currently looking through the source.. it should be as simple as emulating one type of wheel to the game (prefereably one with all available options), interpret the HID packets (forces, axis inputs, buttons, etc), the rest would be handle by the DirectInput API.

This will universally allow use of more wheels which do not natively support PS2, but have proper windows drivers. Since I imagine the underlying problem is each wheel has slightly different packet descriptors.

I have several wheels for testing... G25, DFP, Fanatec, Microsoft Sidewinder and will update my progress.

EDIT: Tried my DFP wheel, didn't work at all. I'm using latest release on Github.

EDIT2: i managed to make my fanatec wheel work perfectly in GT4 with slight modification in usb_pad_poll

I changed
generic_data.axis_x = value;
to
generic_data.axis_x = value * 0.05;


just the buttons need a bit work
Reply
#18
(12-21-2013, 06:57 AM)Racer_S Wrote: On the Win32 side one could generalize this a whole lot by using DirectInput.

I think MS prefers raw input api usage? Anyway it should be generic enough now except force feedback stuff that writes data directly to usb device.

(12-21-2013, 06:57 AM)Racer_S Wrote: I changed
generic_data.axis_x = value;
to
generic_data.axis_x = value * 0.05;

Ah crap, i didn't add the min/max value check yet. My wheel's value is max 1023 (0x3FF) and im guessing yours is 900° wheel so its maximum is 0x3FFF if I remember correctly. 'pValueCaps' should have these values, pValueCaps[i].LogicalMax maybe, can't remember Tongue

So quick try
Code:
generic_data.axis_x = value * 0x3FF / 0x3FFF;

E: Wait... i added it but it is commented out. Too early, need coffee

E: DFP should do direct copy/paste. Probably wrong descriptor messing it up.

E: too many Fs
Reply
#19
Hey thanks for quick reply. I did see that commented and played with it but couldnt get it to give the correct value. Also I have an issue where it works correctly in GT4, but in Enthusia the value is not correct anymore (wheel off center)

Anyway I think your method of directly passing through the USB packets works great for force feedback on most wheels (all wheels use the same output descriptor i think), but using directinput api to obtain inputs would be a better solution as it eliminates the need to figure out the input descriptor for each manufacturer and weird stuff like what is happening in the video below. I will have to test it later tonight.

I would like to contribute to this project but im not familiar with svn collaboration or how difficult it would be.

you can see here my friend testing it with Thrustmaster T500 wheel , dont mind the question at the end, that was inteded for me Smile
https://drive.google.com/file/d/0B4lfqq0...sp=sharing
Reply
#20
Dinput gave normalised values?

He is using my build? I think the thrustmaster axis range is more than the 0..1023 then and overflows. That's why the wheels suddenly turn right probably Tongue
Clutch seems to work so hopefully he just has to remap axes from configure dialog.

I'm patching that range thing, hopefully it works.
Gotta go get Enthusia from Arrrbay now Tongue

(12-21-2013, 07:40 PM)Racer_S Wrote: I would like to contribute to this project but im not familiar with svn collaboration or how difficult it would be.

I, too, know bare basics of git. But fork the repo on github and create merge requests. Then i'll have to figure out how to merge on github Laugh Tortoisegit looks to be simplest to use on bare windows http://code.google.com/p/tortoisegit/
Reply




Users browsing this thread: 3 Guest(s)