Home Page Forums MAME QMC2 Questions, suggestions or requests topic

OK, that's also working in SVN r4809 now. I'm currently building new Win32 packages...

Note that when you mount software-parts from multiple software-entries (manually) the suggested image path will be the one for the *first* software-entry. I'm generally prepared to let the user choose which one to use, but that's not fully implemented (I'm unsure if it's really worth it, though).

so you keep track of the order of parameters if someone e.g. loads both a System 6 HD from mac_hdd.xml and a couple of floppy disks from mac_flop.xml, right?

I guess that once you try c64 with floppy + cart + tape you will start to understand why we decided to move the choice on users' shoulders with the -snapname parameters %d_cart and %d_flop2 etc.

No, I don't keep track of the order in which the software entries are *selected*. The "first entry" in this regard just means the first one in the list (from top to bottom, honoring the current sort order). It's only about the suggested path/name for the snapshot created by QMC2's embedder, but as with the snapname adjustment (where this works!) QMC2 should let the user choose which one to use if this is unclear.

Yes, I DO understand your motivations regarding -snapname .

I've added clean support for this in SVN r4811. I just don't feel like I want to build the Win32 binaries again ...

This screen shot shows what I mean exactly (and how it's done now since SVN r4811):



You'll only get a menu when there are multiple SW entries in use, otherwise it's shown as a single menu-item (like the others).

Before you ask: no it doesn't really make sense to store those images as flyers, PCBs or whatever else , and that's why those items are separated from the more useful ones at the top of the menu. But then again, those are just generic "image types" and who knows what the user might want to use them for .

Brilliant, Exactly what I wanted. Thank's again.

Well, I actually wanted it myself ... I've meanwhile also added two tool-buttons (right of the "Clear" button) which replicate the same functionality as "save as" and "use as" in the image-viewer's context-menu for the currently selected thumbnail (a QMenu can gladly be reused as the menu attached to a tool-button, because it doesn't take ownership of the menu object).

Hi Rene, have any variant for speedup fix start qmc mame ?
I test the last your qmc build , work very good btw.
With this build qmc mess start for 2-3 sec., qmc-mame - about 20 sec .
Tnx

Well, MAME currently has more than 12x as much sets as MESS (i.e. 28495 vs. 2276 in MAME SVN r22104). Taking that fact into account it's actually quite fast.

I can't change this basically, but there are some ways to speed things up by disabling ROM state filtering, additional DAT sources etc. However, with all that enabled it takes just about 18 seconds here (~14 seconds when QMC2's caches are already cached by the file-system, ext4 here).

Note that if you only want to "play the games", there's also "QMC2 Arcade" which loads in less than a second. Only because it doesn't process all the data...

That said, there are probably ways to speed things up a bit here and there, but I doubt that it's really worth the hassle. Whenever I find a way to do things faster I usually revise relevant code if possible, but I'm pretty sure that the initial loading is already mostly optimized. Don't forget that all the data has to be inserted in the views which is a major act. Only Qt itself can speed this up (and there are some areas where Qt 5 actually DOES this, for instance QMap's which are implemented differently in Qt 4 vs. Qt 5, and QMC2 makes great use of them).

I've anyway checked to see if there are possible ways to speed up loading and found at least one that gets me about 2 seconds here . I can probably reuse this approach at other places...