Main > Main Forum
Fixing MAME's handling of 12-position rotary controls
<< < (15/17) > >>
Tiger-Heli:

--- Quote from: RandyT on February 01, 2006, 09:38:40 pm ---
--- Quote from: RobotronNut on February 01, 2006, 09:19:47 pm ---
--- Quote ---I just verified incorrect operation with both Time Soldiers and Ikari.

--- End quote ---

RandyT - try the same experiment with MameAnalog+ 0.83.2; it is claimed to handle Ikari perfectly.


--- End quote ---

With the spinner?

I was under the impression that Analog+ only made the change of adding new button inputs to do this, not modifications to the spinner portion.

Am I missing something?


RandyT


--- End quote ---
Analog Plus gives you at least three different control options -

Dial for rotation - Same as standard MAME (AFIAK).

Button 4 and Button 5 for Rotation - Each button press results in a single click - Analog Plus is supposed to work perfectly with Druin's Interface using this method.

Directly, mapping Player 1 to P3 Buttons 1-10 and then P1 Buttons 9 and 10, and for Player 2 to P4 Buttons 1-10 and then 2 Buttons 9 and 10. - Analog Plus is supposed to work perfectly with this method, but it works in Time Soldiers and not Ikari or Victory Road.
RandyT:

--- Quote from: Tiger-Heli on February 02, 2006, 10:36:08 am ---Same as standard MAME (AFIAK).

--- End quote ---

Unfortunately, that's starting to look like it means "broke."  That's too bad.  I thought Dave had brought up an approach that might have some possibilities.  Unfortunately, that one doesn't seem to work right either.

So, I guess it's back to my original statement.  Neither the user nor an external interface is able to accurately control this type of action on these games with the official distribution, which is why no properly working interface can be offered.

So, the ball appears to be in the developers courts to provide at least one absolute method for controlling these things and the MAMEdevs to acknowledge the problem and make it part of the official distribution.

RandyT
Kremmit:

--- Quote from: RandyT on February 02, 2006, 10:56:51 am ---
So, the ball appears to be in the developers courts to provide at least one absolute method for controlling these things and the MAMEdevs to acknowledge the problem and make it part of the official distribution.


--- End quote ---

That's what I've been saying since page 1.  But even if the devs don't want to add it to the official distro, if some input genius were to fix the problem, there's no reason it can't exist as a .dif file or in an alternative build, ala Analog_+.
u_rebelscum:
You guys ready? ;D  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. ;D


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.
Dav:
I just took a look at time soldiers.   It uses absolute positioning.  It works great defining the 4 raw encoded bits as buttons 5-8.  I think the spinner is off on it possibly because there are dead spots.  instead of 1-12 like I was expecting the valid values are:  0/1, 2, 3, 4/5, 6, 7, 8/9, a, b, c/d, e, f.

I took a look at bermudaa also.  It uses the 4 bits like a spinner.  Defining the 4 bits as buttons and trying to play gave a little control but not much.  I desoldered the decoder on my board and made an adapter to dump it.  It encodes the 12 bits as 0-11binary  so there's nothing tricky going on with that.  Still it would probably work with the ls30  it would just require subs in to match the 4 bits to what the roms were expecting.

I'm real curious why guerrilla war doesn't like going from 5 to 6.  Possibly it's like time soldiers and 5 is not a valid value. 

It seems to me that if i wanted the original sticks to work then hooking it up with the 4 encoded raw bits would be pretty easy and cheap.  At least on the ones I looked at.


Navigation
Message Index
Next page
Previous page

Go to full version