Major code change pushed

[Ian]

Looks good work Harry
however unless I am having some sort of brain fail (it happens a lot
Those XML files are illegal, you can't have multiple top level top level elements ......

[HarryTuttle]

You mean "game" element? We can put under, let's say, "model3" top-level and update the parser

[Ian]

Yeah
A model3 top level node would be perfectly valid !

[Bart]

Thanks, Harry! Looks good. I'll try it when I get home. I just realized I made the mistake of not allowing optional ROM files (Supermodel used to have the drive board ROMs be optional, because the original ROM sets lacked them and it caused problems for people). I guess we can live without that convenience now that the MAME ROM sets are widely available.

I'll check your work more thoroughly at home. I think I'll delete "ecap" though, since it's a bad dump anyway.

I'll wrap the XML in a top-level "games" node. The tinyxml2 parser doesn't care about top level nodes but it's a good idea for us to add one.

[HarryTuttle]

Bart, I've posted an update here with the top level added: http://www.supermodel3.com/Forum/viewtopic.php?f=7&t=1362

[HarryTuttle]

Bart, out of curiosity, do you have any plan to support 7z format and implement a function to export the gamelist as a datfile for rom managers?

[Bart]

I don't know what a dat file is and I've never been a fan of 7z, so it's low on my personal priority list. But, if it's what people want, it could probably be done. Hopefully the 7zip library has an interface that can be easily bolted into GameLoader.cpp. I imagine generating dat files once the XML is parsed should be trivial?

[CiroConsentino]

hi there,
I see Games.xml from svn597.

issue #1:
Child sets only have the unique ROMs necessary by that game and do not list the ROMs from the parent. OK, no problem.
But I need to ask, are ALL ROMs from the parent set required for child sets ?
I'm asking this because my frontend does validate all ROMs for the child set, and will scan the parent.zip file for required ROMs.

But there are some child sets that do not use all ROMs from the parent set... at least this is true on MAME.

issue #2:
I see child sets using "region" tags for the ROMs list.
Example,
game "vf3tb" parent "vf3"
there are ROMs in region "crom" and region "banked_crom", nothing else.

I'm asking because I want to make my frontend always create a games list based on the Games.xml without creating an external database and update it every time an updated "Games.xml" is issued.


Does this means that the frontend should ignore the ROMs of regions "crom" / "banked_crom" from parent set "vf3" and replace them with the ones from child set vf3tb ?
I just need to be clear on those 2 issues.

[Bart]

This ROM stuff is getting more tricky than I realized

Supermodel merges the parent definition with the child by overlaying the child atop the parent. Any ROMs with the same region and offset will be replaced by child sets. Not just the whole region. For example, I think one of the child sets has a single ROM file in a single region changed.

Does that help?

[CiroConsentino]

Yes, thank you.
I'll need to code a more complex ROMs detection function for games.xml. My frontend doesn't check for region tags, just the "rom" tags on each game entry (based on MAME's -listxml output).
No problem, my frontend will support any format you give us.