Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Roman]

Done

- list control for the result
- sorting support by column
- copy to clipboard (|-separated, no header, all columns)
- save to disk (|-separated, no header, all columns)
- export as mamediff format (oldname, newname + filenames as header)

To Do

- improve fuzzy / best guess test
- option to forbid parent renames (since some dats only work on parents)
- auto patching a 3rd (or maybe more) dat(s) on game or rom level
- save positions, sorting, more messages blabla...



Hey s_bastian, I guess you want to test this....

...check later posts for updated urls...

*edit* yes..I', aware of the "thrild2" issue when comparing 133 vs 132.

 |thrild2a|?|
*|thrild2|thrild2a|matched by single unique rom hash
*|?|thrild2|

so what happened here....
a) there's a missing * in the first line
b) why does the 3rd line show thrild2 as a new file (in the 2nd it's an old)

The reason for both is the "not allow double renames" and the best guess rename finder.
thrild2a is normally a best guess rename to thrild2a but we already have a higher prio rename by single unique rom hash. That's why it gets the ?.
The missing * is simply a bug which doesn't set the indicator in this case....
The 3rd line is simply also a bug based on this higher prio rename just the other way around..

I will look into this over the weekend....anyway...Rename Wizard is WIP

[s_bastian]

gave it a fast run and it is working great. I will give it a more deep testing, trying a "backward run" from 133u2 thruoughout some dats I have here, let's see if something odd happens

[s_bastian]

small bug in the mamediff.out generation: newlines are not properly defined, they should be \r\n

[s_bastian]

I was working with OLD dats, 100u2 to 100u3

Code: [Select]

|nss_smw|?|
*|?|nss|
*|nss|nss_smw|matched by fuzzy best guess
nss is be the BIOS for nss_smw

In this case, only a ROM in the BIOS set was changed, game ROMs were unchanged. I believe in cases like this rename should consider also if changed roms are "merge" or not...

nss_smw in 100u2:

Code: [Select]

rom ( name spc700.rom merge spc700.rom size 64 crc 38000b6b sha1 9f3af3d51c229e67daa68041492afa27287aad31 region cpu2 offs ffc0 )
rom ( name nss-c.dat merge nss-c.dat size 32768 crc a8e202b3 sha1 b7afcfe4f5cf15df53452dc04be81929ced1efb2 region cpu3 offs 0 )
rom ( name nss-ic14.02 merge nss-ic14.02 size 32768 crc e06cb58f sha1 62f507e91a2797919a78d627af53f029c7d81477 region cpu3 offs 0 )
rom ( name mw.ic1 size 262144 crc cfa601e7 sha1 5c9a9a9fccd4b4fcbbda06dfdee41e92dc4e9097 region user3 flags baddump offs 0 )
rom ( name mw.ic3 size 32768 crc f2c5466e sha1 e116f01342fcf359498ed8750741c139093b1fb2 region user4 offs 0 )
nss_smw in 100u3:

Code: [Select]

rom ( name spc700.rom merge spc700.rom size 64 crc 44bb3a40 sha1 97e352553e94242ae823547cd853eecda55c20f0 region cpu2 offs ffc0 )
rom ( name nss-c.dat merge nss-c.dat size 32768 crc a8e202b3 sha1 b7afcfe4f5cf15df53452dc04be81929ced1efb2 region cpu3 offs 0 )
rom ( name nss-ic14.02 merge nss-ic14.02 size 32768 crc e06cb58f sha1 62f507e91a2797919a78d627af53f029c7d81477 region cpu3 offs 0 )
rom ( name mw.ic1 size 262144 crc cfa601e7 sha1 5c9a9a9fccd4b4fcbbda06dfdee41e92dc4e9097 region user3 flags baddump offs 0 )
rom ( name mw.ic3 size 32768 crc f2c5466e sha1 e116f01342fcf359498ed8750741c139093b1fb2 region user4 offs 0 )

[Roman]

yeah..as I said..I'm not yet fully happy with the fuzzy name/best guess check...I will try to tweak it a bit more....

[Roman]

ok..new version up...

- linefeeds in files should be fine now
- assertion in 6th check fixed
- correct handling of newly added sets (the thrild2 issue mentioned before)
- correct showing the * in all cases (the other thrild2 issue mentioned before)


http://mamedev.emulab.it/clrmamepro/binaries/cmpro32_update_20090814.rar
http://mamedev.emulab.it/clrmamepro/binaries/cmpro64_update_20090814.rar


now looking into tweaking the best guess check....

[s_bastian]

- linefeeds in files should be fine now

Checked. They are OK in the game list, the are not in the first row, see where bnzabrsj is placed:

Code: [Select]

F:\Nuova cartella\100u4.dat F:\Nuova cartella\101.dat bnzabrsj
magic102
sspiritj sspiritj

Further to this, alwqays in the 100u4 to 101 passage:

Code: [Select]

*|?|magic102|
*|magic10_2|magic102|matched by unique set hashmagic102 has a double entry, one as unique set and the otehr as NEW SET.
 Odd, isn't it?

[Roman]

ok..will check the 1st row....and yes, the 2nd issue looks weird....*sigh*...if I'd only find some time....but assume that these two get fixed rather quickly....

[s_bastian]

this same problem happens again in 101u3 to 101u4, twice

Code: [Select]

*|?|glass10a|
*|glassa|glass10a|matched by unique set hash
*|?|glass10|
*|glass|glass10|matched by unique set hashlooking at the dats to understandwhat there might be leading to this...

[s_bastian]

Trying to understand if the problem was somewhere else over the dats, I created two small dats with only glass/glassa and glass10/glass10a sets. The problem remains, also if there is nothing strange I can see in the dats... I attach them here as a reference, so you can check it out easier

[s_bastian]

More rumblings on the glass thing:

What happened on 101u3 to 101u4 was:

A new PARENT set called GLASS has been introduced
The old glass (parent) became glass10 (clone) maintaining the same romset but with some roms now flagged as MERGE
Glassa was renamed as glass10a, same roms and same merges as before

So there is more than one problem:
- why was not glass reported as new set in 101u4?
- why is the wizard giving a double report for these set, also for the "reduced" dats that are actually missing the new glass set??

[Roman]

ok...fixed everything for next wip....stay tuned

[Roman]

ok...new toy...

- fixed header line linefeed
- fixed added files
- removed fuzzy/best guess (it was not robust enough.....)
- renamed methods a bit and added new strings for the 2 new options and new/removed sets
- 2 new options, allow double new names and allow parent rename

to do:
- saving/loading of options
- don't reparse when dats haven't changed
- apply changes on selectable 3rd dat

...now back to real life...

http://mamedev.emulab.it/clrmamepro/binaries/cmpro32_update_20090819.rar
http://mamedev.emulab.it/clrmamepro/binaries/cmpro64_update_20090819.rar

[s_bastian]

very good, the glass matter is fixed.
OK, let's go back hunting for bugs!

(PS: don0t bother following all my rumblings, your Real Life coimes first!!

[s_bastian]

This is just trivia, so don't bother fixing them unless you REALLY have the time to do it (and I know pretty well how pregnant wives consider their husband's spare time, so feel free to ignore me!!

bug 1: dats from 099u4 to 099u5:

Code: [Select]

*|tfrceacb|?|double rename
*|tfrceacj|?|double rename
*|tgm2|?|double rename
*|tgm2p|?|removed setThey are reported correctly, but why "double rename instead of removed set?

bug 2:
When ordering by Old Name / New Name, "?" are put between numbers and letters, instead of being first or last of the group. It would IMHO better to put them at the beginning or at the end of the list

Code: [Select]

|9ballsht|9ballsht|matched by unique set hash
*|?|sercharj|new set
*|?|murogem|new set
*|?|funkyfig|new set
*|?|ampokr2c|new set
|a51mxr3k|a51mxr3k|matched by unique set hash

[Roman]

Regarding 1) hmm...could be a mistake when adding the reason/method strings...
Regarding 2) well..the strcmp function (which is used during sorting) sorts by ascii code and there ? is between numbers and characters

