Page 7 of 7

Re: Major code change pushed

PostPosted: Sun Jul 30, 2017 6:52 pm
by CiroConsentino
hi,
I just realized something. The ROM "size" tags are gone in the new "Games.xml" file.
There is no way to know the size of the game set now. Can the ROM size tag be added back ? It's not vital for my frontend but it's nice to know the size in bytes of each ROM.
The old list from the source code (in "Games.cpp"), the file sizes are all there.


... there's nothing to see here.

Re: Major code change pushed

PostPosted: Sun Jul 30, 2017 9:37 pm
by Bart
Why is the size necessary? It seems redundant. The CRC can verify whether the ROM is correct, so no one needs to know the size for that. Also, the objectives of Supermodel's ROM loading system are slightly different than MAME's. I wanted to make it easy for me to load up home brew ROMs, so I wanted to put as little information in Games.xml as possible (that way, I wouldn't have to change Games.xml each time I build a new ROM set).

Re: Major code change pushed

PostPosted: Mon Jul 31, 2017 5:42 am
by CiroConsentino
It's just for game size info in the frontend, not necessary at all.

>> I wanted to make it easy for me to load up home brew ROMs, so I wanted to put as little information in Games.xml as possible (that way, I wouldn't have to change Games.xml each time I build a new ROM set).
Noted. I understand your point of view and agree. ROM size is not important. No worries, I can deal with it. Don't think of this for another second...

Re: Major code change pushed

PostPosted: Mon Jul 31, 2017 1:14 pm
by Bart
What if we reintroduced them in an unused tag? For example, original_size="0x200000" or something like that?

Re: Major code change pushed

PostPosted: Mon Jul 31, 2017 5:33 pm
by CiroConsentino
No need. This is your project, your rules.
Like I replied earlier, don't worry about it Bart.

>> What if we reintroduced them in an unused tag?

If you do that, then wouldn't be the same as adding the size tag ? Plus, if the set changes, you'll have to update this "original_size" tag as well.

A tag that it's there and won't be used at all by the emulator ? That works, but it's unnecessary. Supermodel3 users will not notice the lack or ROM sizes info...
Please don't go around changing Games.xml because of me. I just thought that due to recent emulator changes, the size tag was left out by mistake. If it was intentional, then I'm fine with it... seriously! :D

Re: Major code change pushed

PostPosted: Wed Aug 02, 2017 11:10 am
by Bart
CiroConsentino wrote:No need. This is your project, your rules.
Like I replied earlier, don't worry about it Bart.

>> What if we reintroduced them in an unused tag?

If you do that, then wouldn't be the same as adding the size tag ? Plus, if the set changes, you'll have to update this "original_size" tag as well.

A tag that it's there and won't be used at all by the emulator ? That works, but it's unnecessary. Supermodel3 users will not notice the lack or ROM sizes info...
Please don't go around changing Games.xml because of me. I just thought that due to recent emulator changes, the size tag was left out by mistake. If it was intentional, then I'm fine with it... seriously! :D


It's really not a problem to add. If you want to add these tags, go ahead. Just maybe make sure the code can gracefully handle missing tags. Think of it as extra metadata.

Re: Major code change pushed

PostPosted: Wed Aug 02, 2017 12:16 pm
by CiroConsentino
No worries. I just finished coding a function in my frontend to parse the games and their ROMs from "Games.xml" file, and replace the ROMs from child sets into the list of ROMs from parent set (using file "region" and file "offset" tags). File name and CRC32 are left out. It takes around 1.7 seconds to read the list and create a games list database compatible with my frontend. I can't just mount a games list and ROMs list directly from Games.xml though.

My frontend uses CRC32 checksum to validate ROMs of sets. The ROM size and ROM name are of no importance.