Recent Posts

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.

I've made a change to the OpenVR2Key program and now it will hold down the mouse click while the button is being held down on the controller. I'll attach the updated version.

Works great now. Had no problems using it in Blue Estate (which needs a continuous reload for the shotgun, probably one of the only games that do). It occasionally seemed to send a left click instead of a right click in M2 emulator, but I'm pretty sure that's an issue with the emulator or the game rather than OpenVR2Key, I've had similar issues before when trying to spam, and I can get similar behavior with a mouse by going too fast between left and right click. Still, got me through a full run of VC2 with very little issue, which is something I haven't been able to do in a while.

So it seems that Virtual Desktop will save the size and distance settings but when you start it again the rotation and position will be out depending on where the headset is in space.

The only thing I can think of at the moment would be to intercept the openvr_api.dll that is in the program folder and send a saved set of rotation/position co-ords to the virtual desktop exe when the program first starts up. And then it will need to resume normally after that.

I think it's possible but will take some time to work out. Also it will need for a position to be captured while setting it up that can be used to replay via dll as it will be specific to your lighthouse setup / monitor position.

Yeah, seems like a pain. I find recalibrating VD to not take that long, 2 or 3 attempts get it close enough across most of the screen. Setting up the screen dimensions is the fiddly part, and at least that saves. 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. I imagine if you did it while wearing the headset you'd want to throw up, though.

By the way, I also found while searching there is another virtual desktop type app called Desktop+ , it's free on Steam and is also on github with source code.

But I think maybe it's not going to be as good as VD.

I gave it a try and the tracking latency seems halfway between VM and VD, but the problem with it is that when the headset goes to sleep after 20 seconds it stops letting a controller act as a mouse, so it's no good. I think it also interferes with OpenVR2Key because it's part of the dashboard and OVR2K is blocked there (although I think older builds didn't have this functionality).


I've also noticed that when a tracker is set up as a controller, the pin for the touchpad button doesn't seem to do anything. Which means I've got to use the menu button instead, which is another point against vive mouse because it uses that input to disable the cursor. Not a huge number of games need more than 2 buttons, but it's a point of consideration.

Ah, maybe I didn't make it clear, I was talking about Virtual Desktop when it came to remapping, it has a bindings page. OpenVR2Key works fine with my Vive controller/tracker even on the newest release.

I think I just got confused and I saw the author of OpenVR2Key say he didn't have a vive anymore only index so it made sense.

But this is pretty handy anyway. The only issue is there's no repeating function which I think is a limitation of the program to begin with, if you hold a button down it only sends the input once, which means it's not very useful for games with machine guns.

I've made a change to the OpenVR2Key program and now it will hold down the mouse click while the button is being held down on the controller. I'll attach the updated version.

If it were possible to get Virtual Desktop to remember the last window position to essentially save the calibration, it'd just be superior.

I tried out Virtual Desktop, I had used it on the Quest but didn't realise it was a different app on PC. So I can see how you align it to the screen, moving it's rotation and position and then changing size and distance.

So it seems that Virtual Desktop will save the size and distance settings but when you start it again the rotation and position will be out depending on where the headset is in space.

The only thing I can think of at the moment would be to intercept the openvr_api.dll that is in the program folder and send a saved set of rotation/position co-ords to the virtual desktop exe when the program first starts up. And then it will need to resume normally after that.

I think it's possible but will take some time to work out. Also it will need for a position to be captured while setting it up that can be used to replay via dll as it will be specific to your lighthouse setup / monitor position.

By the way, I also found while searching there is another virtual desktop type app called Desktop+ , it's free on Steam and is also on github with source code.

But I think maybe it's not going to be as good as VD.

I do have the ultra small form factor optiplex 3020 if that matters.