|
Joined: Apr 2015
Posts: 387
Senior Member
|
OP
Senior Member
Joined: Apr 2015
Posts: 387 |
Hi,
First off I would like to mention I'd be happy to provide the patch for this, if the idea is not rejected, anyway. It's a slight aesthetic modification intended to enhance frontend integration.
Nowadays, when a MAME session is started, the window is spawned straight away, first displaying the "Initializing" message box (with an additional border outlining the game display area), then the "Loading machine" message box (with the border gone), then any optional decryption messages, and finally any driver warning messages.
This is aesthetically unappealing, to say the least. Even though it's not the case, it looks a bit like MAME is switching resolutions several times.
In MAME's earlier days - I'm talking over 10 years ago - MAME's startup sequence was different, whereby the window would be spawned after MAME is done initializing. This allowed frontends to implement their own 'loading' sequence inbetween process startup and window creation.
Well, how about this for a compromise - if MAME is started with the -console parameter (or another one, though I think it fits well with -console), MAME would go back to the old behavior (not spawning the window until it is initialized, but still retaining any rom warning messages), and instead uses stdout to print status messages.
That way, the frontend gets more control, which could be used to display a nice progress bar, or something more creative (like a cartridge insertion animation for console systems)
To avoid misconceptions; I'm not talking about suppressing the nag screens - though, to be honest, I wouldn't mind not having them in MAME's display anymore but printed to sdtout/stderr as well, I understand and see the need why they're there.
Your opinions please.
Last edited by EoceneMiacid; 09/30/16 10:27 AM.
|
|
|
|
Joined: May 2009
Posts: 2,222 Likes: 387
Very Senior Member
|
Very Senior Member
Joined: May 2009
Posts: 2,222 Likes: 387 |
Anyone paying attention to the project for the past few years can see that MAME is moving more towards its own integrated frontend than supporting other peoples' frontends. MAME has never gone out of its way to cater to other peoples' frontends, and if anything it's moving even farther away from that direction now than it has been in the past. I have no particularly strong opinion one way or another, so far be it from me to reject your idea, but I'm just informing you that it's going to be an uphill battle for you if your proposal starts from an argument of "let's cater to other peoples' frontends". Your proposal itself essentially comes off as "the MAME team has no style, so let's abdicate any responsibility for style or presentation to people who, outside of qmc2, have shown no inclination to provide full support for all of MAME's features". It's a tough sell. What I would suggest instead is, if the current startup sequence is not "aesthetically pleasing" (for whatever that's worth, being subjective from person to person), that you suggest ways of making it more aesthetically pleasing, rather than the non-suggestion of "MAME's presentation sucks, so let's ensure it continues to suck by foisting responsibility off onto a frontend author".
|
|
|
|
Joined: May 2004
Posts: 1,772 Likes: 34
Very Senior Member
|
Very Senior Member
Joined: May 2004
Posts: 1,772 Likes: 34 |
yeah, in the end, as I've stated before, I think MAME will become more of an environment / canvas, where machines can be added / removed on the fly.
at that point everything will change anyway.
external software will probably be able to talk to the running instance, telling it to spawn / despawn a machine as well as that ability obviously being available through the menus.
the existing launch method would likely just be a shortcut for the more complex behavior at that point.
likewise, at that point I imagine front-end authors might want to rethink their approach anyway as you'd potentially have an 'always running' copy of MAME and need to flick between that and your frontend to add/remove machines.
of course we're not there yet, and it could be 10-15 years before that is a reality, if it ever happens, but as MG says, don't expect the project to bend over backwards for frontend authors, that isn't really a consideration.
|
|
|
|
Joined: Apr 2015
Posts: 387
Senior Member
|
OP
Senior Member
Joined: Apr 2015
Posts: 387 |
Anyone paying attention to the project for the past few years can see that MAME is moving more towards its own integrated frontend than supporting other peoples' frontends. I've been paying attention to MAME since the days it exclusively emulated Pac-Man and a few other Z80-based titles, yet this is news to me. MAME has never gone out of its way to cater to other peoples' frontends, and if anything it's moving even farther away from that direction now than it has been in the past. I don't think it should go out of it's way, but I don't see why you would actively oppose it either. Maybe because it 'hides' MAME somewhat and makes it look like the frontend is doing all the work, to the uninitiated? I have no particularly strong opinion one way or another I find that hard to believe so far be it from me to reject your idea, but I'm just informing you that it's going to be an uphill battle for you if your proposal starts from an argument of "let's cater to other peoples' frontends". I'm mostly blind to behind-the-scene emu politics, and I choose to remain that way to preserve what little sanity I have left I just want to make the overall MAME experience as good as I possibly can, and since there's pretty much nothing left to improve on except nitpicks, I'm pickin' Your proposal itself essentially comes off as "the MAME team has no style, so let's abdicate any responsibility for style or presentation to people who, outside of qmc2, have shown no inclination to provide full support for all of MAME's features". Well, since not being honest here won't do both of us any good, I'm going to go ahead and stick my neck out by saying that I believe there's some room for improvement in that regard, yes. And it's such an incredibly tiny regard, to boot. It's a tough sell. What I would suggest instead is, if the current startup sequence is not "aesthetically pleasing" (for whatever that's worth, being subjective from person to person), that you suggest ways of making it more aesthetically pleasing, rather than the non-suggestion of "MAME's presentation sucks, so let's ensure it continues to suck by foisting responsibility off onto a frontend author". I did very clearly suggest what I believe would make it better - output the "Initializing/Loading machine" messages to stdout instead of displaying them in centered message boxes, and spawn the window right before any warning messages, instead of straight away - even if only in 'console' mode.
|
|
|
|
Joined: Mar 2001
Posts: 17,234 Likes: 259
Very Senior Member
|
Very Senior Member
Joined: Mar 2001
Posts: 17,234 Likes: 259 |
The Initializing/Loading steps can take a significant amount of time in some cases, which is why they're shown on the screen (they didn't used to exist, AFAIK). People used to think their computer had frozen.
|
|
|
|
Joined: Jul 2015
Posts: 115
Senior Member
|
Senior Member
Joined: Jul 2015
Posts: 115 |
Well, you all have your points i can agree with, but Haze and JD you shouldnt forget that there are frontends that manage more than just MAME. You shouldnt "cater to other peoples' frontends", but anything "cool" on other frontends, distract people from main MAME and let them move to where ever they *think* it is cool. So from time to time, something new and fancy and most important, unique for main MAME, will keep people using only main MAME. With unique i mean something, that only MAME benefits of and not a external frontend. Like Calamity merging GroovyMAME into mainline MAME, that unique i mean.
So i dont think that EoceneMiacid ideas are bad. Especially when it comes to message boxes and in particular the nag screen. I could imagine having nice shader effects, while blending the different messages for example. I mean people only want to get rid of them, as they are seeing them as "ugly" boxes. Now, i play most of the time on a CRT and i am very fine with how it is now. Because everything has a meaning there and fits perfect into a CRT setup, like the border outlining the game display area. I instantly can see if a game is cropped and how it is meant to be displayed, also if the font is looking good, i know everything is setup right. Anything too fancy here, could distract from that valueble info or even destroy it, as there are not much pixels left on a CRT screen, but for transitions between the screens, there is still room for any "cool and modern appealing".
I live... I die... I live again.
|
|
|
|
Joined: May 2004
Posts: 1,772 Likes: 34
Very Senior Member
|
Very Senior Member
Joined: May 2004
Posts: 1,772 Likes: 34 |
can we stop calling the current screens 'nag' screens btw.
the only 'nag' screens we have can already be disabled (and that's an information screen anyway) or have been removed (the only true nag screen in the first place was the copyright disclaimer, and that vanished when MESS was merged in)
the others are WARNING screens, that tell you if there is a problem, that's a very, very different kettle of fish. Those are important and aren't there to nag you but to avoid you thinking an emulation might be perfect when it could has issues. Letting people skip those or hiding them is just plain irresponsible on our part.
The only thing I'd say *really* needed changing for those is cases where there is a bad dump / no dump don't need a warning screen because it should be covered in the flags. Only a CRC mismatch should trigger should a screen in terms of bad roms. It's kinda silly that anything with NO_DUMP pals or BAD_DUMPs of unused roms will trigger the screen right now as in no case does that tell you anything the flags don't already cover.
the only nagging going on is from the people wanting the warnings disabled completely, and we've already done plenty enough to appease them with the removal of the disclaimer and making the info screen optional.
people here seem to be making the classic mistake of confusing MAME for a toy.
|
|
|
|
Joined: Jul 2015
Posts: 115
Senior Member
|
Senior Member
Joined: Jul 2015
Posts: 115 |
No problem, i am fine with "WARNING" screens too. Its just the common term, for any people that see MAME as a toy.
Like i said, i find any screen useful, especially on the CRT. It was often mentioned, that people should stay at mainline MAME and not going away from it and this where my suggestions, how you maybe could keep them, nothing more.
I live... I die... I live again.
|
|
|
|
Joined: Apr 2015
Posts: 387
Senior Member
|
OP
Senior Member
Joined: Apr 2015
Posts: 387 |
there are frontends that manage more than just MAME. Exactly, I have just refactored a whole lot of code that makes my previously MAME-only frontend one that now incorporates PCSX2, Dolphin, DesMuMe, WINE, PPSSPP, DOSBox, and even native games into a single user interface, without compromising specific functionality for each.
Last edited by EoceneMiacid; 09/30/16 04:11 PM.
|
|
|
|
Joined: May 2009
Posts: 2,222 Likes: 387
Very Senior Member
|
Very Senior Member
Joined: May 2009
Posts: 2,222 Likes: 387 |
The fact that other emulators exist is not MAME's problem. The fact that you want a frontend to cover both MAME and these other emulators is not MAME's problem. You're trying to solve problems that do not lie within the scope of MAME itself. Stop.
|
|
|
Forums9
Topics9,328
Posts122,128
Members5,074
|
Most Online1,283 Dec 21st, 2022
|
|
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!
|
|
|
|