[s_bastian]

I imagined something like that, again, that is trivia...

this is instead a more serious thing:
dats from 099u6 to 099u7 (at least, this is where I notice it....)

old mshvsf is renamed into mshvsfu, and a new mshvsf is added. This is all I get from the wiz:

*|mshvsf|mshvsfu|matched by unique set hash

the new mshvsf is not reported anywhere, not even changhing the scan method...

[Roman]

This is more complex.

mshvsf is renamed to mshvsfu ...ok ...correct fine...

"new sets" are listed if they are a) not appear in the old list (which your new mshvsf does) and b) if they are not in the 'old->new name' list.

So actually I can't determine that a new mshvsf was added unless I do a "new -> old" rename check....(which wasn't the original purpose of the rename wizard)....
Hmm....I will think about it...

[s_bastian]

good to know it is not a bug but a "known feature".

No problem, I'll sort that out "my way"

[f205v]

I'm extremely happy about this new development of clrmame.
Now crlmame is no more "only" a rommanager, but it's also a "datmanager"; something I was asking more then 3 years ago.
In addition to this "compare" function, it would be great to have also an "addition" function and a "subtraction" function.
Where addition is: take datfile A and datfile B -> generate datfile C which include all roms from both datfile, whit only one instance for duplicate roms.
Subtraction is: take datfile A and datfile B -> generate datfile C which only includes roms from A not duplicated in B

Am I dreaming?