Main > Driving & Racing Cabinets
Universal Gear Shifter support in MAME discussion
abaraba:
--- Quote ---SavannahLion:
- An ideal interface might look like this...
BadMouth:
- Here are my thoughts on how it might work from the UI...
--- End quote ---
He has most of that sorted out, he says:
- The Player controls UI would only show "P1 Gear Shifter Setup"
- Selecting it will open new menu that allows you to select...
* This would have to be resolved with some FAKE/REAL control scheme
1.) The only problem there is "fake/real" scheme itself. If he wants to be opening new windows in tab menu I am afraid new command line option must follow, and if that's fine then all is solved here. -- If not, there are other ways.
2.) His actual "CONCERNS" you can find at the end of that message. He says switch could be held in ON state when the UI is selected and that may mess up the UI input selection. -- I'm puzzled. Why is this concern when user can shift to second gear and release the switch on HI/LO, while 4-gear shifters only need to be put in neutral.
I'd say the only problem in the whole story is just to somehow separate mapping of 'toggle' vs. 'normal' switch. I believe MAME UI already implements timing of input when controls are being redefined, so to map 'toggle switch' you could hold longer, while just quick tap would map 'ordinary switch'.
BadMouth:
Another thought on the gear shift port being state aware:
It's not like we're trying to determine mario's position on the screen or which character was selected.
The gear is a switch. The state of that switch has to be maintained in the driver somewhere.
So it might be possible to have the gear shift port get the state of that switch from the driver instead of keeping track of it itself.
Of course, it may not be identified the same way in all drivers.
abaraba:
--- Quote from: BadMouth ---Another thought on the gear shift port being state aware:
It's not like we're trying to determine mario's position on the screen or which character was selected.
The gear is a switch. The state of that switch has to be maintained in the driver somewhere.
--- End quote ---
The state of switch is polled, it's only for hack routines that need to know 'last state' so to figure out in what gear to change. This is all already implemented, hacks are there, that's how it works now. But proper routines are also there, we just need a variable to tell us what kind of input is currently mapped and execute appropriate code accordingly.
REAL/FAKE scheme is nonsense. Just like with 720 where we only need to distinguish whether the input data is 'analog' or 'mouse', similarly here we again only need to figure out whether the input is mapped to 'toggle' type of switch or not.
--- Quote from: BadMouth ---So it might be possible to have the gear shift port get the state of that switch from the driver instead of keeping track of it itself. Of course, it may not be identified the same way in all drivers.
--- End quote ---
I have no idea what problem you are trying to solve.
There are no problems really, only imaginary ones. We do not need any REAL/FAKE scheme, new tab menu, or new command line options. All we need here is classification of switches, and just like there is 'analog' and 'digital' joystick classification, so there should be 'toggle' and 'spring-back' type of button/switch/key.
* Proposed HI/LO shifter mappings:
Gear Shifter ------------- Space
Gear Shifter ------------- Space (toggle)
Gear Shifter ------------- Joy_Button1
Gear Shifter ------------- Joy_Button1 (toggle)
Gear Shifter ------------- Caps Lock
Gear Shifter ------------- Caps Lock (toggle)
If the switch/key is mapped as toggle driver executes routine for authentic functionality, and if it is mapped 'normally' then driver goes for the hack, that's all there is to it. -- So, the solution to all the problems with 'shifter affair' is basically just about providing an option to map a switch/button/key as either toggle or not, and this control scheme should solve the whole problem, not only for HI/LO shifters, but 4-gear shifters as well.
BadMouth:
The Hi/Lo thing is only a small part and yeah, the hack to the driver can be reversed. It's been done before.
--- Quote from: abaraba on January 15, 2011, 09:55:58 am ---
--- Quote from: BadMouth ---So it might be possible to have the gear shift port get the state of that switch from the driver instead of keeping track of it itself. Of course, it may not be identified the same way in all drivers.
--- End quote ---
I have no idea what problem you are trying to solve
--- End quote ---
The bulk of mame users probably play driving games with a gamepad or standard pc racing wheel.
Except for more expensive wheels, these do not have physical shifters that stay in gear.
Most of them have paddle shifters and maybe a sequential shifter on the side that works no differently than the paddle shifters.
One goal would be to give these users (who are the bulk of the user base) the ability to use their paddle shifters on games that originally had a 4 or 6 speed shifter. To do this, there would have to be an option for GEAR UP and GEAR DOWN.
Something would have to keep track of what gear you are in, so it would know which "fake" gear switch to throw when you press GEAR UP.
We're talking about a universal system that takes just about everything into account, not just hacking (or unhacking) the driver of every game we want to "fix"
Please just go away. :(
abaraba:
--- Quote from: BadMouth ---We're talking about a universal system that takes just about everything into account, not just hacking (or unhacking) the driver of every game we want to "fix"
Please just go away.
--- End quote ---
You go away with your imaginary problems.
What you're talking about is already there, it is part of global 'analog hack'. The only thing that is not (quite) there is 'toggle' type of button. And again, we do not need fake/real scheme, all we need is proper classification and identification of input devices, so to be able to execute appropriate code accordingly. That would make everything work: authentic shifters, keys, paddles, spinners, analog sticks... since each type of device could have its own separate handling routine, if necessary.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version