Main > Software Forum
Aaron removes xml2info as of u12 (in other words, we are screwed)
<< < (14/16) > >>
krick:

--- Quote from: AaronGiles on July 20, 2006, 03:48:45 pm ---
--- 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.


--- End quote ---

I was just simplifing the issue for purposes of discussion but that's basically what I meant when I said "bloat the source".   The obvious side effect being a loss in readability.


--- Quote from: AaronGiles on July 20, 2006, 03:48:45 pm ---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).

--- End quote ---

I'm definitely in the camp that wants to push the extraneous data out of MAME.  All input ports/switches/buttons/etc... should be just numbered/enumerated using some democratically agreed upon system.  Then external XML files for each game could define what these ports/switches/buttons "mean" for that game and how they relate to each other.  The MAME UI can then look at these files to get the text to display when the menus are shown.

If you want, each version of mame can include a zip archive with all the latest XML game mapping files.  Or if you really want to get fancy, you could probably put them in a folder, zlib compress the folder, and imbed them into the exe itself like a resource.  That way, they're not physically mixed in with the source code, but they are still "canonical" data stored in the EXE.

SirPoonga:

--- Quote from: AaronGiles on July 20, 2006, 03:48:45 pm ---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.

--- End quote ---
Yep, that's a simple summary of controls.dat.  Not only is it for labelling controls it is for higher resolution sorting of controls.  Like I said earlier, you can sort by 360 steering wheel instead of dial (which would include the spinner games too).

I agree is not putting the info in mame.  I like how history.dat is outside of mame and optional.
It's also makes it easier for non-programmers to add info or correct it.

Krcik, yeah, I figured that was what you meant.  miscDetails is there to be the catch all since games do not use standardize control layouts :)  Some of the games are even too wordy for my liking but there is no other good way to document the controls in an easy and consistant way to parse.
Howard_Casto:
You and me both.  Control constants are sometimes "bastardized" for lack of a better word to piece together inputs for odd-ball games with strange control schemes.  It makes documenting our end of stuff very difficult.  On the other hand, I wouldn't want to subject mame users to the horror of opening up the ui only to find "input 1-input 12" and have those guys try to figure out which ones are joystick directions and which ones are buttons.  

If ctrlr files supported bitmasks and all that fanciness it wouldn't be that much of an issue... an external doc could bind itself to the port "address"  and it wouldn't matter if mame called that port "p1_button1" or "p1_joystick_up."


Btw Aaron, while I'm completely in agreement with you on this one, neogeo is a bad example.  A person could document the game's control functions, but what we do (since it is easier to verify and standardize) is to document the official label given on the cpo or if that isn't available the instruction card, manual ect.... in game descriptions of a control are a last resort.  Anyway, the "official" labels for every single neogeo game with the exception of the prototype game with the spinner and irritating maze are A, B, C, D  just like the mvs cpos.  So their label descriptions could be stored at the driver level with over-rides in those few exceptions.  Even neogeo games that don't use all 4 buttons are most likely going to be in a mvs cab, and since the main pcb still has outputs for 4 buttons, the constant still applies.  

Of course there are "classics" drivers that would really be effected.  I driver in which every single game has a 4 way joystick and a single button would now have to have seperate input port definitions.  

Regardless, what you might have been getting at anyway.... a real hassle comes once the listxml is generated and the "bulk" is increased considerably.  Mame is gonna output that A, B, C, D grouping for all 200+ neogeo games.  An external file, like the controls.dat has the benefit of not having to output replicated data.  We don't have entries for clones (except bootlegs that used hacked controls) and when a system has  a universal layout, like the neogeo, we simply make a driver entry and consolidate all of that mess into just a few lines.  Large xml files take a while just to load.  

