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

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

1

clrmame Discussion / Re: clrmamepro generates duplicated files

« on: 19 September 2018, 15:48 »

well, I was right...
the clone set jdreddb only consists of a chd, the clone does not have any roms on its own. So as long as you don't have the chd, you don't have the set and cmpro complains about a missing set and if you have the chd check enabled, it will list jdreddb as missing set and missing chd jdreddb.chd.

So everything's fine...you don't have the clone set since you don't have the chd (and that's the only part of the jdreddb clone which exists in a split scenario).

However you can fool cmpro by adding an empty folder jdreddb as container for the chd and the missing set message will go away.

2

clrmame Discussion / Re: clrmamepro generates duplicated files

« on: 18 September 2018, 06:49 »

if I remember correctly jdreddb differs from its parent only in the used chd file. So if you don't have that clone chd file present somewhere, it is possible that the set is marked as missing.

But I will try to repeat your detailed described way later at home...

3

clrmame Discussion / Re: clrmamepro generates duplicated files

« on: 17 September 2018, 16:06 »

hmm....I made a test and an empty (actually this doesn't play a role) jdreddb folder would lead to a message that it should be merged to its parent jdredd when using full merged mode....
so...maybe you can specify or minimize the problem a bit...this was tested with latest official MAME though....

4

clrmame Discussion / Re: clrmamepro generates duplicated files

« on: 17 September 2018, 05:40 »

hmm..empty folder....hmm..ok...it should complain about it (that it should be merged to its parent)...but yes, could be that some "set-got-chd" check hides it....I will double check it. Thanks

5

clrmame Discussion / Re: clrmamepro generates duplicated files

« on: 15 September 2018, 12:58 »

if you switched to full merged sets, then of course the judge dredd clones need to be put to the parent.

Hmm...and if you have natodefa and natodef present and full merge mode enabled, it should also list the natodefa files as wrong placed or wrong merged...

6

clrmame Discussion / Re: clrmamepro generates duplicated files

« on: 12 September 2018, 19:09 »

in times of cheap multi terabyte hds space isn't a real problem...

as an example for identical sets (however it is a parent/clone, not a clone/clone), there is natodef and natodefa, which only differ in the order of levels...which is defined by how mame loads the roms....both machines do exist in reality....and so you have 2 identical sets :-)

I bet there are others where rom sets are identical but chds images differ....or bios rom usage...all these are examples for ending with identical rom sets.

7

clrmame Discussion / Re: clrmamepro generates duplicated files

« on: 12 September 2018, 07:00 »

Nothing's wrong here.

First of all, there are sets which simply have identical clones, where e.g. only the internal driver handling differs or just a different name (which corresponds to the IC on the board name).

Secondly, keep in mind what the rebuilder is. It's not set based, it's file based, i.e. it only creates matching files (checksum compare against database) in the destination, not necessary full sets. If you now got for example 2 clones which are 80% identical and the rest 20% aren't, and you only rebuild files which belong to the identical ones, you end up with 2 incomplete clones which are fully identical. The mentioned sets share a lot of files, kovlsjba kovlsjb as clones only differ in 1 file (*prg.rom), maybe you don't have it, and so it rest of these 2 are fully identical.

You're looking at various clones by the way, not at a parent/clone. There is no merge definition between clones, so identical files within clones are pretty common, if they aren't shared with the parent.

And finally, there is a profiler->options setting which allows parsing "merge" information provided by MAME. By default, these settings are enabled (which is good). If you disable them, cmpro does a merge check by not looking at hashes only but also at names...so byte-identical files which don't share the same name are handled as 'different'.

But again, merging is something between a specified parent set and its clones, not clones against clones.

8

clrmame Discussion / Re: trying to generate no-intro roms

« on: 02 September 2018, 19:44 »

"generate" like in magically create files out of nothing?
so maybe you should specify what you want to achieve in detail....so it sounds like you want to get roms for various systems....well....you need to find a page where you can download them...but of course this is most likely a violation of copyrights....

