Recent Posts

Looks really nice. I wish I had access to a 3D printer but if I bought one I know I'd only use it a couple of times a year, if that.  It looks like it provides options for things that would be too difficult to make by hand. Opens up a lot of possibilities.

I found this youtube before that gives a link in the description to a dll file linked on the github issues page:



It enabled me to use the offset menu and I think it may also fix the remapping but I didn't test that. I can see now how the offsets work as it is.

Unfortunately they didn't seem to provide any code and it's already compiled so it still leaves me to get it working.

But that github you sent could be very useful because I'll need to compile the program and use it to figure out exactly how the offsets work and if I can send a fixed position.

I had tried something with the client commandline program but it didn't work. But I didn't know about it faking a tracker and maybe that's why

This is a good idea. I did have a look at OpenVR Input Emulator and I had heard about it before with regards to changing the angle from the controller to the screen. It's open source which is good, but I read on there that people said it was out of date and that it wouldn't work. Did you have to downgrade SteamVR/OpenVR or anything like that to be able to use it?

I'd have to look into how it actually changes the pose etc and if it could do it for the whole position with virtual desktop picking that up

When I went looking earlier I found https://github.com/Louka3000/OpenVR-InputEmulator-Fixed, which works for the pose based stuff, I use it to realign my tracker to the gun barrel on the latest SteamVR. I couldn't get the input remapping side of things to work though, I think that was broken at some point. OVRIE seems to be offset based in that it takes the current position of the device and just moves and rotates it, I don't know if it can be used to send hard coded values, although you could maybe have a virtual tracked point as a spoofed controller/tracker (via the client_commandline protocols), and then switch the tracking between the headset and that fake tracker to position it precisely for VD recentering. One other thing of note is that either redirect or swapping 2 devices in the interface causes it to crash, I think swapping is the one that works while redirect causes crashes.

Hard Drivin'/Race Drivin' cockpit in the mame driver only has this.

Code: [Select]

PORT_START("mainpcb:a80000")
PORT_BIT( 0x0001, IP_ACTIVE_LOW, IPT_START2 ) PORT_NAME("Abort")    /* abort */
PORT_BIT( 0x0002, IP_ACTIVE_LOW, IPT_START1 ) PORT_NAME("Key")  /* key */
PORT_BIT( 0x0004, IP_ACTIVE_LOW, IPT_COIN3 )    /* aux coin */
PORT_BIT( 0xfff8, IP_ACTIVE_LOW, IPT_UNUSED )

But all the rest have this?

Code: [Select]

PORT_BIT( 0x4000, IP_ACTIVE_HIGH, IPT_CUSTOM )  PORT_TOGGLE PORT_NAME("Center Wheel Edge")  /* center edge on steering wheel */
PORT_BIT( 0x8000, IP_ACTIVE_LOW, IPT_UNUSED )

I notice the highest memory address for these operations is on the steel talons/stun runner board that has this

Code: [Select]

PORT_BIT( 0xfff0, IP_ACTIVE_LOW, IPT_UNUSED )

Maybe the other function that could potentially be missing is lurking around within the 0x8000 to 0xfff0 range?

PORT_BIT( 0x8000, IP_ACTIVE_LOW, IPT_UNUSED )  actually is used in Airborne in the debug menu..........

Wonder what 0x9000, 0xa000,0xb000 etc would do?

Oh man... I'm not sure we are out of the woods yet.

Last night I played about with setting IP_ACTIVE_HIGH for the Compact Hard Drivin' roms yesterday. I have to say, I kind of think the correct thing to do is leave it at  IP_ACTIVE_LOW...

