Main > Software Forum
MAME cfg is going XML.
SirPoonga:
There is a reason to have the ctrlr files yet. First, having the preset controller (hotrod, slikstik) configs, the whole reason ctrlr files were made. MameDevs use those. I know many devs have HotRods and SlikStiks.
Also, that means cfg files would have to support neogeo.ini, vector.ini, cps1.ini, etc.... All the driver and extra files above romname files.
I can see a time where ctrlr files would go xml.
Howard_Casto:
I'm mostly worried about the file size.
Keep in mind guys xml is ascii based and the old cfg files are binary.
Also the cfg files contain a TON of data, not just controls and dip switch settings. Basically anything that normally saved to the games battery (if it didn't have nvram) is saved in the cfg file.
So your mame install is gonna be huge as cfg files are made automatically.
Also need I remind you guys that there is no standardization what-so-ever in cfg file data. It's basically just a raw dump with the exception of control data.
Unless the standardization of the data is fixed first, I would say this is just a huge waste of time on aaron's fault.
Oh and just in case you guys don't know, I'm not a big fan of xml. I think it's another one of these "now" formats that will fade over time. Also xml is designed for small, simple data nesting, not the huge, complex 1000 level data nesting junk you have to deal with in mame.
My guess is some of the mame devs recently took xml courses and they are all excited about learning something new so they decided to go mucking about in mame. Well I learned java, but I didn't rewrite my fe in it afterwards, mainly because java isn't well suited for the stuff I like to do.
Howard_Casto:
And on a final note, I am also worried about the ctrlr format.
I don't think the mame devs were ever big fans of it else it would get worked on more. Even if it doesn't go away it probably won't be improved upon anymore. That means that the most accurate control data would be stored on the cfg files. That also means that us guys working on the controls.dat project are frikkin screwed! The two formats are convertable, but not easily convertable. So we would have to choose and either way, there are extrememe dis-advantages of doing it one way or the other.
SirPoonga:
--- Quote ---I don't think the mame devs were ever big fans of it else it would get worked on more.
--- End quote ---
I doubt this, as they were added so devs could just use the hotrod and slikstik default mappings. However, mamedevs do have a reputation for once they have something working to not improve upon it.
u_rebelscum:
--- Quote from: Howard_Casto on July 22, 2004, 02:45:56 pm ---Also the cfg files contain a TON of data, not just controls and dip switch settings. Basically anything that normally saved to the games battery (if it didn't have nvram) is saved in the cfg file.
[snip]
Also need I remind you guys that there is no standardization what-so-ever in cfg file data. It's basically just a raw dump with the exception of control data.
Unless the standardization of the data is fixed first, I would say this is just a huge waste of time on aaron's fault.
--- End quote ---
The cfgs are fairly well standardized.
The biggest problem in decoding the binary was figuring out where one input (or the other settings HC mentioned) started and the next ended. This problem will very easily be covered by the switch, as xml is very good at seperating stuff.
The other problem is that the cfg binary needs to match the driver's order of inputs. If the xml inputs are made so they can be in any order, much like ctrlr ini files are compared to default.cfg. (FWIW, default.cfg has been the only config file that only contains input settings.)
But, yes the xml files will probably 10 to 50 times larger.
--- Quote from: SirPoonga on July 22, 2004, 02:34:33 pm ---There is a reason to have the ctrlr files yet. First, having the preset controller (hotrod, slikstik) configs, the whole reason ctrlr files were made. MameDevs use those. I know many devs have HotRods and SlikStiks.
--- End quote ---
Ya, that's part of what I ment in: "2) setable to different folders (for different controllers)" I was not very clear.
--- Quote ---Also, that means cfg files would have to support neogeo.ini, vector.ini, cps1.ini, etc.... All the driver and extra files above romname files.
--- End quote ---
Again you explain it better, but that's what I meant in: "3) uses multiple ini files, depending on game ..."
:)