Page 6 of 7

Re: Major code change pushed

PostPosted: Tue Apr 04, 2017 5:04 am
by 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 ......

Re: Major code change pushed

PostPosted: Tue Apr 04, 2017 5:06 am
by HarryTuttle
You mean "game" element? We can put under, let's say, "model3" top-level and update the parser

Re: Major code change pushed

PostPosted: Tue Apr 04, 2017 5:09 am
by Ian
Yeah :)
A model3 top level node would be perfectly valid !

Re: Major code change pushed

PostPosted: Tue Apr 04, 2017 7:18 am
by 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.

Re: Major code change pushed

PostPosted: Tue Apr 04, 2017 7:48 am
by HarryTuttle
Bart, I've posted an update here with the top level added: http://www.supermodel3.com/Forum/viewtopic.php?f=7&t=1362 :)

Re: Major code change pushed

PostPosted: Wed Apr 05, 2017 2:02 pm
by 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?

Re: Major code change pushed

PostPosted: Wed Apr 05, 2017 7:03 pm
by 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?

Re: Major code change pushed

PostPosted: Thu Apr 13, 2017 5:57 pm
by 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.

Re: Major code change pushed

PostPosted: Fri Apr 14, 2017 9:39 am
by 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?

Re: Major code change pushed

PostPosted: Sat Apr 15, 2017 8:04 pm
by 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.