Print

[ressurectionx]

FBL Favorites

Hey BB...

Here's the FBL favorites list with the fixed romnames.


The first line of the doc is how many favorites entries there is.....



After that, there is 7 lines for each game.  The first line is the zipfile name without the extension.  The second line is the name we want displayed with the .CUT files.  (IMG:style_emoticons/default/smile.gif)

This post has been edited by ressurectionx: Apr 30 2010, 12:44 PM

[ressurectionx]

I've got all the .CUTs and images for MAME now BB, but they still look like crap with the "gibberish".zip

What would you need from me to get these changed to the real names?   We'd need just the *.cut and *.tbn to be changed to full names.

[Bomb Bloke]

Oh! I saw your post stating "I will post the list", but never saw the new post icon to indicate that you later had posted the list... After a few days I figured you'd forgotten about it.  

With any luck, I should have some time tomorrow evening to take a look at it. At a glance, I see that the INI doesn't always follow the rules you stated, but hopefully it won't take too long to get it parsed.

[ressurectionx]

Cool

And I'm still trying to figure out or get somebody to tell me which file CoinOPS uses to make the long names as well.

I figure with both sets I may have to do some manual work, but if we could get a majority of them renamed that would be great.

[ressurectionx]

Well... I can't find anything good for CoinOPS, so I'm just going to rename 3,200 files by hand I guess....

If you could figure out the FBL from that document though, you'd be saving me about 8 hours of manual labor probably  

[Cospefogo]

QUOTE(ressurectionx @ May 15 2010, 07:11 AM)

And I'm still trying to figure out or get somebody to tell me which file CoinOPS uses to make the long names as well.

Hey Rex,

Every single game name is hardcoded inside the MAMEOX.XBE, that huge file of ~40Mb.
You will need to HEX EDIT the file to be able to see its contents, and the only thing you
can do it to REPLACE letter/numbers from the game names with BLANK SPACES, keeping
exactly always the same number of characters coded in the executable.

If you add one new letter (that was not there) you will be adding 1 byte to the program,
and the whole universe will burst over your head.

You can do things like, transforming:
S h i n o b i ( B o o t l e g )

Into:
S h i n o b i _ _ _ _ _ _ _ _ _

Where the char _ represents blank spaces.

Something like:
S h i n o b i [space][space][space][space][space][space][space][space][space]


That's it.
C.

[ressurectionx]

Yeah... Thanks cospefogo, but I'm not looking to actually change any names in the emu itself.  I'm just looking to change the *.CUT and *.TBN names for the shortcut files for command line launching in XBMC.

Hopefully with that favorites list I made for FBL we can get the process automated for Final Burn Legends and the Shared roms.  Looks like I'll have to edit about 2,600 more CoinOPS files by hand.   Hopefully we'll have the shortcuts ready to ship in a few days.

Later,
~Rx

[ressurectionx]

Nevermind on this BombBloke

Changing the file names does nothing.  It displays a name that's inside the .CUT files themselves.  

The "Label" field

I have no idea how to fix this in a way that won't take me another month, so I'm just going to upload them as-is

[Bomb Bloke]

Sorry, family stuff kept me busy yesterday.

I coulda told you that changing CUT filenames does nothin'. Even if it did, FATX would cause all kinds of problems - you should know that already!    It was already my intention to simply alter the label tags. I'm not sure why this would require any large amount of time once my coding work is complete?

