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.

2561

clrmame Discussion / Re: MAME4Droid

« on: 20 November 2011, 09:08 »

load a mame4droid datfile in the profiler, setup rompaths in settings, go to the scanner and scan. add missing files, rescan till nothing is reported anymore.
pretty the same as for any collection. in other words, follow the common cmpro tutorials

2562

clrmame Discussion / Re: How to derive 'snaps' from rom dat

« on: 19 November 2011, 12:12 »

a datfile needs checksums. without you're lost. rebuilder matches files by checksum compares.
my idea with the rename wizard would be the way to go with some manual work afterwards. the rename wizard would see the renames from current mame to 72 and then applies them to a 3rd dat like a current snapshot one.

2563

clrmame Discussion / Re: How to derive 'snaps' from rom dat

« on: 18 November 2011, 08:47 »

hmm...

for the names...I guess the easiest would be to use xslt to translate a .72 mame dat (in xml) into a datfile of snapshots...should be pretty easy (take the setnames as rom entries and add png).
Or you scan an empty rompath with the .72 datfile and export the missing list and edit that later on..

...but how do you want to add things like checksums and sizes of the pngs?

It sounds like you want to verify your snapshots....but how can you verify them if you don't know the correct checksums/sizes.



Or, as an alternative solution you might be able to use the rename wizard in cmpro's profiler. There you can load 2 dats (a current one and a .72 one), it will analyze the changes and you can apply the changes to a dat. So theoretically you can transform a current snapshot dat into a .72 dat (but it might not include all entries since there might be removals which can't be reconstructed...


and besides of that: I don't see any need in using anyhing but the current MAME version..

2564

clrmame Discussion / Re: clrmamepro, mame, old roms

« on: 16 November 2011, 00:04 »

well, look what cmpro's scanner tree output lists as missing...
if MAME says you're missing files you're missing files...
and these files are listed within cmpro's scanner output...either in the set itself, the parent set (if you're looking at a clone), the bios or -if needed- in a device.

so what file does MAME complain about?

Take a look what cmpro says about neogeo set...I'm pretty sure you don't have the latest one.....and of course use the MAME binary you're using for playing within cmpro's profiler to get the data from. Otherwise you don't compare apples with apples...

2565

clrmame Discussion / Re: Newb without a clue!

« on: 05 November 2011, 17:53 »

First of all, clrmame is a Windows application, it does run under crossover though...maybe with some hickups here or there.

Generally clrmame can be used to audit files for a given datfile. Audit means it can check your files against the data provided in the dat, and some if not most issues can be fixed by clrmame. Of course it cannot magically create files which you don't have.

So, find yourself a datfile for Mame4Droid which can be loaded into clrmamepro's profiler, then setup a rompath in settings which points to your rom archives, then go to the scanner and scan. It will tell you what's missing / what is wrong with your collection....and if the fix options are enabled, it can upate your sets.

2566

clrmame Discussion / Re: MAME ROM's and CHD's in separate subdirectories

« on: 05 November 2011, 07:07 »

you're welcome. by the way, the eye picture is from a c64 game (also amiga/atari iirc) called ******** happy guessing.

2567

clrmame Discussion / Re: MAME ROM's and CHD's in separate subdirectories

« on: 04 November 2011, 08:32 »

The rebuilder checks all files in the specified source folder (or what you drag'n'drop either in the scanner or rebuilder window), checks if the files matches anything in the loaded datfile and creates all instances of this match in the set destination path and uses the correct naming there.

So, everything valid will end in the rebuilder destination path and only there!

The destination path is not necessarily a rompath, but usually if you want to use the rebuilder as a nice and fast way to add files to your collection, it is.

When you require multiple destination paths, the only option currently is to use system default paths (where you can only split files by systems).

