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.

3341

clrmame Discussion / Re: Packed CHD subfolders are considered to be unneeded files?

« on: 10 September 2009, 20:26 »

You're wrong. Mame does not support it correctly. Try to zip up mach3.chd and try to load it in MAME....have fun. (Besides that standard zip only supports files < 4GB).

Besides of this, what MAME does and what it does not doesn't play a role. MAME loads files in a very lazy way, it simply loads by hash, no matter if the files are in the correct set of a parent/clone relationship. It simply scans everything related for a match.
MAME's loading mechanism is one thing, auditing is something else.

3342

clrmame Discussion / Re: Packed CHD subfolders are considered to be unneeded files?

« on: 09 September 2009, 19:26 »

Nonsense

a) diskspace doesn't matter. In times of terabyte hds and laserdisk chds you talk about a minimum saving
b) chds ARE zip compressed already. CHD is a container for raw data which is sector wise zlib compressed
c) it's a memory hog if you keep chds compressed. You won't be able to run them fine in MAME (except the small ones). Great idea to zip a 15GB file which needs to get decompressed into memory when loading the game and then needs random access on it.


To sum it up: zipping chds is nonsense.

3343

clrmame Discussion / Re: Packed CHD subfolders are considered to be unneeded files?

« on: 09 September 2009, 12:30 »

There are 2 ways to store chds.

Either the good old way:

rompath\setname\chdfilename1 ... chd filename n

or the "we really don't like it" way in a rompath root:

rompath\chdfilename 1... chdfilename n

For this second option you have to enable Scanner->Advanced->"Allow CHDs in rompath root" option.



....since these are the 2 modes, anything else is not supported. Especially not zipping up chds. Where is the sense anyway. CHDs are zlib compressed already. Waste of decompression time and memory usage.

3344

clrmame Discussion / Re: clrmamepro 3.131 released

« on: 31 August 2009, 22:26 »

Maybe later....

Appartment move....Fatherhood...September is a busy month...

3345

clrmame Discussion / clrmamepro 3.131 released

« on: 31 August 2009, 21:27 »

3.131

More on rename wizard:

- changed analysis to 5-pass
  1) unique set hash
  2) single unique rom hash match
  3) single unique chd hash match
  4) description match
  5) setname match
- detecting removed, added and replaced sets
- new layout, list control, sortable columns
- acess via Profiler Button
- keeping positions and options
- added option for enable/disable parent rename
- added option for enable/disable rename to multiple new name
- detecting new, removed and replaced sets
- export to clipboard, file and file (mamediff format)
- diff button only reparses files if needed


- ability to apply renames to a 3rd datfile (e.g. an artwork datfile).

  You can select 'apply on sets' or 'apply on roms' method.

  'Apply On Sets' renames set name (description, year, manufacturer, romof, cloneof, sourcefile
  tags optionally), while 'Apply on Roms' renames rom name, rom merge tags. In case of roms, it checks
  the names with and without extensions, so you can easily have them as e.g. *.png.

  This 'Apply' option will only do the renames. Removed, added, replaced sets are not handled.

  Usage example:

  Enter paths to a MAME .133 datfile as old and MAME .133u3 datfile as new.

  Hit 'diff' and see what the renames......now load a MAME flyersdatfile for
  .133 as 'Modify DatFile'. Enable 'Apply On Roms' and hit 'Apply Renames'. It will create you
  a *_new.dat with the updated roms.

3346

clrmame Discussion / Re: rebuild older version - Noob

« on: 29 August 2009, 17:43 »

Sure...load the .123 datfile (or use a MAME .123 binary in the profiler) and rebuild your .133 and .86 sets (keep them as rebuilder source). Rebuilder destination will then hold your created files...the 123 ones...if bad dumps were replaced in between, you need to find the old ones of course...

3347

clrmame Discussion / Re: Rename Wizard wip

« on: 26 August 2009, 09:37 »

yeah..maybe another option to rename the other tags....that should be possible.

...and I don't think there will be another beta, I more think of a release this week since my new home's internet will be hopefully active next week and my old one will be shutdown.....I expect a much worse scenario with no access for some days

