mGalaxy forum
General Discussions => mGalaxy Wishlist => Topic started by: mgalaxy on July 23, 2012, 04:18:51 AM
-
Dear users and friends,
I'm planning to open mGalaxy to other emulators.
Before going further, I would like your comments/advices on that particular subject:
For now, mGalaxy runs MAME emulator and uses the native database built in each MAME version.
That database allows you to see all the available games...and forces you to conform your roms and screenshots names to the ones saved in that database.
From my first searches on other emulator systems (let's say SNES and PSX) it appears that many databases exist (logiqx, dat-o-matic, redump...) using different naming convention.
One told me that it might be complicated for the usual user to find romsets and screenshots corresponding to the chosen database?!
So...I'm wondering if it wouldn't be easier for the usual user to have mGalaxy just scan their dedicated roms & screens folder and display the content as it is? (without relying on a database)
As I told you, I'm in the early stage in my reflection.
I'm perhaps missing some important points...or seing the situation more complicated that it actually is?! That's why your feedback and experience is very helpful to me, so please don't hesitate to give your point of view!
In the meanwhile I just set up a simple poll to check your wish.
Thanks for your help!
-
Mess and Mame went combined in latest news. So i would recommend to follow them.
So Mgalaxy for UME Ultimate Machine Emulator.
-
Save yourself tons of support questions by just having Mgalaxy scan the roms folder.
One of the repeating issues I see with Hyperspin is new users always having a hard time setting it up initially because of this.
If you would like to make it a little more advanced I would take the Mamewah route.
Mamewah allows you a few options:
rom_folder = Which just scans the roms folder and displays what is found (useful for consoles)
rom_folder_vs_dat = scans the roms folder and displays those found in the dat file (usefull for other arcade emu's not named mame)
rom_folder_subfolders = this one is useful for cd base emulators like psx where games are in their own folders
rom_folder_vs_list_xmlfile = scans the roms folder and displays those found in the xml (mame only)
-
HI mGalaxy
When you expect the new version ??
-
Im with the scanning of the rom folder. I know its a clean and nice option to have the correct names and such, but man its a hassle useing clrnamepro and the dats with the xmls...... and that and this and him and her...........
yeah just scan the rom folder and the users can do the cleaning up and the renaming of the roms the old fashion way.
cheers ma-tee. ;)
-
I'm pretty exited about this implementation. Would you mind sharing your current progress??
-
Sure :)
I'm working on mGalaxy "Runway" (which is the application to configure key mapping)
This will now be the full mGalaxy preferences application.
There, you'll still manage keymapping, but configure SIMPLY each "systems" too! (Application path, rom path, snap path, activate or not...for each emulators).
MAME will follow the same rules! For the first time (in mGalaxy ;)) MAME (and its folders) won't need to be in the same folder than mGalaxy (or vice-versa).
I'll be working on the main application from October 1!
The goal being to release mGalaxy at the end of that same month!
You know that we all want mGalaxy to stay as simple as possible!? So, no new button and key mapping to switch from an emulator to another: you'll simply press the button that is already used to quit (ESC on keyboard, Player 1 & Player 2 for arcade users). There you'll have the option to switch to another emulator..or to quit!
All the functionalities already present will be kept: for each emulator you'll get your "full" favorite list, your 10 most played and top 10 favorites lists.
That's all I can tell you for now :)
-
hello :) is a beta version expected ?
-
Not for now...If there's one, that should be around October 15!
-
You rule the emulation front-end. Simplicity is the key and you've got a sunning UI. I'm tech savvy but wish I had better fluidity in computing languages.
-
Not for now...If there's one, that should be around October 15!
in the new release we expect to Joystick/Joypad support ??
-
No, not in this release, sorry!
-
Hi, these are very good news, as a long time user of your frontend I always missed the possibility of launch apps like a jukebox, will this be possible with the new version?
-
This is indeed the object of the next update to come!! :)
-
Then you´ll made me the happiest man in earth!!! Any news or updates?
-
Another wish: in my version: (I´m running 1.2) the volume of the sample: ¨Launching Game¨ is not affected by the preset you use high or medium volume, could that be fixed in next versions?
-
How long for the new release or a beta?
-
I FEEL THAT IS TODAY ;) or not :(
-
Hope so
I FEEL THAT IS TODAY ;)
Hope so.
-
+1 to being excited about getting a new version! I'd love to have access to Sega games like Comix Zone right in my arcade interface.
-
any news about the forthcoming release? ;)
-
I actively working on it, things are progressing well...but I need some more time before releasing it!
I still hope to be able to release it during November!
-
I'm worried about my friend what's going on with you but I understand a little slip and you have a big change will probably patch
-
Any possibilities of being a betatester?
-
I'm now looking for beta testers!
If you guys are interested in beta testing mGalaxy v4.0 please send me a mail at info@mgalaxy.com
-
Hi, glad to hear that!!! I just send you an email.
-
me too please :) rash@milc.pl
-
I'm in ;)
-
thanks :) now testing
-
Got the mail, gonna do some testing later today ;)
-
The ideal solution might be to check ROM name against a database, if it isn't there then fallback to displaying the file name for that ROM.
-
Duckeenie IMO has got it right.
A database (something editable, like a .txt or .xml) could be generated using the filenames as they are now (and the MAME rom descriptions). Once it's generated, you can leave it alone or you can get editing. That way, surely everyone's happy and the idea of keeping the rom names up-to-date is placed on the user and not the developer.
What would be needed then, of course, is a way to re-scan the folders to re-create the database(s) for the systems.
I can see two ways of getting this to work:
1. There's one database file (or several for each system). It's generated by mGalaxy according to user demand. If you make amendments in it then mGalaxy will automatically show the changes. If you re-scanned your roms (essentially creating new databases) then you would either have a way to determine what's been changed and leave it alone (a flag in the XML perhaps?) or the re-scan will simply overwrite what was already there.
2. There's one "custom" file (or again several for each system). It's created by the user. mGalaxy uses it's own methods for determining how to name the files, as it does now. If it finds a custom file it checks this against the filenames it has and does a simple substitution.
I think the upshot is that the developer doesn't have to do much, other than provide the tools for the user - they can then amend or leave it as it currently works.
To be completely honest, I'm not that bothered either way. I thought if it is something that users want, then it doesn't have to be a painful job to implement. I'm just happy after trying lots of different frontends to find one that's simple, works and is pretty to look at!! So congrats to the author for doing an amazing job! GameEx, Hyperspin, Mala and all the others have their place - but for me this is the best frontend I've had the fortune to stumble across so far! =)
-
I'm not (at all) against the idea of a database for each system...my main concern is: based on which romset!!??
Gamebase, No-Intro, GoodRoms,... there are a few romsets available, each with different naming convention.
As one can't impose a specific one, that would involve maintaining a database for each romset in each system!?
I'm OK to write a little utility that would make a database out of a folder (or another existing XML?)
All your ideas and suggestions are welcome!!
-
Well - personally speaking - I don't think it needs a naming convention, other than the one that mGalaxy already uses (based on the filename). It's the ability for the user to change what's displayed I think is the request from a few people on here - and it would be a handy feature IMO.
-
Well I'm afraid to not understand!? What's the benefit of a database if it simply lists the rom name without (for instance) allowing you to have the 'correct' (by opposition to the rom name) name displayed or a 'genre' attributed?
What would you gain? Apart from removing games from the list (but you simply could remove them from the folder) I can't see!
-
I've noticed Stefan also mentioned the same idea in another thread (http://www.mgalaxy.com/forum/index.php?topic=341.msg1006#msg1006). Maybe this conversation would be more suited there.
In simple terms:
- mGalaxy creates the file.
- If you leave it alone, everything stays the same - you gain nothing - as you pointed out.
- If you amend it manually in notepad or whatever, those custom rom names show up in the list, instead of the rom's filename. The filename basically gets associated with a custom name.
As an example, the file could be laid out as follows, auto-generated when required by the user:
<RomName>
<FileName>srally2.zip</FileName>
<CustomText>srally2.zip</CustomText>
</RomName>
The GUI then displays the <CustomText /> from the file in the listing, instead of the <FileName />
If a user amends the file manually, replacing srally2.zip with Sega Rally Championship 2 then that's what will show up in the GUI, instead of srally2.zip.
I'm struggling to find a simpler way to put it!! :D
Like I said before, it's not a huge problem for me either way - I just noticed people enquiring about it on here so thought I'd offer some ideas.
-
OK...we are talking of the same thing!...and indeed you would like to have the "real name" displayed instead of the "rom name" ;-)
The only difference between me and you is that you see it from a single user view (each one does as he wants)...when I see the benefit to share all that work among all users...But it requests (that's true) to maintain as many databases that there are romsets available!
The idea:
One user, with a full Commodore 64 romset coming from Gamebase (roms are really bad named!) decide to work on it and begin to associate a "real name" to the rom name...Wouldn't it be interesting to make all this work available to other users that perhaps don't have the technical abilities to do so?
-
I understand what you're saying - and you're right it would be amazing for everyone to be able to rename the roms to something a little better automatically. This as you've pointed out would be a complete headache though! :D
And yes I'm thinking from a single user point of view for simplicity's sake. Maybe people could share their databases on the forums if they've gone to the trouble of creating custom names?
Just an idea anyway! ;)
-
I've think to it...and it's OK, I will implement the scan for a database for each systems.
The presence of this database won't be mandatory (to keep simplicity for 'common' users) but if there's one present mGalaxy will use it.
The argument that finished to convince me is the possibility to have the "real name", of course, but eventually the 'cloneOf' info, the 'genre' of a game and the 'players' info (based on the same scheme that nPlayers (1player, 2players, 2players simultaneously,...)
That would bring the same functionalities (for people taking time to populate their database) than those used for mame.
The database will so be structured that way:
<?xml version="1.0"?>
<dbase build="1.0">
<game name="123abc">
<cloneof/>
<description>Superman</description>
<genre/>
<players/>
</game>
<game name="456def">
<cloneof/>
<description>Supergirl</description>
<genre/>
<players/>
</game>
</dbase>
...and will be part of the next release: v4.2 that I hold until this addition is completed.
-
It's a nice feature and will be welcome for users that want to customise a little more. Thank you and good thinking with the extra functionality :)