Main > Software Forum
Aaron removes xml2info as of u12 (in other words, we are screwed)
Howard_Casto:
well... actually it isn't in mame. Mame doesn't use manual/cpo accurate label descriptions.
Asteriods is a prime example:
First off some of the labels are slightly off from the official cpo labels. Secondly it's mapped to a joystick, which is wrong as asteroids actually used pushbuttons. (This is fixed in controls.dat by the direcitonal buttons constant.)
So it's less of a documeting thing in mame and more of a "this description was added because the button mappings are confusing and the full label name was altered to fit in the ui." Not that they aren't appreciated mind you, I'm just saying they don't have anything to do with the documentation aspect or else they'd be more accurate.
It's a waste of space to output, say directions for a joystick unless it's a special case. Simply defining defender as a vjoy2way (which is a mame control constant) tells you that there is an up and down and of course they would be labeled up and down. There isn't a need to define each direction.
I'm not sold on the individual button entries either. Some of the classics have captions for the button function, but most don't. Around 90% of the listxml file would be "<button name=p1_button1/>" ect....
I actually liked it better early on in the xml cfg file's history when all the possible inputs were printed in the cfg, even ones that weren't remapped. Made more sense to have it there for me as most (note I said most) people could care less about that data.
While we are on that tangent...... Somebody really needs to modify the cfg files so that they always print hardcoded remaps even if they haven't been changed by the user. It was in there for a while and it was great... j5 and those types of viewers potentially were 100% accurate as even keys that were internally remapped from their defaults could be read.
Makes sense to me.... a user always assumes that button 3 on a game is space and it throws them for a loop when they find out the driver author remapped that button to "a" for this particular game or what have you. So that kind of craziness definately needs to be documented somehow.
Minwah:
I like much of the stuff mentioned here...I think the key is getting as much useful stuff we can, but not being so over complicated that the MAMEdev don't accept it. IMO the multiple control types is a huge step forward already, combined with no. buttons is pretty decent info for a good number of games.
I like the second system shown by u_rebel...if the issues with the ctrlr files (HC & I have touched on) were sorted too then I think we should be pretty happy fella's :)
SirPoonga:
Krick, what do you mean by string heavy? Just curious as I am always looking for ways to improve the project.
When I designed the xml format I went with the suggestions most books give. Use attributes as they are faster to parse with some parsers, etc... times have probably changed and it may need improvement.
Also one thing controls.dat does is assocciate button with a control. Like the dotron triggerstick has two buttons on it that are player 1's button 1 and 2. The other thing is there is more resolution on type of controls. Like you can sort by 360 degree steering wheel or spinner instead of just dial. That type of stuff I don't see being internalized in mame. However, I could see that controls.dat be treated like other dat files as an add-on.
HowardC, going to bring up the service button issue? *hint hint*
krick:
--- Quote from: SirPoonga on July 20, 2006, 02:03:01 pm ---
Krick, what do you mean by string heavy? Just curious as I am always looking for ways to improve the project.
--- End quote ---
No need to worrry, I didn't make myself clear. I meant that the content of the controls.dat includes a lot more "text" than the MAME devs would be comfortable with in the -listxml output. Mainly the "miscDetails" content, but I'm sure we'd get resistance to adding functional labels for the buttons as well. I personally think button functions are a really important part of documentation but Haze (and possibly other devs) worry that all the extra text will bloat the source and make the EXE a lot larger.
I think the ultimate solution for MAME is to have an XML file for each game that defines all the control, display, and dipswitch, roms, etc... information. These files can be either parsed in at runtime (probably not likely) or translated into actual code at compile time. If you look at the source for most of the drivers, they look like just a bunch of macros for the most part. There's no reason that that information can't be generated from XML files.
The upside is that the XML files can include more information than MAME actually uses so it provides a convenient place for further documentation.
AaronGiles:
--- Quote from: krick on July 20, 2006, 02:22:27 pm ---I personally think button functions are a really important part of documentation but Haze (and possibly other devs) worry that all the extra text will bloat the source and make the EXE a lot larger.
--- End quote ---
That's a bit of a mischaracterization. The reason is that right now in many cases there can be one set of input port definitions for multiple games on a system. If you started adding descriptions for the buttons to each port, then you have to create separate input port defs for each game in a driver. So neogeo.c would be polluted with 200+ input port definitions, etc. This also hides all the commonalities of the inputs and makes it difficult to understand how one set of inputs maps differently from others. It really hinges on source code readability.
That said, I think there are ways to fix this. Basically, get rid of the existing way of naming input ports, and have some mapping that says IPT_BUTTON1 = "Jump" for this game. And have that information be separate from the input port definitions. Which is basically controls.dat, as far as I understand it. Whether or not that data should be internal to MAME is a good question. Some of the devs want to push some of MAME's current data out of the EXE and into other files (XML, sorry Howard), while others like to have the "canonical" data stored in the EXE where it is guaranteed to be verified through a known process.
Plus, input port names technically don't matter at the PCB level, which is officially what MAME focuses on emulating. But if we were super sticklers about that, then even joysticks would be mapped as raw switches, the DIP switch information wouldn't be provided, and we wouldn't provide any control mapping. I can hardly claim consistency on anything in MAME (nor would I want to).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version