The Gulf of Bothnia

As has widely been reported commit 5df1b60963060ea61de7bed8d2e8f68f284bf1d9 marks the beginning of a new age of MAME.

The UME project, which began life as ‘Ultimate MAME’ in 2011 has dissolved into what from this point on will simply be known as MAME.

The option to build an ‘arcade only’ version of MAME remains as a subtarget, and likewise you can still build MESS if you have no desire for the arcade drivers, however the default ‘out the box’ configuration is now one that encompasses ALL the work that is being put into the project. I expect the other build options will evolve over time to become more hardware focused for example, allowing you to build a solution containing all drivers using a given device (which would obviously be beneficial to development) The way we generate the build solutions now using Genie gives us the possibility to explore more options in the future.

At the same time you’re also seeing a drive to clear up the licensing a little more. This, like the above, is just a step in the project maturing. As an arcade-only emulator it was easy to write MAME off as nothing but a toy; while it did have a number of other uses the majority of what it did (and what people ended up using it for) was run games. By bringing in the more serious side of the project we end up with a more professional piece of software with numerous irrefutable uses that extend well beyond any simple misconception of the project being nothing but a toy. With that more professional front to the project the need for a standard license also becomes greater, and I also feel more comfortable in re-licensing my code to be more permissive knowing that it is part of something that has many more legal uses. Obviously a number of the issues with older code that were raised before remain, but we’re in a better place right now than back then.

The main topic for discussion when it comes to MAME doing more than just arcade games is ‘what does MAME stand for’. While people like to put forward suggestions for new names still fitting the acronym I think the most important thing is not to focus on what the letters stand for, but to simply focus on what MAME as a brand stands for. For the longest time now ‘MAME’ has represented a bridge between the past and the present, a project providing a platform to keep creations of the past accessible, providing documentation (an insight into how things worked), reusable components, and importantly a place for those interested in emulation to do their work. Just like nobody really thinks of ‘SEGA’ as ‘SErvice GAmes’ the traditional meaning of the MAME acronym is less important than actual work we do.

If you still want something to mentally associate with the ‘new MAME’ then the suggestions of “MAME And MESS, Emulators” and “Multiple Archaic Machine Emulator” do strike a chord with me, but I doubt the official acronym will be changing, it simply represents where we came from.

People have asked what my opinion on all of this is, probably expecting me to have a lot to say about it now that it’s finally happened, however, I don’t. I don’t mind that the UME brand is gone, it was a fun thing, and yes, I did like the name (EMU backwards, the combination of two things ‘U and ME’, the way it was creatively used in the word ‘ConsUME‘ etc.) but in the end the project was only ever a means to an end, a way of showing that the projects could work as one, and a way of ensuring no further conflicts between the projects crept in after they’d ended up really quite far apart at one point. The brand has served it’s purpose.

I think, as the project grew up, this kind of change was inevitable; just as arcades saw a steep decline interest in the baseline MAME project saw a steep decline; hardware we were emulating was being better tested by non-arcade systems, and a lot of developers were already starting to write more code for the emulation of non-arcade systems than arcade ones. The flexibility and design patterns required for the non-arcade systems were already starting to define the project too, leading to better more reusable code. The source repository used for both projects already existed under the ‘MAME’ name only, the source distributions were already shared, and releases were already being made from the exact same code revisions. Mametesters has also already been taking bugs for the non-arcade side for a while, and a number of other sites were providing support for both due to improved awareness that they really are both built from the same sources. In that sense what we see isn’t such a big step at all, just another small step.

Obviously some work needs to be done on unifying terminology, there are many places in MAME which refer to things as ‘games’ (or in MESS as ‘systems’) where in reality a unified term (something like ‘machines’) would apply better to both the arcade ‘machines’ and home ‘machiness’, but again that would simply be refinement, and another sign of the project becoming more serious, and more mature. Concerns with UME such as not being able to identify the type of system from the XML are more likely to be addressed now that everything is included in the primary target.

For an end user (not interested in developing) all it really means is that you get the option to do more with the binary you download; you have the opportunity to see how the code used for emulating Sega C2 / Megatech / Megaplay games fares when asked to run larger parts of the Megadrive / Genesis library, you have the tools at your fingertips to explore the different home ports of various arcade games and compare them. If the new additions don’t interest you then you can simply ignore them, just like you ignore so many of the terrible games supported by MAME right now.

From a developer point of view not much changes immediately; new developers get more in their build by default, and on a sufficiently high end system (as I’ve recently found out) build times and link times are still good. For developers on weaker hardware the old targets can still be built, and hopefully in the future things will become even easier with more focused targets for specific cases becoming much easier to generate than ever before. The project benefits because developers are more immediately aware that their changes must work with all sides of the project, as by including everything by default we’re showing we value it all equally.

There are always going to be people calling the project ‘Bloatware’ or throwing ‘Jack of all trades, master of none’ statements around about the project, but in the end the people calling it Bloatware are never really going to be satisfied as long as it emulates things they don’t personally care about, and the only way we’re going to master the emulation of many systems is by increasing exposure, getting people on board, and working hard on doing what we’ve always done; every little step counts. One thing I’ve noticed with MAME is that it stands the test of time a lot better than many of the smaller emulators even if there is room for improvement (the number of older but popular emulators that fail on simple things like coping with a wide-screen display without distorting the image is disturbing for example, I’ve found myself using MAME/UME very often simply due to little things like that, there are many advantages to it being an active and open project with a wide variety of users and tasks that need to be done meaning we’re never far from a release)

Moving on to more random thoughts, I guess UI builds will adopt the existing MESSUI code (as it provides a way to use a number of features that MAMEUI doesn’t) meaning those who have been asking me to do ‘UMEUI’ for a long time might finally get something along those lines, although I’d definitely still recommend a real frontend over either.

Overall it makes me happy to see that the public response has generally been positive, with some uncertainty over how things will work, but I’m sure once there has been a release or two with this as the default configuration people will find it a lot clearer.