MAME games ->non standard controls

[rampy]

I was poking around playing MAME last night trying new games (new to me that is) and fired up pound for pound (a boxing game)...  since I never played it in the arcade I have no idea what the configuration/controls are/were.

No matter how I mapped sticks/buttons I couldn't only left jab... Any clues on how it should work (yup I'm gonna check klov in a minute)

I also fired up Hevyweight Champ because I used to like that boxing game (but of course remembered the swivel monitor and the multi axis punch levers... )  is there a good wa;y to map the controls to a 2 stick 6 button each setup to make it playable?

On a more general note... maybe part of the FE spec (in a different thread here) could have a module that further catogorized or documented suggested mappings or game instructions... or something.... (sometimes a random game is intuitive enough, ok.. jump fire manuever... other times it's like huh?)  

I know people manually create jpg/gif/png's of simulated control panels on some frontends explaining specific to their cabinet which buttons to press and what does what... but I think a more generalized system/info repository would be helpful....

rampy

rampy

[Howard_Casto]

There is a thread regarding this somewhere in this forum. Simply put, what you ask is an incredible undertaking.  We talked about it and realized how much work woudl be involved and it kind of fell out of favor.  There are over 3000 games in mame you know and each one would have to have a cp mock-up made.  Besides that it's really hard to find the control layout for some games.  

[Minwah]

It would certainly be handy if MAME -listinfo gave a more accurate 'control' description.  eg separate rotational joysticks from 'dial' games, and 2-way joy's separate from 8-way games etc.

I guess any frontend could be made (some already do) to display how many buttons are required for each game - this would be some help at least.

[rampy]

heh, I didn't say it was easy... I'll do a quick search for that thread, do you remember any key words from the discussion or its subject?

FWIW a quick search on KLOV showed me that the pound for pound game had trackballs for a control system... strange.

well, one would think recreating the hardware in software to 3000 games would be a challenge too, but if a process was designed well, and enough people contributed... given enough time I'm sure some sort of optional .dat/.info file could be created.  But you are probably right, it's unlikely given the scope of what's needed.

I'm sure I've seen a custom example where someone added renderings of their control panel with instructions for games (probably not all of them though =) )

rampy

[Lilwolf]

I've spend a great deal of time generalizing the controls for jfront.  But it only works on 90-95% of the games.  Then you have to custom setup the rest.

troubles.  Number of players is recorded instead of number of controllers (so there are a ton of 4player games that really only had 1 controller and you switched)