Time to moooove.....

3348

clrmame Discussion / Re: Rename Wizard wip

« on: 25 August 2009, 21:47 »

Open question...
...does it make sense to apply (besides setname) description/year/cloneof/romof/manufacturer from the new dat to the 3rd dat....

hmmm....

3349

clrmame Discussion / Re: Rename Wizard wip

« on: 25 August 2009, 19:46 »

The sets do differ...the u2 ones all had a bad dump listed (which influences the set hash).
However there was a little mistake in handling bad dumps which is now fixed.

|sf2049|sf2049|matched by description
|sf2049se|sf2049se|matched by description
|sf2049te|sf2049te|matched by description

3350

clrmame Discussion / Re: Rebuild2.log - Questions

« on: 24 August 2009, 21:24 »

The scan results tree shows all errors in detail and you can export this in any form.

3351

clrmame Discussion / Re: Rename Wizard wip

« on: 23 August 2009, 22:33 »

well....some more coding on it...however no wip exe this time...

- moved rename wizard to profiler
- windowpos/columnswidth and options are saved now
- "diff" buttons checks if a re-parsing of dats is needed
- added 3rd dat mode which allows you to load a dat and apply the found changes on it. This can be in set or/and in rom mode.

Rom Mode: Each rom in each set is checked for an old name match (without taking extensions into account) and the name is updated to the new one (replaced sets and new sets don't play a role here).

Set Mode: Each set name is checked for a match and the name is being updated (again, replaced sets and new sets don't play a role here).

Modified dat is saved to *_new.dat/.xml.

So you can e.g. load a MAME 133 dat and a MAME 133u3 dat and apply the renames on the flyer datfile.
Parsing + diff the 2 dats only has to be once....after that you can exchange the dats to mod.

Open things:

- optionally don't ignore extensions in "apply on rom" mode
- "apply on set" mode is not that easy as you might think....currently it only updates the name. I plan to include description, year, manufacturer, sourcefile and cloneof/romof.....but still, this isn't the full set defintion, so the modified dat has to be handled with care....

Anyway...I started this thing because I didn't want to rename the artwork dats manually.....and something which is a bit more accurate than mamediff....looks like it becomes reality soon....

3352

clrmame Discussion / Re: Rename Wizard wip

« on: 21 August 2009, 13:56 »

http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Number=199520&page=0&view=expanded&sb=5&o=&fpart=1&vc=1

made a little advertising there, too

3353

clrmame Discussion / Re: Rename Wizard wip

« on: 21 August 2009, 11:54 »

wow..more than a day and no reports yet ...

3354

clrmame Discussion / Re: Rename Wizard wip

« on: 19 August 2009, 23:30 »

http://mamedev.emulab.it/clrmamepro/binaries/cmpro32_update_20090820.rar
http://mamedev.emulab.it/clrmamepro/binaries/cmpro64_update_20090820.rar

today's features:
- fixed the double rename issue
- replaced ? with ""
- changed progress window slightly
- fixed some index stuff
- added check of "replaced sets" (aka the mentioned mshvsf thingie...)...well..what it does is: check new dat names against old ones...if there is a match and that old name is not in the list of renames (where kept names are included), show the set as "replaced".

Go and test a bit

3355

clrmame Discussion / Re: Rename Wizard wip

« on: 19 August 2009, 09:13 »

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...

3356

clrmame Discussion / Re: Rename Wizard wip

« on: 19 August 2009, 07:28 »

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

3357

clrmame Discussion / Re: Rename Wizard wip

« on: 18 August 2009, 23:30 »

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

3358

clrmame Discussion / Re: unable to rebuild certain filenames

« on: 18 August 2009, 20:42 »

besides of this, tilde (~), pipe (|), \/:<> etc are of course not allowed in filenames since they are used by Windows for other operatiosn..

Anyway...dat please.....

3359

clrmame Discussion / Re: Rename Wizard wip

« on: 18 August 2009, 20:24 »

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

3360

clrmame Discussion / Re: Rename Wizard wip

« on: 18 August 2009, 14:08 »

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....