All though it wasn't an orignal idea... *sniff* I'm so proud the thread I started kicked this off...
Anyways... if need be I can create a forum on randomdrivel's forum... or add a total separate forum in the same webspace... or if it was an gpl type license of this dat file sourceforge supplies all the same stuff for "Free"
[atarigt.c:primrage]
URL: http://www.klov.com/P/Primal_Rage.html
MOVE_URL: http://db.gamefaqs.com/coinop/arcade/file/primal_rage.txt
GAMEFAQID: 3575
LAYOUT: 2
PLAYERS: 2
IPT_JOYSTICK: Movement 8-way
IPT_START1: High Quick
IPT_BUTTON1: High Fierce
IPT_BUTTON2: Low Quick
IPT_BUTTON3: Low Fierce
NOTES: Hidden bowling game (look at gamefaqs.com for info)
I figured that more information is better especially if it is easy to get now (whereas later it would suck to have to reget). Haveing the IDs and URLs allows you to see the sources (besides the driver code and playing the games) that were used.
The format is a windows config file format. I can easily rework it into a different form if needed (perl is good at that stuff).
The IPT_BUTTON1, etc. style comes from the input definitions in the drivers themselves. They are the internal names mame uses (with some simplifications). Again, they are easy to translate from if a different format is required. I only put P1, P2 on them when the player controls are different for each player. I do note how many sets of controls there are in the layouts (simultaneous players) and how many players can play total.
IPT_JOYSTICK: Movement 8-way indicates that the joystick for each player is a control for movement and allows you to move it in 8 directions. I envision all of this being shown by a front-end (not necessarily mame) so it would signal to me that I need to make sure my controls are in 8-way position, not 4-way or 2-way.
As a note, the [atarigt.c:primrage] is the driver source file and the input definition, not the source file and driver name, there is an optional third item that allows you to specify a driver when multiple drivers use the same input. Look at cave.c for instance.
I have mailed you the complete file as it stands now. The links have not been validated yet and there are a bunch of notes to me where I need to complete the controls.
-ben
Since I am parsing the raw driver.c files I am effectively generating the same info as -listinfo, but mine happens to be more detailed about the specific control info.
The reason that I do not have 1 input definition per game is that that would generate a ton of definitions, this seems to cut it down by a quarter which makes maintenance a bit easier for the moment. Internally mame knows which input definition it is dealing with (look at the code for -listinfo). If needed we can expand the file out later, getting an input name to game name mapping is easy and then rewriting the definitions is easy too (but makes maintenance harder).
I am not sure waht you mean by renaming IPT_JOYSTICK to IPT_CONTROLS. I would rather document the controls that mame has at the moment (and I plan to fix the controls if they are obviously bust in mame as doing this complete scan will turn up errors).
In the future I would love to add a more sophisticated controls mechanism to allow you to define your controller and have the controls be automapped to the mame ones in a more sophisticated manner so that if I have a spinner it will use that, if I don't I can choose to map it to buttons or a second joystick... but that is a big task for the future.
So for dotron:
[mcr3.c:dotron]
URL: http://www.klov.com/D/Discs_Of_Tron.html
GAMEFAQID:
LAYOUT: 1
PLAYERS: 2
IPT_JOYSTICK: Movement 8-way
IPT_DIAL: Aim
IPT_TRACKBALL: Aim (Y) (hack)
IPT_BUTTON1: Fire
IPT_BUTTON2: Deflect
IPT_BUTTON3: Aim Down
IPT_BUTTON4: Aim Up
Could you modify that to create a skeleton controls.dat file? Like output the control info for each game, leave the right side of the = blank?
the driver file is nice for FEs, I added it to -listinfo for HC. But it shouldn't be in the [] for ini files for FE use. that way the FE just needs to use the romname as the key to the INI file parser.
1 input defination per game, when would you have more???
Also, technically mame doesn;t know the imput definition, it needs to be derived fromt he GameDriver object, hence that huge case statement:)
Ahhhh, I get it now, with one example I didn' understand what that was.
Shouldn;t it be IPT_JOYSTICK=JOY8WAY, what mame uses?? Or DOUBLEJOY8WAY, that use list of constants in that one source file....
Right, like that stuff I was talking about. That can get very complicated, I have an idea to implement something like that, but it all depends on the final format of this project.
Yeah, I can see how the IPT stuff is better inside of mame. That;s why I need to get together people interested in this, and FE devs interested in this. I see this being used more in FE than in mame, it;s just nice to add to mame, looks all pretty. So it should be a format that makes life easier for the FE dev but still useful inside of mame.
Well, and FE devs want to reply with what they'd like to see the format as?
Could you modify that to create a skeleton controls.dat file? Like output the control info for each game, leave the right side of the = blank?
Sure, can you provide a snippet so I get an idea of what you want?
1 input defination per game, when would you have more???
No. the other way around. Some games share the same input definition. Often these have the same control meanings so that it is easier for me to just do one input definition rather than duplicating it for all 3 games. I can rewrite the file into a different format later.
Did you get the file I mailed to you with my current working copy?
-ben
Well, and FE devs want to reply with what they'd like to see the format as?
Minwah, very simular to my first. Here' the problem I see with that format, games like firetruck that use different labels for 1 and 2 player, need to support that.
Plus, to be ini file compliant (vb, vcc, m$ have ini parsers, makes life easier) the romname would be in brackets. Makes it easier to search for a rom then too:)
Otherwise yeah, including the actaul control info is needed. This will most likely incluse something from everyone;s idea.
I like the klov link...my fe can embed html pages in the info menus...
Minwah, very simular to my first. Here' the problem I see with that format, games like firetruck that use different labels for 1 and 2 player, need to support that.
Plus, to be ini file compliant (vb, vcc, m$ have ini parsers, makes life easier) the romname would be in brackets. Makes it easier to search for a rom then too:)
Otherwise yeah, including the actaul control info is needed. This will most likely incluse something from everyone;s idea.
Yeah, you're right, I'd assumed that P1 & P2 controls are always the same :-[
How about this:
[tron]
noplayers=2
nocontrollersets=1
P1description=8-Way Trigger-Stick & Spinner
controller1=joy8way
controller2=dial
P1_JOYSTICK_UP=UP
P1_JOYSTICK_DOWN=DOWN
P1_JOYSTICK_LEFT=LEFT
P1_JOYSTICK_RIGHT=RIGHT
P1_DIAL=AIM LEFT
P1_DIAL_EXT=AIM RIGHT
P1_BUTTON1=FIRE
[sf2]
noplayers=2
nocontrollersets=2
P1description=8-Way Joystick
P2description=8-Way Joystick
controller1=joy8way
P1_JOYSTICK_UP=UP
P1_JOYSTICK_DOWN=DOWN
P1_JOYSTICK_LEFT=LEFT
P1_JOYSTICK_RIGHT=RIGHT
P1_BUTTON1=LIGHT PUNCH
P1_BUTTON2=MEDIUM PUNCH
P1_BUTTON3=FIERCE PUNCH
P1_BUTTON4=LIGHT KICK
P1_BUTTON5=MEDIUM KICK
P1_BUTTON6=FIERCE KICK
P2_JOYSTICK_UP=UP
P2_JOYSTICK_DOWN=DOWN
P2_JOYSTICK_LEFT=LEFT
P2_JOYSTICK_RIGHT=RIGHT
P2_BUTTON1=LIGHT PUNCH
P2_BUTTON2=MEDIUM PUNCH
P2_BUTTON3=FIERCE PUNCH
P2_BUTTON4=LIGHT KICK
P2_BUTTON5=MEDIUM KICK
P2_BUTTON6=FIERCE KICK
[firetrk]
noplayers=2
nocontrollersets=2
P1description=360deg Steering Wheel + Pedal + Buttons
P2description=360deg Steering Wheel + Button
controller1=dial
controller2=dial
P1_DIAL=STEER CAB LEFT
P1_DIAL_EXT=STEER CAB RIGHT
P1_PEDAL=ACCELERATE
P1_BUTTON2=HORN
P1_BUTTON3=TRACK SELECT
P2_DIAL=STEER TRAILER LEFT
P2_DIAL_EXT=STEER TRAILER RIGHT
P2_BUTTON1=BELL
??
OK so for games where P1 & P2 controls are the same (see sf2 above), there is a lot of stuff repeated (ie larger file size) - this just seemed the easiest way to me atm.
I'm not sure how MAME gets the descriptions 'Gas', 'Horn', 'Bell' & 'Track Select' in the tab menu (for Firetruck). Could you enlighten me?
Also, I've never actually done any .ini file parsing - I realise this is the way to go, so I've added the brackets, and I'll do a little research on how to do it when I get a chance.
OK so for games where P1 & P2 controls are the same (see sf2 above), there is a lot of stuff repeated (ie larger file size) - this just seemed the easiest way to me atm.
I'm not sure how MAME gets the descriptions 'Gas', 'Horn', 'Bell' & 'Track Select' in the tab menu (for Firetruck). Could you enlighten me?
Minwah... as we discussed before simply putting joy8way won't work...
Minwah... as we discussed before simply putting joy8way won't work... we need to define each axis/input for a controller seperately. So controller1, controller2 wouldn't work....
I read that one post a little wrong... the controller type=joy8way would be ok, but I think that it would only be useful for reference and not using the dat file to display a layout. But since we also want to preseve the contoller information that should also be in there.
Btw I am almost finished with a skeleton dat file maker so no one has to bother with that... I only have to add the trackball and spinner generation and it's done. :)
I read that one post a little wrong... the controller type=joy8way would be ok, but I think that it would only be useful for reference and not using the dat file to display a layout. But since we also want to preseve the contoller information that should also be in there.
Btw I am almost finished with a skeleton dat file maker so no one has to bother with that... I only have to add the trackball and spinner generation and it's done. :)
Ahhh, but it is useful information. Especially if FEs are goin to start allowign a person to layout their CP in the FE. If someone has a dedicated 4way...
Make the dat file thing accept a list of of drivers/games so whena new version of mame is out you can just generate the new stuff.
Ok here it is....
http://www.oscarcontrols.com/lazarus/files/controls.zip (http://www.oscarcontrols.com/lazarus/files/controls.zip)
It's completely blank and ready for you to fill in...
Btw, I've also started work on a klov extractor but it needs some work. So far I can extract button labels, the number of simultanious players and the controller type fairly well, but the problem is actually finding the name of the page for a given romname....
Klov doesn't use the revision names as does mame, so it's hard to extract data... I'm looking into a way of removing the revision information on the mame descriptions. I will probably split at "(" and use the first field in the array as the url to search for. any other ideas on this?
I read that one post a little wrong... the controller type=joy8way would be ok, but I think that it would only be useful for reference and not using the dat file to display a layout. But since we also want to preseve the contoller information that should also be in there.
Btw I am almost finished with a skeleton dat file maker so no one has to bother with that... I only have to add the trackball and spinner generation and it's done. :)
Ahhh, but it is useful information. Especially if FEs are goin to start allowign a person to layout their CP in the FE. If someone has a dedicated 4way...
Make the dat file thing accept a list of of drivers/games so whena new version of mame is out you can just generate the new stuff.
Well it's good for putting a caption on a graphic but that's about it. I'll explain that one later, it's complicated.
Ok here it is....
http://www.oscarcontrols.com/lazarus/files/controls.zip (http://www.oscarcontrols.com/lazarus/files/controls.zip)
{ "KEYCODE_A", IKT_STD, KEYCODE_A },
{ "KEYCODE_B", IKT_STD, KEYCODE_B },
{ "KEYCODE_C", IKT_STD, KEYCODE_C },
...
{ "P1_JOYSTICK_UP", IKT_IPT, IPF_PLAYER1 | IPT_JOYSTICK_UP },
{ "P1_JOYSTICK_DOWN", IKT_IPT, IPF_PLAYER1 | IPT_JOYSTICK_DOWN },
{ "P1_JOYSTICK_LEFT", IKT_IPT, IPF_PLAYER1 | IPT_JOYSTICK_LEFT },
{ "P1_JOYSTICK_RIGHT", IKT_IPT, IPF_PLAYER1 | IPT_JOYSTICK_RIGHT },
{ "P1_BUTTON1", IKT_IPT, IPF_PLAYER1 | IPT_BUTTON1 },
{ "P1_BUTTON2", IKT_IPT, IPF_PLAYER1 | IPT_BUTTON2 },
P1_BUTTON1 "KEYCODE_A"
PORT_BIT( 0x80, IP_ACTIVE_HIGH, IPT_BUTTON1 | IPF_PLAYER1 ) /* main accel key */
[firetrk]
IPT_PLAYER1:
IPT_BUTTON1=Horn
IPT_PLAYER2:
IPT_BUTTON1=Bell
[end]
[firetrk]
P1_BUTTON1=Horn
P2_BUTTON2=Bell
[end]
PORT_START /* fake port to make aiming up & down easier */
PORT_ANALOG( 0xff, 0x00, IPT_TRACKBALL_Y, 100, 10, 0, 0 )
PORT_START /* IN1 */
PORT_ANALOGX( 0xff, 0x00, IPT_DIAL | IPF_REVERSE, 50, 10, 0, 0, KEYCODE_Z, KEYCODE_X, 0, 0 )
PORT_START /* IN2 */
PORT_BIT( 0x01, IP_ACTIVE_LOW, IPT_JOYSTICK_LEFT | IPF_8WAY )
PORT_BIT( 0x02, IP_ACTIVE_LOW, IPT_JOYSTICK_RIGHT | IPF_8WAY )
PORT_BIT( 0x04, IP_ACTIVE_LOW, IPT_JOYSTICK_UP | IPF_8WAY )
PORT_BIT( 0x08, IP_ACTIVE_LOW, IPT_JOYSTICK_DOWN | IPF_8WAY )
PORT_BITX(0x10, IP_ACTIVE_LOW, IPT_BUTTON3, "Aim Down", IP_KEY_DEFAULT, IP_JOY_DEFAULT )
PORT_BITX(0x20, IP_ACTIVE_LOW, IPT_BUTTON4, "Aim Up", IP_KEY_DEFAULT, IP_JOY_DEFAULT )
PORT_BIT( 0x40, IP_ACTIVE_LOW, IPT_BUTTON2 )
Actually my skelton file includes all of the std entries with the exception of vertical spinners and paddles.
The other things you saw were glitches in the program that i didn't catch simply because those few games you choose are so freakin wierd. Btw those example would have to be entered manually anyway, so I don't see the big deal there. There isn't any way you can get the information of those particular games automatically.
Remember sirp this is beta... I posted it so others could find glitches. :)
[firetrk]
Description=Fire Truck
numPlayers=3
alternating=0
P1ControlType=Dial
P2ControlType=Dial
P1_DIAL=Left
P1_DIAL_EXT=Right
P1_BUTTON1=Horn
P1_BUTTON2=Track Select
P2_BUTTON1=Bell
START1=Player 1 Start
START2=Player 2 Start
START3=Both Start
MiscDetails=
[end]
[ddragonb]
Description=Double Dragon (bootleg)
numPlayers=2
alternating=0
P1ControlType=8-way Joystick
P2ControlType=8-way Joystick
P1_JOYSTICK_UP=Up
P1_JOYSTICK_DOWN=Down
P1_JOYSTICK_LEFT=Left
P1_JOYSTICK_RIGHT=Right
P1_BUTTON1=Punch
P1_BUTTON2=Jump
P1_BUTTON3=Kick
MiscDetails=
[end]
And the inputs are just like mame, so remember how the graphics are linked to the outputted layout is irrelevant to our data collection.
[/qiote]
Right, but since eventually someone will use it to do jsut that, to me my way is easy (in my opinion). Actually, HC's idea is a subset of mine, you can still implement HC's idea with my style of formatting, putting the P2, P3, P4 labels in the dat. HC's algorithm wouldn't look at that as much, but still could be done:)
Which brings up another point, it;s flexible enough to use different implementations.
BTW, I'm writing an ActiveX dll to handle the dirty work of parsing this. It will work alot like the XML 4.0 stuff form M$.
PORT_BITX( 0x02, IP_ACTIVE_LOW, 0, "P1 Kan", KEYCODE_LCONTROL, IP_JOY_NONE )
#define PORT_BITX(mask, default, type, name, key, joy)[polepos]
Description=Pole Position
numPlayers=2
alternating=no
P1ControlType=Dial
P2ControlType=Pedal
P1_DIAL=Left
P1_DIAL_EXT=Right
P1_PEDAL=Gas
P2_PEDAL=Brake
MiscDetails=Player 1 uses both pedals
[end]Small, non normal questions:
What about mahjong games?
They don't use mame's BUTTON1...9 input types, but make their own custom inputs with no reference to a standard mame input (see the zero (0), below):Code: [Select]PORT_BITX( 0x02, IP_ACTIVE_LOW, 0, "P1 Kan", KEYCODE_LCONTROL, IP_JOY_NONE )
#define PORT_BITX(mask, default, type, name, key, joy)
Also, I don't understand the games with one real player, but use player 2 (and higher) inputs because of mame's limits. Take Pole Position for instince: gas is P1_PEDAL and brake is P2_PEDAL and steering is P1_DIAL. P2_DIAL is not used. Will:Code: [Select][polepos]
Description=Pole Position
numPlayers=2
alternating=no
P1ControlType=Dial
P2ControlType=Pedal
P1_DIAL=Left
P1_DIAL_EXT=Right
P1_PEDAL=Gas
P2_PEDAL=Brake
MiscDetails=Player 1 uses both pedals
[end]
be the way to do this? (Should Pedal be added to P1ControlType? Or should Pedal be removed from P2ControlType?)
Quote from: SirPoonga That might be the way to do this, but like I said, since this is most likely no going to only be for FEs that can be defines like
P1_PEDAL1=Gas
P1_PEDAL2=Brake
[/quote
But what happens then when you lookup in the ctrlr.ini file? If Pole Position uses P2 Pedal for brake, then this controls file MUST refer to P2_PEDAL in order to find out what key is configured for this control.
I think :D
I'm not sure what you guys are referring to in pole position... it ueses
P1_PEDAL
P1_PEDAL_EXT
As far as I know it no longer uses player 2 inputs. If it does use player 2 then that is silly as mame allows at least 2 axis and 9 buttons for player 1. The steerting wheel would be one axis and the pedals on all arcade machines share an axis via a network of resistors.
Also when games use shared inputs from players (like xmen 6 player, which steals some inputs from player 1 and 2) We will put a special switch in the controltype fields, Telling us to look for inputs from all 4 and not to mirror anything.
If I'm wrong on this please correct me as I need to rework some things if that is the case.
Btw I looked at pole postion again and realized that the original cab only had a gas pedal. So why the pedal 2 is put in it's menu is beyond me, it serves absolutely no purpose. I'm betting there are probably other games like this.
Rather than use the relatively flat .ini format, how many FEs parse the -listinfo format at the moment? It might be a good format to consider since it allows for arbitrary trees of data to be captured.
I have been thinking about the format of the stuff we need to capture and I think I have been assuming that the formats that we have all been kicking around are a little too simple.
Perhaps the correct model is one where you can define control blocks, then say which players use which control blocks. As an example take that game 1942 which has 2 players who alternate at the controls which are an 8-way joystick, and 2 buttons (fire and loop).
I propose we capture this information as follows:
CDEF1=JOYSTICK|8WAY,BUTTON1,BUTTON2
CDEF1_JOYSTICK=Movement
CDEF1_BUTTON1=Fire
CDEF1_BUTTON2=Loop (3 per board)
Then you associate the controls with the players:
[1942]
PLAYERS=2
SIMULTANEOUS=1
PLAYER1_CONTROLS=1
PLAYER2_CONTROLS=1
CONTROL1_DEF=1
(controls from above)
[end]
The CONTROL1_DEF line maps the control location to the actual raw definition. I hope the meaning of this will become more clear in the next example. This is for 1943 where 2 players can play simultaneously:
[1943]
PLAYERS: 2
SIMULTANEOUS=2
PLAYER1_CONTROLS: 1
PLAYER2_CONTROLS: 2
CONTROL1_DEF=1
CONTROL2_DEF=1
CDEF1=JOYSTICK|8WAY,BUTTON1,BUTTON2
CDEF1_JOYSTICK=Movement
CDEF1_BUTTON1=Fire
CDEF1_BUTTON2=Special Attack (uses energy)
CDEF1_BUTTON1+CDEF1_BUTTON2=Loop (uses energy)
[end]
Then for one of the more screwed up examples:
[firetrk]
PLAYERS: 2
SIMULATANEOUS=2
PLAYER1_CONTROLS: 1
PLAYER2_CONTROLS: 2
CONTROL1_DEF=1
CONTROL2_DEF=2
CDEF1=DIAL,BUTTON1,BUTTON2,BUTTON3
CDEF1_DIAL=Front Steering
CDEF1_BUTTON1=Gas
CDEF1_BUTTON2=Horn
CDEF1_BUTTON3=Track Select
CDEF2_DIAL=Rear Steering
CDEF2_BUTTON1=Bell
[end]
Then there are the games like nstocker that have controls for P1 mapped into P2:
[nstocker]
PLAYERS: 2
SIMULATANEOUS=1
PLAYER1_CONTROLS: 1
PLAYER2_CONTROLS: 1
CONTROL1_DEF=1
CDEF1=P1_LIGHTGUN,P1_BUTTON1,P2_DIAL
CDEF1_P1_DIAL=Steering
CDEF1_P1_BUTTON1=Trigger
CDEF1_P1_LIGHTGUN=Aim
[end]
Another perverse case to consider is spclords (test driver) which as a joystick with left/right/up defined but not down (see also atetcktl for a working case of this)! And the 6 player X-men with scavenged controls for players 5 and 6.
The reason that I call out the number of simultaneous players is that some games define 2 sets of controls but only 1 player can play at a time (dunno if these are missing COCKTAIL flags, see ajax, armedf, ...).
I have deliberately left out additional information that I think we want to capture (URLs, GameFAQ IDs, etc.) to make the control discussion the real focus. At some point we need to decide on what ancillary information to add.
Things that the above format accomplishes:
- Accurately documents the controls on a real cabiner (i.e. P1 and P2 shared the same controls or used different sets)
- Avoids duplicating the descriptions
- Is confusing to read :-)
-ben
So what are you parsing to get the control definitions from MAME? And what language is your parser written in?
Right now my parser reads directly from the driver C files (and it is written in Perl).
Please note that I really want to reduce the number of duplicate definitions in at least the source file that human maintain. I think duplicating all 4 identical controls for Gauntlet is a waste. Also providing information for clones is a bit pointless.
My original format (and the one I am using at the moment to generate the control definitions) is pretty simple. It refers to things by their internal MAME macro names rather than the ctrlr.ini ones, but I think that is easily rectified.goto-l
-ben
QuoteQuote from: SirPoonga That might be the way to do this, but like I said, since this is most likely no going to only be for FEs that can be defines like
P1_PEDAL1=Gas
P1_PEDAL2=Brake
[/quote
But what happens then when you lookup in the ctrlr.ini file? If Pole Position uses P2 Pedal for brake, then this controls file MUST refer to P2_PEDAL in order to find out what key is configured for this control.
I think :D
Ahhh, you bring up an interesting dilema. First off, right now, alot of people don't use the ctrlr files, they reconfig games keys with the UI. Second, what use would it have? The only thing you could get out of it is the keyboard key assigned to something.
Other than NeoGeo, unless you use my ctrlr file hacks (which aren;t ever going to be in the real mame) there isn't much you can do with the ctrlr files.
Perhaps the correct model is one where you can define control blocks, then say which players use which control blocks. As an example take that game 1942 which has 2 players who alternate at the controls which are an 8-way joystick, and 2 buttons (fire and loop).
OK well, no, I don't use the .ini files really.
But it would be quite cool to get the 'key' for each control/button tho. Then you could use this for a 'test controls' feature in your FE, before you actually run the game.
The ctrlr files are useful in that you can read them and see input changes... in other words if you redefine button 1 on one particular game it will be displayed properly in your layout for that game. Of course if you don't use the ctrlr files then you are screwed, but this will definately encourage people to use them....
Actually no.... everytime a layout is displayed you read the layout of the persons ctrlr file.... In some languages it's hard but in thers it's very easy... in vb for example, the keycode constant is simply "vbkey"
followed by the key name, which makes it veyr easy to parse. I believe that c++ has something similar.
Unless you have a fe that redefines mame keys for you, this shouldn't be an issue.
As for the ipac, I use xp. And more and more people are popping up with xp on their cabs. Since it's difficult to program the ipac on the fly in xp I figure a few years from now this won't be an issue. Also Writing to the ipac that often isn't such a good idea as eprom chips have a finite number of writes. It's a high number but still, better safe than sorry :)
P1_PEDAL
P1_PEDAL_EXT
As far as I know it no longer uses player 2 inputs. If it does use player 2 then that is silly as mame allows at least 2 axis and 9 buttons for player 1. The steerting wheel would be one axis and the pedals on all arcade machines share an axis via a network of resistors.
Oh ya, starting with mame .61, mame now has 3 (used) analog axes: X, Y, and Pedal. A forth is coded in there too, but no drivers are written to use it yet (it's a shared Z / Pedal 2 axis). So some games that now have P1_PEDAL and P2_PEDAL might have P1_PEDAL and P1_PEDAL_2 at some point in the furture, as well as some of those games that incorrectly emulate the gas & brake on a shared (Y) axis may be switched, too.
Also the default mapping of PEDALs in mame are still buttons, but now will correctly handle analog joystick inputs, and with the analog remapping ability also added pedals now work like they should. (hint: use the ctrlr pedal.ini to aplply to all games with PEDAL)