Setting it active high means the 'Centre Edge' thing (Seen in the Service Menu) is constantly on (Green), the 'Steering Wheel' value is held at 0x0000, and steering calibration is not possible (Which can't be correct). While you can skip the service menu to play the game, and observe the car re-spawns always with centred steering (which is very good to know and well found by yourself), it feels to me like we are building on a side effect of doing something that we shouldn't be doing. Without fully understanding what should be happening...

Another spanner in the works is that I also think for these compact roms, the steering control should probably be an IPT_DIAL (which has unlimited rotation) rather than an IPT_PADDLE (that has limited rotation), to reflect the actual arcade hardware.

 

 
Thats why i only have it set high for racedrivc the others i left alone. It just makes the game playable. My feeling is that those functions you sent from the hard drivin' compact manual with memory addresses 404000,404000 and 408000 are not being used properly........i think that the devs have made the game only use one of them to do a job that the other one is meant to carry out when it reaches the centerpoint?

Code: [Select]

From the Race Drivin' Compact Manual, for the Main Board Memory Map, it says:
OPTO: Optical Steering Wheel Reader
400000 (R) OPTORD Read the Optical Counter
404000 (W) OPTORES Reset the Optical Counter
408000 (W) CENRES Reset the Optical Centre Flag
I have a hunch that only the middle one is being set or the last one? In mame when we press that wheel edge button to manually activate it the counter suddenly becomes 0000.........that sounds like it's activating the middle function which kinda makes it seem like it's doing it's job because suddenly the wheel will think thats the centerpoint?  Shouldn't it be activating the last one to be setting in stone what the actual centerpoint is? Where in the mame code is the other function? I only see the one wheel edge function mentioned in mame driver code? What if the wheel edge in mame is linked to the wrong operation in that manual? Wouldn't that be the cause of it all? I think theres meant to be 2 flags or operations working together and from what i see in the mame driver code is only one operation/flag being used. I might be completely wrong but it's all my brain can come up with.

Last week I went to play California Speed (using the latest versions of MAME and FFB), I noticed that FFB gave some "hiccups" even when the cart wasn't touching anything. Doing some tests I saw that this problem originates in the FFB plugin version 2.0.0.34. I concluded that the last best combination for Cal Speed is MAME 0.257 and FFB 2.0.0.33. I think it's possible that this problem could also be present in some other game, but I'm not sure. I hope this information can help someone.

EDIT: In this test I used the Logitech G29 steering wheel. I will soon test the Thrustmaster T300.

Today I did the test with the Thrustmaster T300 steering wheel and the "hiccup" was present. This time the games tested were: Ace Driver, Ace Driver Victory Lap, Cal Speed and SFRush 2049 SE. They all had the same problem (very discreetly in both Ace Driver's). I decided to roll back to MAME 0.257 and FFB 2.0.0.33.

Specifically what did you change from auto to windows in mame.ini?

Change this . . .

Code: [Select]

#
# OSD OUTPUT OPTIONS
#
output                    auto

. . . to this.

Code: [Select]

#
# OSD OUTPUT OPTIONS
#
output                    windows


Scott

Mine is already like this. From what I know, if it's different, ffb doesn't work. That's why I thought it was another command.

In my mind the way to do it would be to have something like OpenVR Input Emulator fix the headset position in space to a preset location (with maybe fine adjustment to dial in calibration), click the recenter button on the program to set the screen angle and spacing, and then cancel the headset position so it goes back to the actual one.

This is a good idea. I did have a look at OpenVR Input Emulator and I had heard about it before with regards to changing the angle from the controller to the screen. It's open source which is good, but I read on there that people said it was out of date and that it wouldn't work. Did you have to downgrade SteamVR/OpenVR or anything like that to be able to use it?

I'd have to look into how it actually changes the pose etc and if it could do it for the whole position with virtual desktop picking that up

Oh man... I'm not sure we are out of the woods yet.

Last night I played about with setting IP_ACTIVE_HIGH for the Compact Hard Drivin' roms yesterday. I have to say, I kind of think the correct thing to do is leave it at  IP_ACTIVE_LOW...

Setting it active high means the 'Centre Edge' thing (Seen in the Service Menu) is constantly on (Green), the 'Steering Wheel' value is held at 0x0000, and steering calibration is not possible (Which can't be correct). While you can skip the service menu to play the game, and observe the car re-spawns always with centred steering (which is very good to know and well found by yourself), it feels to me like we are building on a side effect of doing something that we shouldn't be doing. Without fully understanding what should be happening...

Another spanner in the works is that I also think for these compact roms, the steering control should probably be an IPT_DIAL (which has unlimited rotation) rather than an IPT_PADDLE (that has limited rotation), to reflect the actual arcade hardware.

 

Code: [Select]

PORT_BIT( 0x4000, IP_ACTIVE_HIGH, IPT_CUSTOM )  PORT_TOGGLE PORT_NAME("Center Wheel Edge")  /* center edge on steering wheel, IPT_ACTIVE_HIGH fixes the steering alignment in game! */

OMG lol! I didn't try IP_ACTIVE_HIGH on 0x4000, only on 0x8000. I didn't change it on 0x4000 because it looked like it was doing the right thing in the service menu :p I honestly can't wait to try this later, nice one Yolo and well found!

I didn't try it either because i already tried it on Airborne and it didnt fix that or stop the behaviour that makes the wheel center get reset, but because i had made that button to activate it i noticed in the reacedrivc level select and car select screen that if i held the button down the wheel would follow my logitech g932 like it should so i just changed it to high to keep it on all the time lol

Another thing i will mention because it might help out in fixing airborne etc is that my wheel EMA code didnt work on street drivin'............i had to start the game then hit f3 to reset the machine and suddenly it would work fine.....i made a change to the code so that it would not send the EMA wheel info when the game boots up, it sends the unprocessed wheel info to the game and then switches to the EMA wheel. When i made this change it worked fine again. I have to change the port_minmax for all of the games for it to work with my code so to me it seems like all these different version of the game have slightly different ways or reading and calibrating the wheel positions which makes finding a fix for airborne maybe harder but as i said before i haven't had a proper look at the info you sent earlier as in i haven't actualy tried to use it yet.......i should give that a go today too once i have a few coffees in me 

The EMA wheel code can be manipulated to make the smoothing more or less aggressive and more aggressive will mean more lag between you moving the wheel IRL and it moving in game. The setting i have it set to in the code snippet below seems to be perfect and stops the wheel going out of alignment in airborne when you make erratic/fast movements. The lower the number the more EMA smoothing/latency is applied and the closer it gets to 1 the more responsive/less smoothing it will have. A EMA setting that works for a port_minmax range might not work if you adjust the port_minmax range to be more sensitive, you'll need to readjust the EMA to compensate for it so there is a balancing act in working out whats best.

Code: [Select]

static const float alpha = 0.082;  // Smoothing constant
I noticed that Hard Drivin' Compact has an other issue that it doesn't fix........the wheel seems to every so often try to go to another position for a split second and sems to make the car skid sometimes for no reason? I'll have another look at it today.