Some general facts about the rebuilder:
- it does not (yet) rebuild chds
- it does not rebuild samples
- it adds files to the destination, it does not overwrite the archives there, it adds the files and if an archive does not exist yet, it creates it.
- it's file based, not set based, this means you do not necessarily get full/complete sets as an output
- it creates all instances of matches, i.e. if 10 sets (which don't have a parent/clone relationship) all got 1 single rom in common, the rebuilder adds it to these 10 sets.

2568

clrmame Discussion / Re: MAME ROM's and CHD's in separate subdirectories

« on: 03 November 2011, 21:45 »

Set = a set of ROMs/CHDs/Samples; ROM = a single IC/PAL/GAL dump
So you got a set called "pacman" which consists of e.g. 8 single ROMs. Or you got the set area51 which consist of 1 chd and several romfiles. Usually romfiles are kept in an archive (zip), while chds are stored in a subfolder named after the setname. There are also chd-only sets.

The rebuilder does not rebuild chds, only roms.
Scanner's fix missing option scans various places for a missing rom/chd and if it finds it, it will be moved to the correct place. Correct place is either where part of the set already exist or -if nothing of a set exists- the 1st rompath.

You said you clicked auto-detect in systems, which means you DO use system default paths.
Now you scan with system default paths enabled but you rebuild with no use of system default paths...which is most likely not what you want. If you use the rebuilder as an adder, it should move the found files to the place you're prefering in the scan...and there you're prefering the setup sysdef paths.
System default paths means that you assing a rompath to each bios based system (and default/mechanical/devices). This is usually done if you want to organize sets in various rompaths, split by systems, e.g. neogeo belongs to rompath x while naomi belongs to rompath y.

As mentioned in my earlier post, in that mode you won't be able to split chds in an own rompath. If you got a naomi chd, it will be moved to the folder which is assigned to naomi. If you got a Triforce chd, it will be moved to the folder which is assigned to triforce and so on but the same applies to the roms of that set.

So if you really want to keep chds in a different folder than the belonging set (I still wonder why it should make sense to split sets apart ) you need to disable the usage of system default paths. This can be done by removing all assigned system default paths. Double click the path and don't select one in the folder browser. This will clean the entry. You will see that there's a tiny bug in 4.01 which doesn't allow you to alter the last entries in the list, so you can either create a new profiler or wait for the next version or edit the belonging .cmp file of the used profile (cmpro settings folder) and remove the entries Misc_BIOSSets, Misc_StandardBIOSPath, Misc_StandardMechPath and Misc_StandardDevicePath


So to sum it up: If you really want to keep chds in an own folder, get rid of system default path settings.

2569

clrmame Discussion / Re: MAME ROM's and CHD's in separate subdirectories

« on: 03 November 2011, 19:23 »

Generally I think it doesn't really make sense to keep chds in a different path than the belonging set (like why keep area51.zip here and area51.chd there....it's one and the same set). And keeping laserdisks again differently...erm? for what? But anyway, tastes do differ.

If you don't use system default paths, you can keep chds in an own rompath, however you need to be aware that found missing chds or wrong named chds will be moved to their belonging set's rompath. In other words, you may have to manually take care of the chds a bit. If the set is not (yet) available, the 1st rompath is used.
If you do use system default paths, you will get warnings about wrong placed chds since system default paths organize rompaths by system and won't accept a folder for chds.

2570

clrmame Discussion / Re: Availability of older versions of clrmamepro

« on: 03 November 2011, 08:21 »

ah that...ok..that has nothing to do with torrent(zip).

Look at the history of 4.00b:
fixed: biossets with set romof are not handled as biossets (sys1 with soundboard)

So the current (>=4.00b) interpretation of that constellation is imo more correct. Since it's really a BIOS set, it will be handled as one (and not as a normal set (bar) with reference to a BIOS set (foo)).

2571

clrmame Discussion / Re: Availability of older versions of clrmamepro

« on: 02 November 2011, 20:35 »

people shouldn't use torrentzip...easy as that
It does not support utf8 filenames and will actually kill utf8 stored names since it will reencode the names with local page encoding and in the past it used to have wrong size entries in the zipstructures which didn't match the real comment field length which was used to store the checksum etc...no idea if they ever fixed that...
...but besides that, it shouldn't be a problem to scan the provided data/files.
If you get not separated biosrom file /missing BIOS rom messages you should investigate the datfile for the mentioned name. Especially if the BIOS entries are well defined in the dat. There was a change in 4.x regarding the option to "keep bios files separated" but actually it was only an alignment of the rebuilder/scanner functions for this.
Default should be "separate bios sets" enabled in scanner advanced and rebuilder advanced.

If you find something spooky with more details, let me know

2572

clrmame Discussion / Re: Availability of older versions of clrmamepro

« on: 02 November 2011, 19:45 »

Generally I got all versions (well, from 3.111 onwards) in my SVN repository but I don't keep binaries.

