Main > Main Forum
Fixing MAME's handling of 12-position rotary controls
Minwah:
--- Quote from: XtraSmiley on January 31, 2006, 08:41:23 pm ---I'm just a little confused as to why the MAME guys don't want to fix this. Has anyone tried to just email Aaron or post on his website? I realize he hates when people contact them and beg for games, but this is a totaly different issue. I don't mind doing it, but I just don't understand all the ins and outs yet.
--- End quote ---
IIRC it was Aaron who removed the dial input stuff for 720....he was challenged at the time and wouldn't back down unfortunately.
Dav:
--- Quote from: XtraSmiley on January 31, 2006, 08:41:23 pm ---I'm just a little confused as to why the MAME guys don't want to fix this. Has anyone tried to just email Aaron or post on his website? I realize he hates when people contact them and beg for games, but this is a totaly different issue. I don't mind doing it, but I just don't understand all the ins and outs yet.
--- End quote ---
Because from the mamedev point of view it's not broken. Writing code to support a third party adapter for sticks almost no one has is not something they want to do.
You can add showdown to the list of games that need some kind of switching input type. It autodetects the input device and then writes it in nvram so I'm not sure how to fix it without making 2 games out of 1 rom set. Just switching inputs won't help unless you delete the nvram. :(
RandyT:
--- Quote from: Dav on January 31, 2006, 09:27:03 pm ---Because from the mamedev point of view it's not broken. Writing code to support a third party adapter for sticks almost no one has is not something they want to do.
--- End quote ---
Who are the first and second parties? This is something that I don't quite get. They obviously can't write code for the original hardware (first party), and the MAME devs don't do physical hardware (second party). As MAME is supposedly a "documentation" effort, would not somehow making the original controls work on the new hardware platform be an important part of fully documenting the machine?
The argument could be brought up that they are documenting only circuitry. But if that were the case, all of the input routines would be fully functioning but nobody could play. So obviously, that isn't the standard.
Seems like just about anything that would allow the original controls to work on the hardware platform doing the emulation would be more accurate from a documentation standpoint than just making everything work as well as it can on a mouse, keyboard or gamepad. And since you can't actually connect the original control directly to the foreign hardware, something is going to have to bridge the gap.
And I don't think I would consider writing an input routine to rotate based on a cycling input "Writing code to support a third party adapter." This is far more accurate to the way the game was actually played than just holding the input in a single state. Every click of the rotary required a conscious effort on the part of the gamer and, depending on play style, a mental count of the clicks. Each action was independent. You can do this by cycling a button, but it is impossible to achieve by merely holding it down.
I'm not ranting, even though it may look that way. Just trying to follow the thought processes :)
RandyT
Dav:
--- Quote from: RandyT on February 01, 2006, 12:00:29 am ---
--- Quote from: Dav on January 31, 2006, 09:27:03 pm ---Because from the mamedev point of view it's not broken. Writing code to support a third party adapter for sticks almost no one has is not something they want to do.
--- End quote ---
Who are the first and second parties? This is something that I don't quite get. They obviously can't write code for the original hardware (first party), and the MAME devs don't do physical hardware (second party). As MAME is supposedly a "documentation" effort, would not somehow making the original controls work on the new hardware platform be an important part of fully documenting the machine?
The argument could be brought up that they are documenting only circuitry. But if that were the case, all of the input routines would be fully functioning but nobody could play. So obviously, that isn't the standard.
Seems like just about anything that would allow the original controls to work on the hardware platform doing the emulation would be more accurate from a documentation standpoint than just making everything work as well as it can on a mouse, keyboard or gamepad. And since you can't actually connect the original control directly to the foreign hardware, something is going to have to bridge the gap.
And I don't think I would consider writing an input routine to rotate based on a cycling input "Writing code to support a third party adapter." This is far more accurate to the way the game was actually played than just holding the input in a single state. Every click of the rotary required a conscious effort on the part of the gamer and, depending on play style, a mental count of the clicks. Each action was independent. You can do this by cycling a button, but it is impossible to achieve by merely holding it down.
I'm not ranting, even though it may look that way. Just trying to follow the thought processes :)
RandyT
--- End quote ---
The way the ls30 works is by dectecting movements up or down. As has already been mentioned there is no 1:1 relationship between the position of the stick and a position of the players sprite. You move 3 clicks clockwise and the binary number goes up by 3. That is pretty much exactly the way an analog spinner works. You move a wheel so many notches and the binary number the rom sees goes up. If you move a tempest spinner x number of degrees the sprite moves y number of degrees. Pretty much all spinners I can think of except Omega Race work like that. I don't see how it's that much inaccurate to treat it as an analog spinner. The only difference is you don't feel the notches. What's inaccurate is letting people control an analog spinner with 2 buttons. You are correct, that should probably be removed. :)
RandyT:
--- Quote from: Dav on February 01, 2006, 01:02:59 am ---The way the ls30 works is by dectecting movements up or down. As has already been mentioned there is no 1:1 relationship between the position of the stick and a position of the players sprite. You move 3 clicks clockwise and the binary number goes up by 3. That is pretty much exactly the way an analog spinner works. You move a wheel so many notches and the binary number the rom sees goes up. I don't see how it's that much inaccurate to treat it as an analog spinner. What's inaccurate is letting people control an analog spinner with 2 buttons. You are correct, that should probably be removed.
--- End quote ---
I disagree. While the motion may be similar, the two have about as much in common as the current button method does.
A spinner works on a principle known as "step and direction." The device takes one step in one direction or the other and this is all the information it transmits. One could say that a spinner has only 3 states. Idle, moving forward and moving backward. That makes it a relative positioning device.
The LS30 has 13 connections, presumably 12 contacts and a common. So this would mean, as urebel demonstrated, that the device has 12 distinct states, one for each possible direction. The interesting thing about this device is that it is an absolute positioning device that can be used as a relative device for games with less (or more) than 12 possible positions.
Aside from the electrical differences, the most important one is physical. There is absolutely zero tactile feedback for the user to know that he has moved one position one way or the other. Overshooting and undershooting the move is still a problem, even with the spinner, because the motion is continuous. The user has no way of knowing how close or far away the next "click" is that causes the player to index to the next position.
However, if every cycle of a button causes exactly one index, this would be far more accurate. If anything, the spinner support should go (note: I am not advocating this. More options are always better than less.)
Here's a simple way to think about this. A hardware interface for this purpose does nothing but attempt to translate the output of a device to a form expected by the computer/software. As it currently stands, it is impossible to implement such a device, because it is impossible for a user to control the software properly. Were such control possible by the user, then that control could be automated by an external device. To be honest, I really don't know what to say to anyone who reads this and still thinks there isn't a problem.
BTW, I advocate a step and direction solution. This can be handled as part of the input routines (provided the polling is fast enough) and would require only 3 inputs on any input interface (provided there were no problems with a constant "on" input.) In the event that MAME does not poll quickly enough, the next option would be some tricks in hardware and a INC and DEC input that acted only once per cycle. Having both of these solutions available would make virtually any rotary game absolutely controllable, regardless of whether a rotary switch or buttons were used to index the player position. It would also work regardless of external specialized hardware.
RandyT