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.
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".
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.
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.
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.
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".
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.
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.
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.
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.
Stop? Why?
That was just an anecdote, and isn't even being close to being the topic of this thread.
Please let's not have this devolve in another shouting match.
Eocene was citing that he *had* solved the problem outside of the scope of MAME to his satisfaction.
Right on queue: arbee's sarcastic contribution.
Well, that's the last time I'll defend you then.
Lol, you're right - I misread.
Nono, by all means please continue defending me.
Eocene was citing that he *had* solved the problem outside of the scope of MAME to his satisfaction.
If "fuck it, let an external frontend handle it, if any" is a solution, then let's just remove all the internal UI then. Seems about fair.
No, that's how he solved it for himself. I don't think he'd claim it was a universal thing.
Well could Mame show the MAME logo on startup (with the initializing info underneath)
and when starting a machine could the cabinet image not be shown as it was starting up.
Then the (don't tell us this machine is not working as we bloody well know it's not working , we wrote it (red message) could appear over the top of this)
progress bars could be added and/or info on what mame is loading or checking for just to inform people that it has not crashed.
just things other software does when starting up.
as for external front-ends???
... or you could not do any of those things
and simply output status messages to sdout
... or you could not do any of those things
and simply output status messages to sdout
What you could do, and would have a chance to be accepted, is to create a communicate-with-frontend protocol through stdin/out activated with a command line option. Then you'd change the code to encode the rom check/loading/etc information so that the frontend can easily parse and display it in whichever way it wants.
If you're funky you can even try to pass the window handle from the frontend to mame through that protocol (os-dependent obviously, would work under linux, dunno windows or osx) to avoid window transitions.
But you'll have to do it cleanly if you want to have a chance to have it accepted, obviously.
OG.
What you could do, and would have a chance to be accepted, is to create a communicate-with-frontend protocol through stdin/out activated with a command line option. Then you'd change the code to encode the rom check/loading/etc information so that the frontend can easily parse and display it in whichever way it wants.
If you're funky you can even try to pass the window handle from the frontend to mame through that protocol (os-dependent obviously, would work under linux, dunno windows or osx) to avoid window transitions.
But you'll have to do it cleanly if you want to have a chance to have it accepted, obviously.
Such a protocol is already in place - the lua console.
Why not use that? It is not enabled by default, non-power users don't use it (and probably aren't even aware of it, or what to do with it). It's pretty much a perfect fit, and it would avoid complicating the code base.
"Lua" is not a protocol
Edit: To elaborate a bit on this, before your inevitable backlash strikes:
A protocol needs a few things to be called a protocol. At least the following things are required:
- a formal definition. This can be prose, code, pseudocode, flowcharts, etc.
- special attention to interoperability between different implementations (i.e. windows vs linux, 32 vs 64 bit, big endinan vs. little endian, etc.)
- At least two working "proof-of-concept" implementations that show that (and how) the protocol works.
True, you can do all these using the Lua interpreter in MAME (just as well you can use C/C++ to implement it), but simply stating "just use Lua!" is nothing even remotely similar to a "protocol".
I think when OG asked you to propose a protocol he wanted you to come up at least with the above mentioned points.
Semantically, no.
But for all practical intents and purposes, yes - you could treat it like a protocol, in this case.
It sends and receives input, using an established standard.
Right?
Such a protocol is already in place - the lua console.
Why not use that? It is not enabled by default, non-power users don't use it (and probably aren't even aware of it, or what to do with it). It's pretty much a perfect fit, and it would avoid complicating the code base.
Why not. I don't remember lua being able to access stdin and I think it's initialized relatively late, but I'm sure you can fix that. It would have the advantage of every frontend being able to implement whichever functionality it wants. We'll await your PRs.
OG.
Such a protocol is already in place - the lua console.
Why not use that? It is not enabled by default, non-power users don't use it (and probably aren't even aware of it, or what to do with it). It's pretty much a perfect fit, and it would avoid complicating the code base.
Why not. I don't remember lua being able to access stdin and I think it's initialized relatively late, but I'm sure you can fix that. It would have the advantage of every frontend being able to implement whichever functionality it wants. We'll await your PRs.
OG.
lua can access stdin, you can send commands to it.
Ok, will do.
BGFX actually relies on SDL or DXGI passing it a window handle. In fact, I think I said much the same thing the last time someone came up with something like this.
BGFX actually relies on SDL or DXGI passing it a window handle. In fact, I think I said much the same thing the last time someone came up with something like this.
I was wondering, can you pass window handles between applications on windows or on osx? I know it's possible on linux (but you need to have opened the window in GL mode for bgfx/opengl iirc).
OG.
It works in Windows too. Many applications use it to "embed" other applications' window into their own UI. A non-gaming-related example is PuTTY and its various front-ends (SuperPuTTY and whatnot) but it (reportedly) also works for GL-enabled windows which is often used by "overlay"-type software (I think there's even a flag that can be passed to SDL which makes it attach to that window instead of creating its own. It's been a few years since I last used such features though)
Window embedding and all that stuff is another discussion entirely though, and not what I'm going for, personally.
I used to experiment with embedding MAME in the frontend back with Qt4 (Qt5 doesn't have that functionality anymore), but iirc it didn't work all that well, and impacted performance negatively.
Besides, on Linux, it isn't really necessary anyway - there are plenty of different window managers available, and many of them offer advanced configuration on a per-window basis, so you have total control over MAME's or any other window.
And then there's Wayland, which isn't widely adopted yet, but shows a ton of promise and is much nicer than the archaic X11 to develop for.
Of course this doesn't do Windows or Mac users any good.