What aspect do you want to compare anyway. It is recommended to use the latest (4.01) since it a) supports unicode and b) is faster in all aspects compared to 3.x.

2573

clrmame Discussion / Re: Dir2Dat Limitations

« on: 02 November 2011, 09:20 »

Since dir2dat tries to follow the mame set loading and placing rules
(rompath\setname\file 1...file n), the only trick you need to follow is most likely to point to the parent folder of the folder you want to get "datted".
..and enable:
Scan Subfolders
Set-Subfolder Mode

So if you want to collect all files to a dat within folder c:\test\bla (and subfolders), let the dir2dat input point to c:\test...and it will create 1 set named "bla"

2574

clrmame Discussion / Re: Easy way to update .zips with new roms?

« on: 31 October 2011, 06:25 »

there's also an option in the scanner context menu to automatically make a scan after the dragndrop/rebuild operation. so drop, see the updated scan result, drop more, see the update again and so on

2575

clrmame Discussion / Re: CLRMamePro 4.01 does not detect some updated neogeo romsets...

« on: 30 October 2011, 19:26 »

good you solved it. maybe I should add a one time prompt warning if not all systems are enabled.  we'll see

2576

clrmame Discussion / Re: CLRMamePro 4.01 does not detect some updated neogeo romsets...

« on: 30 October 2011, 07:24 »

it is enabled by default as all systems and new systems are.
maybe it was disabled as a sideeffect of so me init issues in 4.0. however you always see in the window title line if sets or systems are not enabled (the. it shows something like x/y sets...).

2577

clrmame Discussion / Re: Easy way to update .zips with new roms?

« on: 30 October 2011, 07:19 »

the rebuilder is an adder. let the rebuilder destination point to your rompath the. simply dragndrop files in the scanner tree window (or within the rebuilder itself).  before I'd do a full scan with all check and fix options enabled.

2578

clrmame Discussion / Re: CLRMamePro 4.01 does not detect some updated neogeo romsets...

« on: 29 October 2011, 19:56 »

be sure that:
you scan against the same mame version which you used for starting the game
you scan neogeo sets (system selector)
you got the mentioned set enabled (set information screen)
you do a full new scan with all check options enabled (esp. the hash ones) and maybe with a cleaned cache.
and finally maybe check the zip for structural errors

since Im on holiday these are my common guesses. you can try to send me your setup and files for more testing later next week.

2579

clrmame Discussion / Re: CHD deep-scanning with recent CLR builds

« on: 27 October 2011, 07:22 »

look at the verify routine in chdman (chd.c) and you will see that chdman calculates both hashes md5/sha1. Actually cmpro already does better here since it only calculates hashes which are needed (newer chd versions only store sha1).
Easy test for you: copy the chd to a local drive and test it there. With chdman and clrmame.

However, I do have a slowdown in cmpro 3.x with local drives but it's not related to hashes or networkdrives. But 4.x is as fast as chdman so I can't really say it's gcc/hashes/drive based (it could be zlib though...since that was updated in 4.x).

gcc compile is no option, cmpro is a vs2008 project and I don't want to spend weeks to get it running
with gcc (if even possible).

I may find some time to look a little bit more deeper into that 3.x/linux slowdown of November. On the other hand, 4.x is fast on the prefered platform

2580

clrmame Discussion / Re: CHD deep-scanning with recent CLR builds

« on: 25 October 2011, 07:55 »

cmpro uses the chdman source code, so functionally, it's identical and actually the verify process is pretty straight forward. Loop over all hunks, read them in, decompress them (if needed), calc sha1/md5/crc32s...

The only changes are:
1) the zlib decompression and crc32 calculation points to the ziparchive class' zlib module (it's plain zlib as in MAME)
2) the OS dependent I/O routines point to windows api calls
3) the sha1/md5 calculation is threaded and uses C++ classes for MD5/sha1
4) cmpro is compiled with VS2008 and not gcc

I did already some tests with several changes to the above setup with the 3.x build...however, no real bottleneck was found. Generally it's slow. It might be a combination of slow reading (maybe chdman does some better buffered reading) and compiler settings...so maybe 2) and 4) are the main reasons. What I still wonder is that 4.01 acts so fast compared to 3.x (on Windows system, no network drive) while the only difference there is the updated ziparchive lib and an unicode build.