I'll probably skip on pulling game titles from that MAME XBE, though. I could hard-code an extractor to grab the string array out of the executable, but for every new version of the XBE that gets released, I'd need to update the extractor... and a dynamic reader (which could handle any version) is a bit out of my league (it'd need to parse machine code...).

Anyway! I'll probably have a new generator up in the next few hours or so.

[Bomb Bloke]

Done.

However, on testing with my (tiny) NeoGeo ROM collection, I see that there doesn't seem to be all that many listings for de-crypted games in that "favorites.ini". For example, the first three Metal Slug games (1, 2 and X) will be detected correctly (as they were never released with encryption), but only encrypted versions of the later games in the series will be picked up (eg, "mslug3" instead of "mslug3nd")... And seriously, who wants to keep their games encrypted?! They take longer to load that way, and the compressed file size is typically around double for encrypted sets.

[ressurectionx]

Well..... I'll take a look at it and see if I can do anything with it that isn't too much work.  Even if we can do the FBL automated, I can't imagine I'm going to find the desire to change the label field in 1,600 CoinOPS CUTs though.

We'll see how ambitious I'm feeling this week.  Maybe I can get some help on this from other members.  

[Bomb Bloke]

Figured out a solution of sorts to deal with the missing sets in "favorites.ini". If it can't find something like "mslug3nd", it'll chop the rightmost character off the end and search again, and then repeat once more if that also fails.

Sticking with the "mslug3nd" example, it'll match it with "mslug3", and decide that the ROM must be a child of that entry. Since I can't accurately have it determine which child in all cases, it'll simply put the suspected parent/child relationship in the label, and leave it to the user to figure out.

For eg,

"Metal Slug 3 (mslug3nd, child of mslug3)"

And if people don't like that, they can either get an INI file that covers all the child sets, remove the child sets from their collection completely, or manually edit the labels when the generator's finished its work.

Of course, if even that process fails to get a match, it'll just use the filename as the title, same as before.

Regarding CoinOPS, one way to get around the problem of compatibility with future releases would be to rip the list from that XBE to text format, then distribute the document with the CUT Creator package. That way, updates to CoinOPS wouldn't matter. Though I'd first want to get permission to distribute that list (from whoever coded up that XBE file), and I'm not sure who to ask.

It would probably be easier to get the list from source, too, rather then trying to read it from the compiled XBE. Even better would be a copy of the original list used during the development of the source (which I imagine would look somewhat similar to FBL's INI file).

[Bomb Bloke]

A zipped/rar'd encrypted set will be much larger then a zipped/rar'd decrypted set. To memory, the difference for Metal Slug 3 is about 30mb.

The two versions contain the exact same data, but the encrypted version has it stored in a much more "random" format - compression alogrithms get better results with "predictable" data. Note also that emulators can't run encrypted ROMs, they have to decrypt them before execution anyway. I really have no idea why people bother to distribute encrypted versions. It's kinda like the old "zip file stored in another zip file" stupidity, only worse.

[Bomb Bloke]

QUOTE(kenshiro @ May 19 2010, 03:00 AM)

False. The encrypted / decrypted sprites data of Neogeo games has exactly the same size. It is only a descrambling algo based on XOR tables.

While it's true that the sets are the same size whether encrypted or decrypted, we're talking about compression potential here. The amount of space they take up when uncompressed is irrelevant to my comments, and certainly doesn't prove them wrong.

QUOTE(kenshiro @ May 19 2010, 03:00 AM)

It is not stupid. It is just a proper way to reference things, and keep  accurate roms sets. Related to mslug3, the decrypted set will use all parent's roms (P-X, V-X, M1) and contains only the decrypted C-X roms, so no waste of space on the HDD.

C as well as P, in this particular case.

Think about it. If you're storing the complete parent set in addition to the child set, then right off the bat you've got two effectively identical copies of well over half the game (those C ROMs are large and numerous).

If that isn't bad enough, one of these copies is taking about roughly double the drive space as the other (as encryption is not compression friendly), and takes longer to load if you try to play it.

This is why people often merge the required parent ROMs into the child set (eg using ROMCenter), then remove the parent set from their collection completely. There's no logical reason not to treat the decrypted versions as parent sets, and remove the encrypted versions altogether. OCD doesn't count as a logical reason, before you bring up the matter of perfectionists who want every ROM ever in the "original format" stored on their drive. All decrypted ROMs lose is encryption.

It's like someone found a file stored in ACE format with minimal compression, then decided that instead or repacking it in a ZIP/RAR, they'd distribute it in both ACE and ZIP format. Together. It's pointless idiocy.

[Bomb Bloke]

QUOTE(kenshiro @ May 20 2010, 12:08 AM)

What will happened if i merge the parent roms into a clone set?

- The set will be usable only for FBA, as MAME doesn't support decrypted sets.

-  I can't remove the parent encrypted set, otherwise i can't play the game with MAME  

I do realise that with current emulators, users are forced to distribute ROMs in this way, though I wasn't aware that MAME was so limiting - obviously it can run decrypted sets (very few sets are encrypted in the first place, and it'd need to decrypt those that are prior or during execution anyway), so it's just being picky.

Another example where you're forced to keep the encrypted parents is when multiple children exist, assuming you want all available children in your collection (eg, emulators typically won't let something like mslug3b6 treat mslug3nd as parent by default). Merging in that circumstance would also lead to data redundancy.

I've mis-stated my point. I'm guess I'm trying to refer to those who determine how their emulators will load games, hence dictating distribution, but truthfully I simply don't know who set the current standards. Really I'm just ranting.  

Ideally, emulators would treat decrypted packs as parent by default (pulling files from the encrypted versions only if need be). This would allow efficient storage and execution of ROMs regardless of which child sets you have, and regardless of whether you want to keep encrypted ROMs or not.

QUOTE(kenshiro @ May 20 2010, 12:08 AM)

You don't understand why some people wanna keep their sets accurate, and on my side i don't understand why people merge the sets and remove the original one.

Really I don't even understand in what context you're using the term "accurate", but to sum up the merging arguement - to save disk space and lower loading times by pruning data you don't intend to use.