9

clrmame Discussion / Re: cmpro 4.035 released

« on: 02 September 2018, 06:24 »

the link is listed on the homepage at the Download/Windows 9x/XP Users section

10

clrmame Discussion / Re: Strange bug?

« on: 29 August 2018, 06:43 »

you're welcome, it was only a question of taking the dimensions of the physical or virtual screen into account....

11

clrmame Discussion / Re: Strange bug?

« on: 28 August 2018, 07:18 »

try this...

http://mamedev.emulab.it/clrmamepro/binaries/cmpro20180827.rar

12

clrmame Discussion / Re: Strange bug?

« on: 24 August 2018, 20:42 »

yep it is how you order them to the main one....left ones get negative pos, right ones positive...thanks for testing

13

clrmame Discussion / Re: Strange bug?

« on: 24 August 2018, 10:56 »

I did a quick test at work with 2 monitors (where the main screen is right, the 2nd left) and I placed cmpro at the left one....this will result in negative positions

Win_MainDlgX = -1055
Win_MainDlgY = 1422

...and cmpro resets < 0 values, too....

would be interesting if you also have negative values in cmpro.ini after placing the window on your 2nd screen and closing cmpro (and not restarting it)

14

clrmame Discussion / Re: Strange bug?

« on: 23 August 2018, 20:50 »

as I said...cmpro resets the positions if they go beyond the borders...it's clearly connected to the 2nd monitor and the way how windows functions return the resolution.......most likely the functions return the resolution for one screen only and not twice the width.....should be a pretty easy fix...when I find some time I will look into it

15

clrmame Discussion / Re: Strange bug?

« on: 23 August 2018, 05:45 »

No, cmpro also remembers positions on startup / main window. However such positions are reset to defaults when Windows tells cmpro that it won't fit there. So this might be the case (for whatever reason). Most likely the 2nd monitor thing plays a role here. Easy test, use the 1st monitor and move it near to the bottom right and exit...it will reopen there.

I will test it with 2 monitors

16

clrmame Discussion / cmpro 4.035 released

« on: 21 August 2018, 21:36 »

4.035
added: batcher, scanner, auto save have/miss list options
fixed: case rename on eFAT formatted drives does not work
fixed: profiler sorting of items in "new datfiles
fixed: possible archive loss when fixing names in password protected 7z sets and not using 7z's native rename
fixed: setinformation attributes (size/hashes) for clonesamples/clonechds aren't listed sometimes
fixed: clone sets which only consist of chd nodumps appear wrongly as missing
fixed: chd-only clone sets which only consist of a parent clone are wrongly listed as missing set
fixed: bad 32bit cast causes name check to fail for >32bit sized files
fixed: hashcollision check different sha1 values are not detected when crc32s are identical
misc: strenghten merge attribute rule when datfile holds merge attributes and you got parse merge attributes on
misc: don't show "Sets Option Disabled" warning in batch mode
misc: prompt rebuilder errors only once per destination file
misc: updated to 7z sdk 18.05, rar to 5.60, zipArchive lib to 4.6.6

17

clrmame Discussion / Re: Hash collision (Bug?)

« on: 21 August 2018, 14:32 »

24 hours ? I mean HBMAME is not "that" big and even scanning a full mame collection with sha1 checks enabled etc is done within minutes on a modern system........

The change is actually only called during importing the data, so running speed should not change at all....

18

clrmame Discussion / Re: Hash collision (Bug?)

« on: 20 August 2018, 11:54 »

long in terms of "finding a way to test it" or long in terms of "something is slower than before"

Actually you can quickly check it by opening the setinformation dialog, go the the set in question and check if the filename contains the setname now ;-)

19

clrmame Discussion / Re: Hash collision (Bug?)

« on: 18 August 2018, 15:50 »

grab the latest nightly and retest please (you need to press profiler->clear cache before loading the profile though)

20

clrmame Discussion / Re: Feature Request

« on: 18 August 2018, 15:48 »

grab the latest nightly and retest please