While the new rom flag output helps a  person that needs just the basics from the entire listxml file is gonna be slowed down.  I don't think anyone would mind this if the data was useful.  In this case, however, I've gotta agree that unless there was some way to toggle the captions on and off, port descriptions generally just confuse things at the mame level, and in the case of documentation it simply isn't possible as a great deal of "official" descriptions won't even fit in the ui screen.   That's why I suggested some sort of external file that could be read in at the ui level only.  People that want to use it could, people that don't won't.

[very slight rant]
Btw krick... I've gotta laugh a little at your string heavy comment.  We are documenting captions and labels.  What did you expect that to be short?  Even the ini version which saves space by not using all the xml tags is still rather huge.  Save maybe removing misc details I don't see how you could possibly make it smaller if you are really trying to accurately document.  Those are the researched official labels and physical controls, there isn't any way to shorten them without making them unofficial and thus you aren't really documenting anything are you?  If anything they are string light.  We could put the driver and clone names in each entry to aid in parsing, but since that can be obtained by asking mame we left them out.  It is the absolute bare minimum format you can document the controls and their labels with.  Actually in some ways it has provento be too minimal and sirp and I are considering expanding the format slightly to add a few misc stuff.  I'm not picking on you, I just wanted to explain.  Controls.dat doesn't use labels that some guy made up that help you understand what's going on in a game, each entry is researched to get the most arcade accurate description of the controls as possible.  If you were to read an entry while looking down at the real dedicated arcade machine, it would precisely describe the panel you are looking at and the labels printed on either the control panel or the instruction card on the bezel.  I'm not saying that the format we have setup would have to be used in mame, but the data would, as that is the actual data.  
[/very slight rant]
krick:

--- Quote from: Howard_Casto on July 20, 2006, 05:12:11 pm ---[very slight rant]
Btw krick... I've gotta laugh a little at your string heavy comment.  We are documenting captions and labels.  What did you expect that to be short?  Even the ini version which saves space by not using all the xml tags is still rather huge.  Save maybe removing misc details I don't see how you could possibly make it smaller if you are really trying to accurately document.  Those are the researched official labels and physical controls, there isn't any way to shorten them without making them unofficial and thus you aren't really documenting anything are you?  If anything they are string light.  We could put the driver and clone names in each entry to aid in parsing, but since that can be obtained by asking mame we left them out.  It is the absolute bare minimum format you can document the controls and their labels with.  Actually in some ways it has provento be too minimal and sirp and I are considering expanding the format slightly to add a few misc stuff.  I'm not picking on you, I just wanted to explain.  Controls.dat doesn't use labels that some guy made up that help you understand what's going on in a game, each entry is researched to get the most arcade accurate description of the controls as possible.  If you were to read an entry while looking down at the real dedicated arcade machine, it would precisely describe the panel you are looking at and the labels printed on either the control panel or the instruction card on the bezel.  I'm not saying that the format we have setup would have to be used in mame, but the data would, as that is the actual data.   
[/very slight rant]

--- End quote ---

I think my comment was misunderstood by all.  Sir Poonga originally mentioned controls.dat in response to u_rebelscum wanting suggestions on additions to the MAME XML output in the controls area.   I think what is done with controls.dat is awesome, however, I know that if anything was to be added to the MAME source code, it would have to be as minimally invasive and non-bloating as possible in order to be accepted by the devs.  In that respect, controls.dat *is* too heavy.  It doesn't make it invalid or unimportant, just more than the MAME devs would go for if it was incorporated into the source.  External XML files, however, put an entirely new spin on it.


Pi:

--- Quote from: Howard_Casto on July 18, 2006, 05:25:32 pm ---Yeah it works, but it seems to only keep data relevant to crc checking. 

--- End quote ---

There's an option called -k to (quoting the manual) "keep as much information as possible from the source file". In the past it worked quite well, I'm not sure right now. But as I said, he's available for some requests, if time permits.

In any case, if people really care about xml2info, then someone should take over the source and maintain the project from now on... It'll be much better and cleaner than any other solution, IMHO.
Navigation
Message Index
Next page
Previous page

Go to full version