You guys ready?
BIG post.
Here's my view on the 12 way rotary (it's changed before though, so don't think I think this is "The Way It Has To Be"
).
The rotary is an absolute "analog" input that rolls over from min to max and visa verse, with 12 levels. Each level has its own digital switch. The original controller gives each switch it's own wire to plug into the PCB. The original games take the absolute analog data and convert it into relative analog internally. It could be argued (or treated) that the controller has 12 separate digital inputs, or that since the games used it like relative input the controller was really relative. (I'll get into these later.)
The mechanical rotary games I tested could have the rotary jump up to five (5) positions, with the player also skipping those five positions (150 degrees on the rotary, & 270 degrees on the screen). That means if one switch was bad and never closed, you could skip one direction every 540 degrees on the screen (depending how the original game treated no direction pressed, of course). The tests were done with 12 buttons connected as if they were the 12 switches in the rotary, using analog+ code.
Now, mame has three basic types of inputs: digital, absolute analog and relative analog, and PC inputs follow this too. (This is explained well in the source.)
Since the 12 way rotary can be argued as any of the three types, what should be done?
Well, from a programmer and user point of view, mame is great at the following input-to-input relaying (the first type being the physical PC input, the second being
mame's input type for the emulated game):
digital --> digital
absolute --> absolute
relative --> relative
relative --> absolute (note: mame's absolute stops at min & max and doesn't automatically roll over)
Mame is pretty good at:
absolute --> digital (with a limit of 2 digital per each analog axis)
Mame sucks at (
not saying it's mame's fault, and others might call it "okay" instead of "sucks", but it's less than pretty good):
digital --> absolute (note: mame's absolute stops at min & max and doesn't automatically roll over)
digital --> relative
absolute --> relative
Mame cannot (ATM):
relative --> digital
Notice how whatever input type mame uses, there is at least one physical type that at best sucks at feeding it, possibly the physical type can't feed it. And whatever physical type you have, it sucks at feeding at least one mame type. So from the
usability view, not everybody can be pleased at the same time.
Also notice how if the original controller was absolute that rolled over (like warlords, and IMO 12 way rotaries) and/or mame uses its absolute input type, spinners and keyboards don't roll over unless the source is hacked in the game's driver to cover roll over. This non roll over is perfect for most games (star wars with trackball, for example).
MameDev's current view is there should be one physical input in the driver per game input. Not sure if this is a goal of this view, but the number of inputs matches the original number, at the cost of not having "hack" ("usable") OR not having original inputs. It's very much a good KISS way of handling inputs. This is different from the past, and although much of the old code has been cleaned to match this, there still is old code out there that can be changed to match. So if game A does YYY, and game B does ZZZ, just means one of those games was written before this view was in place and wasn't updated yet. It's HARD to keep 6000+ games up to date in all aspects. Arguments based on "mame's inconsistency should be fixed" do NOT promote the importance one bit; some devs treat it the same as a noobie saying "add 'dis game NOW!!!".
Since mame is not about usability
, let's look at the ways the original controller could be treated.
Currently, mame treats the input as a relative analog input (dial). Alright, the (or maybe most) original games refine the original input into relative data, but the
original game software refines it, not the controller. Currently in mame, the driver takes the relative data, converts (possibly
reconverts if the core converted it from absolute to relative which mame sucks at) it to "absolute" (which mame does great) and sends the absolute data to the ROM. (Which the game converts back to relative.) This setup works best with spinners, but absolute and digital inputs work with problems. (Druin's interface sends digital left/right data.) Pluses for mame using relative type include the game treats the input as relative even though gets absolute, spinners work, works on all PCs, and it's the current setup. Minuses include original controllers (raw or with interfaces) don't work well, it's doing the work the game ROMs do, and obscures the original inputs deeper into the source than most other inputs and totally out of mame's input UI.
RandyT, Mame takes the relative data (which is stored in a 256 value rolling counter) and multiples by 12 and divides by 256. In integer. This means rounding, which is why you get the two values in ikari. Looks like timesold has same sensitivity as the other games, but a lower keydelta (keydelta shouldn't effect mouse inputs but seem to in small and mysterious ways). It still is weird that timesold needs between 19 & 23 steps. I could see it was the rounding problem if it took say 20 or 22, but with the range you list, it might be something else too.
The reason Druin's interface doesn't work perfectly is that it "holds down a button" for a given amount of time for each mechanical click. Mame reads the digital input and translates it to relative, the "delta" based on how long the button is pressed. If the timing is not perfectly matched to mame's settings (keydelta & sensitivity), the microseconds add up and finally show up as a missed signal. If the timing is bad, you see it every other click. This is done in the core, not the driver, and is about as good as you can get when converting digital to relative.
If mame's input type is changed from relative to 12 digital inputs, you could hook up the original controllers through any interface with 12 free digital inputs (aka buttons)
as long as it's okay with one always closed. (Or the interface and mame could be set up to remember the current direction so that it doesn't need to send the closed switch all the time.) Major problems arise when you try to use a spinner or almost any other input besides an original controller. But the original controllers work great this way.
If it is changed to only 2 digital inputs (left/right), spinners wouldn't work. Absolute would suck, but any device hooked up to something like Druin's interface would work pretty well.
If it is changed to absolute, spinners and keyboards would run into the roll over problem. Original controllers would need new interfaces to hook up as an absolute joystick (much like the GPwiz49). A pot based spinner should work. But almost nothing out there in any quantity would work correctly, even though IMO the closest to what the original was.
The way to please most users would be to give them the choice of mame using any of the above. However, it would either complicate the input UI and the driver code big time, or need a big rewrite of mame's core UI and input handling. Either way, this way would conflict with the current KISS policy about inputs and if done incorrectly
really complicate the driver, just for usability purposes. IOW, it would not be accepted unless it was done very cleanly and (my guess) 100% within the core code.
FWIW, Analog+ added the 12 digital and the 2 digital input ways on top of the spinner way. It was implemented (hacked) on the driver level, and not correctly in all games, so it isn't mame acceptable for these two reasons.
Home
Help
Search
Login
Register
Send this topic
Print
Topic: Fixing MAME's handling of 12-position rotary controls (Read 18227 times)