Then from there... I could see using either the historical.dat to store additional info, or try to come up with a standard like the catver.ini (it's really only nice if you can save the file and send it around)...

but even then... your still in trouble in that I could define the game itself... but you would need to somehow describe the inputs on your controlpanel... and thats assuming you only have one.  Then I would have to build a default.cfg or one of the newer ini files.

Anyway, I'm looking into removing some features for the next jfront and working with some new controller ini files in mame for the next version.  I might take a look at characterizing the controls per game and building something... but don't expect it soon.  It's not what I'm focusing on right now and I'm not getting much done either.

[Howard_Casto]

The problem I've ran into (I have tried to make a system.)  Is figuring out what button does what....

Example:

All street fighter games have the exact same layout and the same name for buttons.  (Strong/medium/fierce kick and punch) The problem with that is if you made a generic template as lilwolf suggested, it's hard to group them.  If you went with generic names (button 1,2,3 ect) then the layout would be useless.  On the other hand if you used specific names there would be literally thousands of descriptive names to keep track of.  

I think I've finally figured out a good framework for an app though which I'll put in a post below this one.

[Howard_Casto]

Ok this is a long one and it would be much more complicated than what you guys were thinking, but here goes....

I at first thought that a catver style dat file would be enough, but upon further inspection and the recent addition of the ctr files in mame this is what I thought of.  

The file would be listinfo like with a format similar to the following...

[sf2]
cloneof=
players=2
alternating=no
controltype=joy8way
button1=light kick
button2=medium kick
button3=fierce kick

and so on...

a little explaniation of those fields.....

clone of is NOT the clone of you think of for roms... this is a layout clone.  If you don't want to have to bother typing in the same layout over and over on a per-game basis, you could define a clone name and it would simply read that games layout into the display.  This way you could make a cps2 layout, a 4 player layout ect and not have to repeat your work.

alternating tells the display wheater to highlight the second, third, or 4th players controls.  Pacman, for instance is 2 player but you can only use player 1's controls even in 2 player mode.  

control type tells it wheather to highlight an 8way, 4 way or misc control... if you don't have one of those, it would default to whatever you defined in your cabs skin file, but more on that later... i don't want to confuse you...  

The buttons could also be adstick x axis or lightgun x or whatever depending upon the game... the key would be to name them how mame names them so that the display wouldn't get confused and some standardization could be kept... if a description isn't given for a button or an entry isn't made for that button at all, the display assumes that this button isn't used in this game and ignores it when drawing the layout.....  


Anyway, on to this display.

I propose a universal, external, viewer that could be called from within a front-end or used as a standalone guide.  I am even willing to make it myself if there is enough interest.  

The viewer would allow you to make skin files.  The first, and most important skin, would be the default skin.  With this skin you can make a replica of your mame cab's personal layout.  The skin file would basically consist of a background image of the cp from an overhead view and coordinates to where buttons are placed.  The skin maker would have pre-rendered buttons in every color made as well as a greyed out button to signify a button that won't be used in a game.  There would also be pre-rendered gifs of joysticks, trackballs and ect that you would use to position the sticks.... all of these images would be external and you could tweak the graphics to your liking, of course.  Each button or stick position can have shared values.  Let's say you don't have a trackball, for example... you assign the trackball to the same position as the 8way and use the same graphic.  Now when a trackball game comes up it shows the 8-way stick so your users don't get confused.  The caption for the type of game would be "trackball" though, so that you understand this.

The viewer program could be launched stand-alone, with some sort of menu system or like this......

cpview.exe romname skinname

If the skin name is left out, it first checks to see if there is a skin named after the romname you passed.... if not then it uses the default skin you made.  it is crucial that we allow this romname based skin lookup as others might want to make true to life re-creations of layouts for preservation purposes.  Of course you would be able to turn off this autolookup in the options.  

Once inside the viewer you would be presented with a nice layout image.  The buttons defined in the skin file would all be in color with a caption of their use overlayed on top.  Buttons not defined (buttons not used for that game) would be greyed out, to make it easier to follow.  As a totally optional feature, you can define keys in your viewer that tells it what the actual keyboard keys are based on your encoder setup.  When you press these keys in the viewer the button graphic is replaced with a picture of a depressed button of the same color.  This gives the illusion of pressing the buttons. When you press the escape key, or whatever key you have defined to exit the viewer, the viewer would exit and you would be returned to the frontend it was launched from.  This key can optionally be defined in your skin files as "uiexit" along with a few other choice special keys... these buttons are always shown regardless of the game and have appropriate captions.  This way users will know how to exit the viewer with a nice caption like "press this key to exit"

Oh and one more thing.... each skin file would require default captions for each button or control stick... this way if an entry isn't found for a particular game, it will at least show your cp layout and the default functions of the buttons (probably something simple like "button 1")


Anyway... that's my big idea what do you guys think?  

[rampy]

Hi Howard,

that seems like a very workable approach!  You seemed so down on the feasibility of the idea, and yet came up with a good approach.  


Good job,

Rampy

[bhille]

HC,

That would be awesome!  I really like the idea you had.  I wish I knew something about programing or rendering so that I could help undertake this.  I really hope you decide to implement this.  I think this is exactly what mame cabs need to make them user friendly (so I don't have to stand by it at parties explain how to use it!).

Brian

[Minwah]

Sounds cool.  Surely the most daunting task is creating the complete controls file accurately...

[bhille]

Sounds cool.  Surely the most daunting task is creating the complete controls file accurately...

That's a good point.  I'm sure that Klov runs on some type of database.  Couldn't we get a copy of that database and then just write a conversion macro/util to put the data in the right format?  Otherwise, maybe we could create a form or something and then split up the work.  That way no one person has to look at all 3,000 games.  Thoughts?

Brian

[SirPoonga]

It would certainly be handy if MAME -listinfo gave a more accurate 'control' description.  eg separate rotational joysticks from 'dial' games, and 2-way joy's separate from 8-way games etc.

I see that as the biggest thing keeping FE's from know what controls the games usus.  Look up dotron in listinfo once,  YUCK!

[Minwah]

Trackball eh?

It seems odd that there's no way to distinguish between analogue stick & 270degree wheel too.

I guess there's a good reason for it, maybe for easier handling of controls within MAME?

[Howard_Casto]

I would say that the internal mechanics are indeed less specific and that's why it is inaccurate.  At least from what I've seen of the source.  

Btw Klov isn't very accurate either... I have noticed various screwups in their database which are small, but an anal retentive guy like myself catches them.  One of the biggest goofs I saw was them reproting that Street Fighter 1 was a 6 button game.  SF1 was a two three-way button game.  Now due to the fact that these pressure sensitive buttons were delicate, they were replaced with the now famous 6 button layout in revision 1 of the game, but klov didn't mention any of this.  If they can screw up that bad then I figure they have other errors, although they are the most accurate I've seen. Their database is quite easy to extract info from btw... someone with experince making bots could probably get it quite easily.  

Anyway I'm glad you guys like the idea and after one more release of lazarus I will probably start to work on it.

Some of you seemed to have an interest in helping and trust me there will be work to be done.  If you guys think I can make a list for all 3000 games then forget it... I will expect a lot of help from the community to make these files and I will complie them into a single list periodically.  If you guys are really all for this, what I will do is post a list of all the games being worked on so that you guys don't repeat work and you can send them to me.  Even if it's just one game it would help a lot.    This will be similar to the mameinfo project in that it will take a handful of people, at the very least to get it done.  

Another question is how do we match the mame name of the button to the caption when the data is collected?  Unfortunately the only way to do it is manually.  Klov is good about putting the buttons functions but they are in the order they appear on the arcade control  panel, not the way mame numbers them.  A good example of this is the mortal kombat games as they have a wierd layout.  You pretty much have to re-define those buttons anyway so that might be another issue, which I think could be fixed with a secondary set of skin files. Just for those special games that require remapping.  Or perhaps custom button name support, like mkbutton1 or ect.... any ideas on this problem?

Also I stole this whole idea from the new crtlr files of mame, so don't give me too much credit.  

[SirPoonga]

Some of you seemed to have an interest in helping and trust me there will be work to be done.  If you guys think I can make a list for all 3000 games then forget it... I will expect a lot of help from the community to make these files and I will complie them into a single list periodically.  If you guys are really all for this, what I will do is post a list of all the games being worked on so that you guys don't repeat work and you can send them to me.  Even if it's just one game it would help a lot.    This will be similar to the mameinfo project in that it will take a handful of people, at the very least to get it done.  

First, I think some of this should be fixed IN MAME!
Second,  I'd focus on parents first.  The FE, MAME, whatever would goto the parent for controls if the clone doesn't have any defined.  Kinda like the ini files in mame.

Another question is how do we match the mame name of the button to the caption when the data is collected?  Unfortunately the only way to do it is manually.  Klov is good about putting the buttons functions but they are in the order they appear on the arcade control  panel, not the way mame numbers them.  A good example of this is the mortal kombat games as they have a wierd layout.  You pretty much have to re-define those buttons anyway so that might be another issue, which I think could be fixed with a secondary set of skin files. Just for those special games that require remapping.  Or perhaps custom button name support, like mkbutton1 or ect.... any ideas on this problem?

Explain this more?  What is the layout of mk buttons?  what does mame use?

[cdbrown]

MK button layout is like

0  0
 0
0  0  

I think top row is high kick and punch, middle row is block and bottom row low kick and punch.  Mame then usually translates to ctrl, alt, space, shift, z don't know which order though.

Before the task of listing all of the different controls out I guess you need to sort out a couple of rules stating Button 1 is always going to be the button on the top row at the left.  Button 2 is then on the right  but still on the top row, 3 next on the right (but if there's no more on that row, go to the next row down and use the leftmost button) and so on.  This may at least give some continuity.  It would be up to the individual user to change these layouts to their own preferences but as long as a standard is in place and is used it should be straight forward as a means of collecting the info.

Of course some people may not remember the exact layouts and provide some misinformation regarding what is button 1 and 2, but I'm sure someone would spot it and point it out for change.

I think this is a great idea and would like to help if I can.

Cheers
-cdbrown

[Lilwolf]

btw, SF1 came in both flavors (2buttons and 6 buttons).  The 2button version broke really quick so Capcom replaced them with the 6 button version.

[SirPoonga]

Before the task of listing all of the different controls out I guess you need to sort out a couple of rules stating Button 1 is always going to be the button on the top row at the left.  Button 2 is then on the right  but still on the top row, 3 next on the right (but if there's no more on that row, go to the next row down and use the leftmost button) and so on.  This may at least give some continuity.  It would be up to the individual user to change these layouts to their own preferences but as long as a standard is in place and is used it should be straight forward as a means of collecting the info.

Of course some people may not remember the exact layouts and provide some misinformation regarding what is button 1 and 2, but I'm sure someone would spot it and point it out for change.

No, you need to go by the button number mame uses.  

I think I realize what HC is talking about now.  Everyone's control panel is different, games can have different controlspanels.  I think HC is talking about translating the button layout to your CP.
Like, we know MK1 has 5 buttons in that format.  Many home CPs are like:
456
123
Many people map MK1's controls like
4X5
123
Anything using the data collected to map the controls on screen (in an FE) will not know that.  Since the reconfig of the buttons can be done in two spots, the game.cfg file or the /ctrlr/game.ini file.

[Howard_Casto]

btw, SF1 came in both flavors (2buttons and 6 buttons).  The 2button version broke really quick so Capcom replaced them with the 6 button version.

Look up and read my post... I said that  Revision 1 fixed this... the only diference between revision 0 and revision 1 was the buttons included in the kits and on the dedicated panel.  

[u_rebelscum]

Late into this, but love the idea Howard!  I have some games I would not mind playing, I mean studying , and getting the needed stats.

No, you need to go by the button number mame uses.  

I have a tab delimited table of all mame's games' inputs at my site ( http://www.urebelscum.speedhost.com/dl/m61input.zip ).  It's taken from mame's drivers, so it has mame's numbering.

However, it has three problems.  It only lists the names (like 'jump' or 'kick') if the name is included in the driver.  It includes custom and hack inputs: customs mostly include mahjong's buttons, and hack inputs are like some included so normal pc inputs can be used in place of the original wierd arcade type.  And it lists every player's inputs (cocktail inputs as player2 inputs).  So there is way too much info than needed.

Still, it could be a start.  People would need to play the games and find out what mame's 'button1', ect are in that game.

It seems odd that there's no way to distinguish between analogue stick & 270degree wheel too.

I guess there's a good reason for it, maybe for easier handling of controls within MAME?

Many driving games were switched from 'analog stick' to paddle.  They are the handled the same in mame.  Not all of them have paddle mind you, but this is the way mame should be distinguishing between the two.  The cp veiwer could follow this, too.

What I want to distinguish between AD_STICK_Y (Y axis of anolog stick) and pedal(s).  Since mame now has two pedals per player, it can be done.  Hopefully I'll make and submit the changes (after 0.62, though).

[u_rebelscum]

I would say that the internal mechanics are indeed less specific and that's why it is inaccurate.  At least from what I've seen of the source.

 

Mame's -listinfo is setup to only list one input type (8wayJoy or spinner or pedal).  But what about DOT (like SirPoonga said) or other games with a (push button) spinner and an 8wayJoy.  Or driving games with: a spinner and a pedal, or a paddle and two pedals.  Mame -listinfo shows incomplete data.

Are you going to try to include these mutliple control type game from the beginning, or maybe add multiple control-types support later?  (Your example does not say one way or the other)  These are a small  percent of mame, though, so don't halt the project trying to shoe horn the feature in.

Some of you seemed to have an interest in helping and trust me there will be work to be done.  If you guys think I can make a list for all 3000 games then forget it... I will expect a lot of help from the community to make these files and I will complie them into a single list periodically.  If you guys are really all for this, what I will do is post a list of all the games being worked on so that you guys don't repeat work and you can send them to me.  Even if it's just one game it would help a lot.    This will be similar to the mameinfo project in that it will take a handful of people, at the very least to get it done.

As I said last post, I'll play, I mean collect data on, a bunch'o games for the project.

Another question is how do we match the mame name of the button to the caption when the data is collected?  Unfortunately the only way to do it is manually.  Klov is good about putting the buttons functions but they are in the order they appear on the arcade control  panel, not the way mame numbers them.  A good example of this is the mortal kombat games as they have a wierd layout.  You pretty much have to re-define those buttons anyway so that might be another issue, which I think could be fixed with a secondary set of skin files. Just for those special games that require remapping.  Or perhaps custom button name support, like mkbutton1 or ect.... any ideas on this problem?

I suggest use mame's button numbering, and assume the user's ctrlr.ini files do the remapping.  
Button1 = "fire", Button2 = "jump" in the cp veiwer game information files.  
The buttons in the skin include the keyboard or joystick equivalent ('ctrl', 'alt', 'joy1_button1, mousebutton1, whatever).  (Alternate: the buttons are button1, button2, ect, and the veiwer assumes the buttons are mame's default keyboard equiv.)  
Then the cp veiwer takes the gamename, looks at the ctrlr.ini folder for any remapping, and then makes the link between label and skin button.

Example: the skin button (shown with greenbutton.png) is the 'alt' key; ctrlr.ini for this game says alt key is mame_button2; and the skin info file for this game has mame_button2 labeled "special").  

This will handle remaps by the ctrlr.ini method, including situations where two cp buttons are mapped to one mame button (say, the two middle buttons in a 6 button reactangle 'OR' mapped to "block" in mk).  The alternate would be fine for most players, since most people just use ipac's/Xarcade's/hotrod's standards, and would be more intuative.  However, it would be great if the user could change the skin's button to the acutal key the button is mapped to also (probably as an "advanced" feature?).

[Minwah]

I'm up for beginning a simple file to extend the scope of the -listinfo controller type.  I figure these new types would be a good starting point(?):

'rotjoy': rotation joystick (from 'dial'),
'360wheel': 360degree wheel (from 'dial'),
'270wheel': 270degree wheel (from 'paddle'/'stick'[/'dial'-roadblst]),
'yoke': yoke (from 'stick'),
'joy2way': 2-way joystick (from 'joy8way')

So the file would be like eg:

starwars
yoke
stunrun
yoke
ikari
rotjoy
calibr50
rotjoy

etc.

The good thing is, only games that require a 'new' type would have to be recorded, and read by your FE.  This would easily enable your FE to filter more accurately, and it'd just be cool for when you've just got a new steering wheel or something

I'm sure this could be done fairly easily, and eventually combined with other peoples efforts regarding buttons etc, into Howards ideal final format.

What do you think?

[Lilwolf]

We should add more information then just that in my opinion.

then from there, we should either follow catver.ini or listinfo file format so that everyone could parse them right away.

But some things to have in the list

number of controllers (not just number of players).  This should also allow for multiples for games that have a joystick and a dial.
number of buttons
xy layout for each would be cool!  But that would take some time to get the information.  But have the file format accept them.
original color for each would also be cool!

[Minwah]

I agree, as per Howards example.

I'm just thinking that to compile all that stuff will take AGES.  I was just thinking of what I said as a start - this could easily be added to another list(s) that other people may be working on.

Well, I'm going to give it a go anyway.  I just wanna be able to filter out those rotary joystick games until I can get a proper stick to play them with!

[Howard_Casto]

ok... to accomidate what you guys said....
instead of having controltype we will have individual inputs for each joystick,spinner,ect

so
[sf2]
8wayup=
8waydown=
8wayleft=
ect.....

this way we can spilt up the controls like the buttons and it makes an easier to add misc inputs...

like

[dot]
spinleft=
spinright=
spinup=
spindown=
triggerup=
tiggerdown=
triggerbutton=
ect....

now the skinfile doesn't give a crap what kind of input it is.....  
when you make an object, say a 8way joystick graphic on the screen, it comes with various properties that you have to fill in...  one of those is controller type, such as 8way.  You can put in multiple entries for this such as 8wayup;4wayup;triggerstickup ect.... this way when any of these controls are used for a particular game it will only have to load the one graphic and highlight it.... now the viewer will know only to show the depressed graphic when certain buttons are pressed, namely the buttons that are assigned to all those input options you gave that graphic. (8wayup,ect)  We are still trying to figure out how to get the button assignments.. so that is up in the air, but as someone posted above, the crtlr files might be the way to go.  Optionally there might also be a button configuration menu that allows you to assign keys, joystick axis, ect to certain functions inside the viewer itself, making it independant of mame's button assignments, leaving it up to the user.  

So here is the final verdict from me and how I would like to group things....


[romname]
cloneof=
players=
alternating=
button/axis/joystickdirection/ect=

we would get the axis,joystick, and button
names from the big list of them contained inside the ctrlr folder.  so for sf it would be something like

[sf2]
cloneof=
players=2
alternating=no
joy8wayup="Up"
joy8waydown="Down"
joy8wayleft="Left"
joy8wayright="Right"
button1="light punch"
button2="medium punch"
button3="fierce punch"
button4="light kick"
button5="medium kick"
button6="fierce kick"

(notice i didn't include the diagonals, which would be nice visually, but would totally complicate things as mame doesn't have inputs for them)

now the way the viewer and skinner are setup it doesn't matter what the heck these names actually represent... all it knows is if a name is assigned to a graphic then that graphic should be displayed and if a button assigned to a name is pressed then it should show the "depressed" graphic on for it's assigned graphic.

Since I will set it up to deal with multiple names per graphic and multiple inputs per name, then you can literally account for any controller system using this method.  So dot and your racing games would be safe as the axis and gear directions would be split up....

if you choose to use a real wheel, however, you simpy take the wheel graphic you placed on you skin and add spinnerxaxis+;spinnerxaxis- and it would know that both of these directions are on the same graphic...

graphics for various devices would be stored in a folder with a naming convention like
wheel.gif,wheelleft.gif, wheelright.gif ect....

this way for object configuration, when you select the graphic type you simply type in "wheel" and the viewer has sense enough to know that wheelleft/right are inclued with this package and to show them whenever the left or right functions have been pressed as the "depressed graphic."  

now if you think about this... what this means is that once this framework is in place the viewer would never have to be updated for added controller types.... it doesn't give a crap what anything does, just if there is a graphic for it and if it can find an entry for functions assigned to that graphic when parsing the controller file.

I hope that clears things up and sorry about not realizing the thing about multiple sticks, that was a big boo-boo on my part.  So what I say is we check out the ctrlr guide and start posting one or two samples to this thread and make sure it is going to work with all setups.  Post a few of your favorite odd-ball games and I'll check it with the framework I have outlined and make sure it fits and that we all understand how this is going to work.  

[SirPoonga]

joy8wayup="Up"
joy8waydown="Down"
joy8wayleft="Left"
joy8wayright="Right"

why?  A little redundant.

[Minwah]

Going a little OT but...

Just been going through some games to see which could have better control desciptions:

My question is, how do you KNOW if a game used a 270degree wheel?  I had it in mind that games which 'auto-center' the steering (if you turn the wheel then leave it alone for a while) used 360degree wheels.  Then 270degree games don't center the steering, as you have to correct yourself (more like a real car).

But I seem to remember Outrun was a 270degree wheel game, and it seems to operate more like a 360 one (it centers itself).  So is this because a) I remember the game wrong, it is a 360deg game, or b) due to the way mame is handling the controls (I'm using a spinner, not a joystick) or c) I'm completely wrong about the centering thing ??

My other Q is why the hell are the Chase HQ series of games classed as 'joy8way'?.  This has to be a 270deg game, it's not even playable with a digital stick!

Cheers

[Howard_Casto]

joy8wayup="Up"
joy8waydown="Down"
joy8wayleft="Left"
joy8wayright="Right"

why?  A little redundant.

Thats a generic example... I think capcom offically calls those directions "Jump" "Crouch" "Back/Block" and "Forward"

[Howard_Casto]

Going a little OT but...

Just been going through some games to see which could have better control desciptions:

My question is, how do you KNOW if a game used a 270degree wheel?  I had it in mind that games which 'auto-center' the steering (if you turn the wheel then leave it alone for a while) used 360degree wheels.  Then 270degree games don't center the steering, as you have to correct yourself (more like a real car).

But I seem to remember Outrun was a 270degree wheel game, and it seems to operate more like a 360 one (it centers itself).  So is this because a) I remember the game wrong, it is a 360deg game, or b) due to the way mame is handling the controls (I'm using a spinner, not a joystick) or c) I'm completely wrong about the centering thing ??

My other Q is why the hell are the Chase HQ series of games classed as 'joy8way'?.  This has to be a 270deg game, it's not even playable with a digital stick!

Cheers

I might be wrong about this so you guys correct me if I am, but I think you have it backwards.  #60 degree wheels are spinners and thus they don't self-center.  270 degree wheels are analog wheels and thus they have a spring centering device since you can't turn them all the way around.  If 360 degree wheels had a centering device then they couldn't spin all the way around and thus it would be pointless to make them that way.  

As for chase hq.... probably one of two things....

#1 Mame's description is inaccurate again and they need to fix it.

#2 Chase Hq might use a digital wheel though I doubt it as they only became popular for console systems.  If it's digital the mame dev's might have lumped it into the closest cat, eg 8 way digital.    

[Minwah]

I might be wrong about this so you guys correct me if I am, but I think you have it backwards.  #60 degree wheels are spinners and thus they don't self-center.  270 degree wheels are analog wheels and thus they have a spring centering device since you can't turn them all the way around.  If 360 degree wheels had a centering device then they couldn't spin all the way around and thus it would be pointless to make them that way.  

Sorry, you are right Howard, I just didn't explain very well.  What I meant is:

Play Outrun in MAME with a spinner.  Spin left or right a bit - the car turns.  Leave the spinner and the car returns to going straight (ie stops turning).  Now I realise that if the arcade game used a 270 wheel, then the wheel would physically return the the central position (due to springs or whatever).  But surely the game code itself would not centre the steering - this seems to happen in MAME.

This suggests to me that either Outrun was a 360 game, or MAME simulates the auto-centering of the wheel via software.

Does that make sense?  

[Howard_Casto]

Yes it does...  I remember playing some of the games with spinners for wheels and the car would turn only while the wheel was in spin... if you stopped the wheel it would stop turning and stay at whatever course it was headed.  So it might be the game, although I'm not sure at all.  

[u_rebelscum]

Play Outrun in MAME with a spinner.  Spin left or right a bit - the car turns.  Leave the spinner and the car returns to going straight (ie stops turning).  Now I realise that if the arcade game used a 270 wheel, then the wheel would physically return the the central position (due to springs or whatever).  But surely the game code itself would not centre the steering - this seems to happen in MAME.

This suggests to me that either Outrun was a 360 game, or MAME simulates the auto-centering of the wheel via software.

Does that make sense?  

You are right that auto-centering is most often used in mame to center keyboard/dpad inputs for spinner type arcade games.

However, here Mame is auto-centering the the wheel via software, simulating the hardware centering of the real game (at least going by the Outrun manual pdf I'm looking at).  Auto-centering is sometimes done for 270 games like Outrun that had springs to auto-center for keyboard/dpad input  simulating a hardware spring.

If you use a POTs wheel or joystick, its input overrides any mame auto-centering (if the wheel is turned).  Giving the game auto-centering makes most 270 game more playable with keyboard or dpad, hurting spinner input a little, but without effecting the original type input.  Not exactly mame's 100% true-blue documenting purpose, but I think most people like it. (ie: more people use keyboard, dpad or analog input than people who use spinner input.)

A big hubla-hoo was going on a while ago in mame about whether to auto-center 270 games: it hurts spinner input, but (in most people's opinion) helps digital input.  It died out after a while with no consensus, so it's up to the driver writer.  Today some 270 games have it and others don't.  

And Outrun is still a WIP, IIRC, so small changes submitted by people like me usually get lost.  But you can edit the source source (delete " | IPF_CENTER ", line 979, drivers/outrun.c) and get better spinner play it you want. (Or uncomment line 980 and comment out line 979).

[Minwah]

Thanks, that's cleared it up perfectly

So that means that I can't use my previous assumption (auto-centering in MAME=360 game) since this is not always the case.  My classification of 360/270 wheels games will be a guess work then, unless I can find original docs for the game.

Another strange one I noticed is Roadblasters, which is classed as a 'dial' game, but actually used a 270 wheel (almost a yoke minus the y-axis).

[u_rebelscum]

Another strange one I noticed is Roadblasters, which is classed as a 'dial' game, but actually used a 270 wheel (almost a yoke minus the y-axis).

Heh.  Yup Roadblasters is a non-standard input game.  Another atari weirdo.

Its turn was restricted, but used an optical wheel and sensor:  half a 270 and half a spinner.  Mame could use the 'paddle' type to emulate it since it had restricted turn, but the input hardware was a spinner-like, and in mame spinners are emu'ed with the 'dial' type.  This was another "discussion" around when I first discovered mame; again the "leave it alone/let the driver writers decide" side survived the longest.

A few other great atari weird input games: 720 (spinner "joystick"), Paperboy (bike handle with 2 axes), Escape From The Planet Of The Robot Monsters (Hall effect joystick).  720 has the hardest input to emulate of all time, IMO.

[Minwah]

I see  

What's so strange about 720?  Why is it difficult to emulate? - I realise it doesn't play great with a spinner.

[u_rebelscum]

I see  

What's so strange about 720?  Why is it difficult to emulate? - I realise it doesn't play great with a spinner.

720 is a spinner where one rotation of the spinner equals one rotation in the game.  This will be very hard to emulate, with practically every PC mouse/spinner having a different # of spokes per wheel.  Add in the new optical sensors and windows mouse acceleration.  Nearly impossible to emulate the one rotation = one rotation.

More info: I heard the 720 has two axis sharing the same spinner.  One has a normal sensor wheel, the other has one spoke.  The one spoke axis would help keep the spinner joystick and the character in sinc, but again in windows wouldn't help unless some really good coding is done, and the user hooks up two axis to a spinner.  However, I don't have a 720 spinner (wish I did), so I can't check this data.

[romid]

Did anything ever come of this thread?  I dont recall having seen an FE that tells you what buttons do what when you first start up a game... it would definitely be a nice feature  

[rampy]

Did anything ever come of this thread?  I dont recall having seen an FE that tells you what buttons do what when you first start up a game... it would definitely be a nice feature  

It's a work in progress, but the controls.dat project was started to address some of these issues (I think).. you can help the effort or read up on the progresss at fe.donkeyfly.com  *shrug*

rampy

[SirPoonga]

controls.dat project:)  It's coming along, though I only heard from one person finishing his list, we only have 247 games left to hand out for someone to check, which may contain mahjogn so less then that.

Also, -listinfo is actually accurate on controls, it's just that it only lists the last control registered in the driver.  Take dotron.  You will see in controls trackball.  That's because it is the last control to be regietered, a hack to simulate the up/down spinner.  They really should fix that to show all the inputs.  That;s the purpose of the controls.dat project:)