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: How to check Progetto Snaps?

« on: 23 October 2016, 21:44 »

Thanks for the clarification. Just had the feeling it gets slower and slower the more matches it found. If i reckon correctly the first 10.000 creations were found in the first minute whereas the last 20.000 needed maybe an hour. Edit: Never mind... as you already said all dupes are created at first approach. That's why it probably boosts in the beginning.
Will do more testing on the titles set with 64bit version (if it runs on Wine). Edit: Works. Felt much faster (like 20mins) but title dat is smaller than snaps. Maybe not comparable.

I doubt a 32/64 bit change will bring you a speed boost.

I rather hoped you would have put some individual processor specific intrinsics there like _mm_crc32_u64 (SSE4.2 hardware accelerated crc32 calculation, multi-threaded).
On 32bit version the CPU is constantly stalled at 1/4 only (on 4 cores) that is typical for single core limitation. I found some entries about parallelization/multithreading in CMP history (somewhere 2008) but it doesn't look like it has any effect here or has been dropped already (or is Linux/Wine issue).

2

clrmame Discussion / Re: How to check Progetto Snaps?

« on: 23 October 2016, 19:52 »

So a 'Matched File' entry is just the comparison between dat crc and file crc (successful or unsuccessful)? "Match" rather sounds like a successful "crc match".

The DAT file is 3.4MB, has 132 'machines' and 59593 'crc's. There are 37449 files to check/rebuild. There is a range of 37.449 - 2.231.698.257 theoretical comparisons. I had 164.413.030 "Matched Files" (comparisons) that are ~7.4% of worst case count. Every file needed 4.39 tries (average) until "created".

In case that is correct it doesn't sound all too bad but it really needed a long time nevertheless like an hour or so. I already processed all files on tmpfs (ramdisk) with sha1 disabled and 'uncompressed files'.

I used the 32bit version (more out of laziness as it is provided by Arch User Repo). Are there noticeable speed improvements in the 64bit version (multi threading, hardware hash calculations...)?

3

clrmame Discussion / How to check Progetto Snaps?

« on: 23 October 2016, 04:33 »

Hallo,
i've downloaded Progetto Snaps 'Full Set 0.170' up to 'Upd 0.178' (for MAME 0.178) and extracted them into separate folders (9 folders). I use provided Progetto DAT file and rebuild the snaps (without compression). Right now there are more than 100 million(!) matches and it needs very long to process (for just some PNGs). It seems it gets slower and slower with raising match count.

Where are these matches come from? The DAT file doesn't hold such a high count of files. I guess something is not correct here.

How can i properly rebuild/check the snaps/titles?

Arch Linux x86-64
Wine/CMPro 4.031a (32-Bit)
Progetto - http://www.progettosnaps.net/snapshots/



Edit: These are the final statistics and it looks like CMP did it properly nevertheless (36825 files). The scanner doesn't show any 'snap' folder entries either so i guess its complete. But the question is still why does it need so long and where is the high match count coming from? Never seen that before.

Code: [Select]

Source-Files:           37449

- now even counting files in archives -

Analyzed Files:         37449
Created Files:          36873

Matched Files:          164413030
Skipped Files:          21886

4

clrmame Discussion / Re: One build for SSE1 processors?

« on: 19 November 2015, 18:35 »

Works properly.. Thanks! 

5

clrmame Discussion / Re: One build for SSE1 processors?

« on: 19 November 2015, 15:43 »

Sounds promising, thx. If you need a tester.. i'm here.

6

clrmame Discussion / One build for SSE1 processors?

« on: 18 November 2015, 20:42 »

Hallo,
i know you don't support XP anymore but i'm running Win7 on an AMD-K7 (AthlonXP) that is SSE1 only and doesn't run latest ClrMamePro builds. Can you at least release one build for SSE1 processors? Depending on your compiler its just one option to set (-march=pentium3 for gcc or /arch:SSE for
Visual Studio).

7

clrmame Discussion / Re: cmpro 4.06 released

« on: 20 June 2012, 01:47 »

'Testing Unneeded' hangs here when scanning 'snaps' (3800/19000 files). I kicked the process after 10min. It looks like cmpro is horribly slow.

Edit: If i disable 'unneeded' check it just hangs anyway so its something different but i have to kick the process always since cmpro doesn't respond (even though the scan animation still works).

Also the scanning process (roms) is much faster when minimizing the 'Scan Results' window (if massive output is coming). It might help to lower the window update rate.

8

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

« on: 18 November 2011, 22:00 »

The 0.72 set is for the XBox360 version. They picked that release for portability reasons i guess.

My first attempt was a manually created DAT file with all files set to 'size 0' and 'crc 0' (via text processor). CLRMamePro scanner didn't like it (kind of high cpu freeze, i killed the task). The rebuilder also doesn't found a match either. I was hoping for blind name selection but couldn't figure out a solution.

In the next attempt i stripped everything but the filenames out of the DAT (text processor, regular expression) and inserted a simple copy process.

copy 005.png "G:\Snap 0.72" >> g:\log.txt
copy 1941.png "G:\Snap 0.72" >> g:\log.txt
copy 1941j.png "G:\Snap 0.72" >> g:\log.txt
copy 1942.png "G:\Snap 0.72" >> g:\log.txt

That was somewhat ok but i then realized that many snaps were renamed and got changed over time and there is no real relation between old and recent snaps ending up in many missing pngs.

The other thing is the current 0.72 frontend for the XBox360 doesn't take clones into account so i would have to duplicate every png for its clone individually. Windows frontends handle that automatically.

In the end i gave up. Some guys already did some great work reaching 3660/4098 PNGs by manually working it out. I think i will use that collection.

Thank you!

9

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

« on: 17 November 2011, 20:55 »

Hallo,
i want to create a 0.72 snapshot set. Since i cannot find any proper snapshot dat i have to convert/create/derive it from the rom dat somehow.

Filenames in the rom dat are 'sets'. For snapshots they must be 'roms' i guess. I want clrmame to rebuild just by filename (1942.png). Any idea how to achieve that?

   <game name="1942">
      <description>1942 (set 1)</description>
      <year>1984</year>
      <manufacturer>Capcom</manufacturer>
      <rom name="01d_sb-2.bin" size="256" crc="8bb8b3df" sha1="49de2819c4c92057fedcb20425282515d85829aa"/>
      <rom name="01m_sb-9.bin" size="256" crc="4921635c" sha1="aee37d6cdc36acf0f11ff5f93e7b16e4b12f6c39"/>
      <rom name="02d_sb-3.bin" size="256" crc="3b0c99af" sha1="38f30ac1e48632634e409f328ee3051b987de7ad"/>
      <rom name="03k_sb-8.bin" size="256" crc="f6fad943" sha1="b0a24ea7805272e8ebf72a99b08907bc00d5f82f"/>

10

clrmame Discussion / Disabling 'Recompress Files' is not byte-exact

« on: 02 February 2011, 15:50 »

Hallo,
1) when disabling 'Recompress Files' (Rebuilder) the output file differs by 2 bytes compared to the original. That brakes hashes (of the zips).

2) Is it possible to use external 'one argument packer' (Recompressors) like 'compressor.exe %1'?

3) When updating TOSEC/Amiga archive it has many datfiles for different folders. Many files have traveled between these folders and were placed into the backup folder (where clrmamepro has created a subfolder for every dat).
I have to take further rebuilder passes for every dat file at the end from backup folder to dat destination. When i press 'Use backup folder' it points to the backup/subfolder not the backup folder itself. Could you add an option that the button outputs the parent backup path? Or is there any easier method?
Using batch rebuilder (as final pass) solves the problem.