Really crucial question...

[stigzler]

So, I'm adapting GameSetMatch to do fuzzy matching on image sets to enable amalgamation of different image sets in different formats (Hyperlist, ReDump, GoodName etc). The key question is this - in terms of amalgamated sets for GameEx - what format should be used in the final full sets?

From looking at the db3 files - it would appear as though not one standard has all games covered. However, GameEx does. So I'm wondering whether to encourage using GameEx Names as the standard? The one small problem with that is some Names have ":" (colon) in them. However - easily remedied via replace - I'm replacing ":" with " -" which also nicely converts it to other formats too.

What do you guys think?

[stigzler]

Nemmind. Made the executive decision to use the GameEx gamename with the replacement " -" for ":" 

Hope there's no other swerve ball characters in the gamenames, but if so, will just have to accommodate.

[greatflash]

There may be others, though my preference would be for the GX names as well. There are a lot that use odd characters like Japanese names etc. Not sure if they would be a problem though.

[stigzler]

Then GameEx name with that specific replacement it is. Plan is to start building up GameImage resources + wanted to decide on a format before starting to gather/make stuff. I think the nice thing about using the GEF (GameExFormat) is that it maps to all the other naming conventions via your great work on the dbs. Kinda unique for the FEs

Just one thing - they're no changes to radically change the format or db before I start building libraries based on this?

[greatflash]

no, if you are just using the gx names, you should be fine..

[stigzler]

Chipper.

[stigzler]

Hmmm - sorry back to this. So my original aim was to produce new image sets with images renamed to the gx names with the ":" (colon) replace. However, not sure this is going to dovetail well with GE. An example of where this falls down is:

Rom = "007 - Tomorrow Never Dies (Europe).zip"

DB Gamename; "007: Tomorrow Never Dies" (matched via HyperList or Goodname map)

The resulting image = "007 Tomorrow Never Dies" (derived from the game name with the ":" replaced with "" [null])

Of course, you replace with " -" to make it equal "007 - Tomorrow Never Dies" which then works. But then this fails for 007 racing:

Rom: "007 Racing (Europe)"

DB Gamename: "007: Racing"

Resulting image: "007 - Racing"

This then fails (GE does not match the image). However "007 Racing" works.

My deduction is that GE is matching images via the filename formats rather than the db gamename?

This makes producing standardised image sets problematic. For instance, the Playstation db has some games exclusive to one convention (e.g. "All-Star 1997 Featuring Frank Thomas"). Therefore you can't choose one convention versus another to have all games represented...

Dunno if that makes sense? What would be easier is if GE also matched images via a 'filesafe' db name - or is there another work around?

Hard to explain that one....

I'm holding off producing the games logos sets until I know how I'm naming them!  It would be easiest if I could rename to gxnames, but don't know if that's possible. 

[greatflash]

The original intention was for gx to match the database name if used and if no match is found, to fall back to the rom name. Not sure if this was ever implemented though. Only Tom would know. 

The same goes for clones and "also" matching. 

[greatflash]

Also. One thing to remember (and this also goes for Rom names), gx names are subject to change and they often do. Though it is possible for me to output name lists for you as a global list and then a diff compare would again be able to show you the changes. 

[stigzler]

Cheers. Ah, that's not good news. 

I guess the difficulty with basing image names on rom names is that rom names can vary from convention to convention. Thus this would throw people with different sets. 

HL seems the most complete (?) but not sure GEdb is fully populated with this. 

This is why I was hopeful that there was some means to leverage the gx names. My guess is that GX can resolve each rom to the single gxname standard. If these names could be kept consistent then there would be a standard to work from. It would also be a good payoff for all the hard work (you're and a select few) are doing making the system maps (i.e. mapping all of the different conventions to a single gxname). 

There could be an agreed method to convert gxnames to a filesafe format, or I don't know how easy a search/replace would be on ":" (pesky colon!)

Feel like I'm asking a lot of you 'top floor' guys at the moment, but it is just trying to make the gx community awesome and get us some content-sugar!

[greatflash]

Problem is there are thousands of names in the databases and a lot more to work on. But I still feel a unified name is the way to go and things will improve as time goes on. 

[stigzler]

Yeah. Onerous task potentially. 

Totally agree on the Unified name. So - looking through the database for playstation (often my test system) - it's looking like a " -" (space,dash) replacement is better than null. this will transform a lot of the gx names into HL and Goodnames format. Better to have a crossover than none where the option presents, right?

Think I'm going to go ahead and start working to this convention. Thus - image sets will be in gxname format with the ":" > " -" replacement. 

Just thought I'd run this pass you devs before proceeding - shout "FOR THE LOVE OF GOD, STOP MAN!" if i'#m missing anything obvious.

[greatflash]

You may be better using a more complete database as a template perhaps. Something like the snes one. 

[stigzler]

Nice one - yerp  - now added mame to the conventions list!

Looks like the convention still stands though? " -" for ":" - still seems to translate gxnames to nointro and goodnames??

 

[greatflash]

That really should be fine. 

[greatflash]

The gx name is more about allowing non dos/win characters to improve the display than anything else. So replacing the non file characters should be fine.