UME is the complete/combined version of the MAME / MESS project.
I feel the project has reached a relative level of stability compared to at other points over the last month so I’ve decided to put out an ‘ex4’ build of UME. There are still some outstanding issues that will likely need to be fixed before a real 0.153 build can be released (for example the breakage of all the Scorpion 4 fruit machine drivers) but overall we’re starting to look in better shape here than we have for a while.
0.152ex4 is based on SVN revision 28774
The changelog (simply a copy/paste of the SVN log) can be read here. This isn’t formatted as a whatsnew, but as usual I’ll summarize the main points below.
UME 0.152ex4 Windows binaries – 32-bit, 64-bit and all tools
UME 0.152ex4 sources
I’ve also decided to compile MAME / MESS builds for this in addition to the regular combined binary.
0.152ex4 (split binaries)
Points of Interest
I’ll write something if / when I find the time.
The build does contain the latest progress on Mega Phoenix and while emulation is still imperfect (some flickery graphics and bad sound) it does now seem to be playable
Most of the progress over the last few weeks has been internal however, as mentioned in the previous update here.
I think you should have not wasted time making and releasing this revision. You admit yourself that MAME is currently very broken in places, so why bother until after 0.153?
It seems a complete waste of your time.
As I mentioned, it seems relatively stable compared to other points as of late, some of the really annoying things (like the brightness controls / sliders simply crashing MAME) wre fixed.
For all I know another big change could hit again before 0.153 destabilizing everything further so it seemed sensible to put out a release at this point for people who want to be able to try the recent additions in a build that isn’t TOO unstable compared to some.
As of r28774 MAME is actually quite stable now, and many longstanding bugs have been fixed since 0.152 (pausing during inp record/playback, neogeo savestates, screenshot errors in 64-bit builds, etc.)
If no one will compille MAME and share free to all of us? You wanna pay mame?
do you know you can easily compile current code by yourself, by just taking the source from the public svn and the compile tools from mamedev.org?
Yes, big thanks to Haze for fixing the Gamma and other sliders. You understand needs of us Mame players well =)
Gamma 0.7 helps play Capcom CPS with good graphics and no gray squares.
Yes i know, and make it long time ago before, but it take so long, so i preffer to wait for a release. And the tutorial is here: http://www.mameworld.info/easyemu/mameguide/mameguide.html
The only thing i can´t do is choosing one source code from each board and make my own emulator. Like create a emulator with only neogeo games and igs in one single pack.
Yes.
http://www.mameworld.info/easyemu/mameguide/mameguide.html
OK, this is getting stupidly confusing now…
It was bad enough when MAME had ‘u’ updates, but now almost every day MAMEworld forums are full of more confusing updated things or frontends that nobody has ever heard of.
Today’s new thing is called “MEWui 1.53rc2” …. whatever the hell that is.
It mentions something about UME but i am sooo fed up of reading about these “revolutionary epic new things” every day, i really couldn’t be bothered to trawl through another readme file.
No wonder MAME is not attracting new blood on the DEV teams, if they are probably confused and bombarded with 1000 new useless splinters and fork releases of official builds & frontends every day…. MAMEworld forum is like one big “my frontend / MAME fork is better than yours” cock wavers paradise these days.
It shouldn’t take long at all if you have a modernish computer. Used to take me 3 hours or so with a single-core CPU. I don’t miss those days. :)
You don’t have to use a “pretty” UI if you don’t want to. IV/Play isn’t bad if you want a simpler one. QMC2 is probably the one I’d use if I wanted a fancy one, though. I just use plain old MAME.
I didn´t say yes haze :@
@Yampy Blike, in my opinion, 1000 new useless splinters and fork releases of official builds & frontends every day means there’s still interest in MAME, and I’m glad for it. It shouldn’t hinder new MAME progress in any way, quite the opposite! And if we’re lucky, we may get a nice replacement for MAMEUI that doesn’t crash. Maybe…
@Lewis King, there is a very nice compiler frontend for MAME that lets you specify profiles for NeoGeo only etc., and that is Raph’s unfortunately named MAME Compiler Automated Scripts (MCAS). The English language version of his site is at http://www.systempixel.fr/mame-compiler-automated-scripts/en/. And yes, he’s working on his own frontend too. When will the madness stop? LOL
MEWui is an attempt to replace MAME’s slimline internal menu / selection system with something closer to a more fully features frontend.
The version numbering is admittedly stupid, because it’s a full MAME build where he’s decided to slap version numbers on it that are completely unrelated to the MAME version it’s based on. He’d be much better of calling it ‘MAME 0.152 svn rev xxxxx with integrated MewUI x.xx’ long-winded yes, but a lot clearer, and it would allow him to maintain his own numbering system in addition to making it clear what MAME build he had to offer.
It’s not a bad idea, but I think ultimately it will die anyway because Mamedev have rejected the idea of integrating it into baseline (I believe due to the complex and bloated dependency chain of extra libraries it has amongst other reasons, like ClientServer MAME) Unfortunately this is kinda what happens to any forks that don’t get officially integrated, eventually it becomes too difficult to keep up with all refactoring that occurs in the baseline project and the authors stop maintaining them.
****
Overall yes there has been a distinct lack of actual ‘revolutionary’ ‘new’ progress lately in the arcade side, lots of retuning of existing things, but no real breakthroughs. Robbie has been working hard on various video gambling things because that’s his area of expertise, but I know a lot of people couldn’t care less about those so won’t consider them to be significant progress although to the people who care about them we are the #1 choice right now, that is good.
The lack of breakthroughs doesn’t really surprise me, I haven’t had time for anything, Kale hasn’t had time for anything, Phil B hasn’t had time for anything, the people I typically work with haven’t had time for anything… furthermore, as I already stated, a lot of refactoring is happening to the underlying code at the moment so it’s not the best time to be working on anything.
I’ve said before we need to put forward one unified front (a UME style MAME) and have a steady ‘full version’ release flow (and *try* to at least fix everything up from each refactor before starting on a new one) but this is not the prevailing opinion in the team, so you get what you get. I put out the ‘ex’ builds at times I feel the code is in a reasonable enough state to do so, which is a step up from the ‘compiled from random SVN revision’ builds you see elsewhere which are mostly compiled / offered by people who have no understanding at all of the changes going on and the relative stability of any given revision. That is my reason for putting them out.
I had hoped by getting rid of the ‘u’ builds we’d establish a better flow of full releases, but like most things that needs full team co-operation, and people working together, to get us to stable states, that isn’t happening.
Actually that’s still the biggest problem that plagues the project, the unwillingness of people to work for a single cause. I’m sure MAME could have become the dominant fruit machine emulator if people with knowledge of the various devices etc. had stepped up to the plate to improve them over the past 2 years, but nobody did – people said they were too UK specific so not their field even if they had a good understand of the devices, as a result the window for that opportunity was lost, just like the window for reinventing ourselves as an all purpose emulator and attracting new developers that way is slowly being lost too because people won’t agree on a unified front.
It will be interesting to see what this year brings. The number of people still compiling MAME builds, frontends etc. shows that there is still interest, but ideally we should have already pushed the MESS code to the forefront of the project so that people building these frontends know they have to support the features required by the consoles etc. in order to claim they have a ‘MAME compatible’ frontend. We should be riding on the recent activity on that front, instead we’re continuing to hide most of what we do and thus people aren’t being exposed to it. (Luckily MEWui does support some MESS/UME features, but like I said, I think it’s destined to die due to lack of official integration)
I think as we see less and less actual progress in the arcade side of MAME the high number of people compiling builds will simply drop off (because the new arcade only MAME builds will offer nothing ‘new’ over previous ones) and we’ll have missed the window to do something new once and for all. Maybe that will make you happy (less random builds / new frontend experiments) but I don’t feel it would be a positive indication of the projecthe health. If nothing else, what you’re seeing right now show that right now people do have an interest in making up for the shortfall in our official release schedule, much as projects like MamePlus and UME (and to a lesser, more dangerous extent the projects that glue emulators together like retroarch) make up for what I consider a shortfall in our willingness to be more open about what we support and the frontends / interface replacements you talk about (MEWui, MameUI + more) make up for what people consider a shortfall in our user interface layers.
I could be wrong of course, but that’s my take on the current situation.
May be there is something interresting on the arcade side of Mame.
This is the h8 rewrite. I remerber you said that Puzlet in the metro.c driver suffers from some bugs in the h8 cpu core. This rewrite can help the emulation of Puzlet may be. I didn’t have time to check if there is improvments or not in Puzlet.
Best regards
It might help with Puzzlet, it remains to be seen, right now it appears to have regressed to a completely non-booting state.
What’s wrong with RetroArch? Why is it “dangerous” to “glue” emulators together?
my belief is that if you do something correct you should only need one implementation, the correct one and that code should be shared by everything using it. Improving that implementation should have mutual benefits to the emulation of everything using said components and any incorrect improvements should be obvious because you have more systems using that code for regressions to show.
coding things this way is harder, that is a fact but it helps avoid, or make more obvious where something is a game / system specific hack.
when you simply ‘glue’ completely emulators together you end up with many completely different implementations of the same thing, each with their own system specific hacks etc. running on completely different underlying cores, using completely different designs.
by presenting that to the user with a common interface those details are hidden, you *appear* to have something better than the actual code is.
for projects like MESS, where we take the tougher approach, to succeed, and for people to actually want REAL improvements to the emulation of our components then people need to realise and support the tougher approach, but if users are given an easy way out with a bunch of ‘perfect’ emulators glued together and see no benefit to doing things properly then they’ll be less inclined to use MESS, as a result MESS will get less testing and less developers, and people will be discouraged from actually trying to do things ‘the right way’
While it’s clearly good from an end user point of view if all people care about is ‘playing games’ I consider it dangerous from the point of view that it discourages proper development, and you’re simply left with large chunks of code you might not really be able to reuse or mix together if you find another system similar because you don’t actually have reusable & compatible emulation cores driving it all, just the illusion of that through a common OSD.
While this might sound selfish, and a lot of people will be reading this and thinking ‘I *don’t* care, I *do* just want to play games’ I think it’s important to look at the bigger picture, and the only way you’re ever going to have truly *great* emulation of various components is if they’re properly shared by a large number of systems abusing them in different ways.
That’s why I like MESS / UME, because it isn’t a console emulator glued into MAME, it’s all the MAME cores, all the MAME code, all the MAME framework being used to drive console emulation. If they improve, we improve, if we improve, they improve, if we continue down that path we end up with components and an architecture that can deal anything you could dream of throwing at it. If people lose interest in doing things the proper way, we don’t, we just end up with lots of little emulators, multiple implementations of the same thing, no mutual benefits to improvements, no clear indication of which cores you should / can be using if you encounter something new that uses a mix of different hardware.
I’m aware your opinion on the matter differs, so there is little point in arguing it.
Maybe it’s because I see such things as competition to the UME idea, but to me it’s like bringing a motorbike to the 400 meters.
libretro isn’t trying to be MESS. All its cores are basically still standalone emulators, they are just running through RA so that they can have competent A/V output. It’s not trying to be archival accurate, it’s just trying to be as accurate as possible while still be playable. It IS just for end-users that just want to play games, but accuracy is good for them to.
And even if it was trying to be MESS, it doesn’t matter what the code as like. As long as you document WHY the code is that way, then anyone can make a emulator for that system in MESS or wherever that’s as accurate if not more so. Then any finding a standalone or RA emulator has can simply be brought over to MESS to work with other systems that share it’s code, or even manually between emulators that don’t share code like MESS.
RetroArch isn’t anything like MESS or even trying to be. It’s simply a frontend for any program, only usually emulators, to use to achieve competent A/V output and for a shared codebase for A/V across platforms.
For all intents and purposes RA cores are still standalone emulators, and are no more or less dangerous then normal standalone emulators are.
RA is more analogous to an OS or something like Java then it is to a project like MESS.
Thanks for copy-pasting my post on emugen, Chiyoko.
Maybe I’m confusing it with another project then..
All I know is that in real life I’m seeing people come to me and mention emulators but instead of mentioning the actual emulator they’re mentioning packages that hide the actual emulator and instead run library versions of the emulators glued together in one package as if that software WAS the emulator. Actual software versions are hidden / mixed and matched too etc.
If retroarch isn’t one of these (but merely a regular frontend) I apologise but skimming the website it appears similar, requiring custom emulator cores etc.
I also worry that MAME / MESS will end up being locked in a corner if this becomes a standard way people use them, closed non-portable OSD layers and the like driving our code and any new features we add simply being unavailable because they have to fit a model we don’t control.
What we really need is people improving the actual emulation, hiding multiple emulators behind a single interface doesn’t help with that but your average user can’t see, and doesn’t care to see the difference.
Maybe I’m just burnt by how aggressively a certain other person was pushing his ‘libMAME’ project, when clearly there were more disadvantages to that than advantages, I don’t know.. all I know is I’m seeing increasing confusion amongst regular people who are seeing pre-packaged ‘frontend’ like applications as the emulators instead of the actual emulators.
I guess to a degree the various torrent sites are to blame more than anything, as well as some unscrupulous eBay vendors etc. selling such packages already set up to be installed (and the odd time such packages make it through the approval process on mobile platforms) but I’m never going to be a huge fan of things like this when I believe people need educating, and need to understand that writing a perfect emulator is *hard*.
Programs do need to be rewritten to work with RA, but the whole point is to leave core emulation intact and just replace all the input and output with libretro.
Frankly RA does a much, much better job than MAME at A/V, with syncing, dynamic rate control, shader options, and latency reduction. Personally, from an end-user point of view granted, I’d much rather use a libretro MAME port than standalone because of this.
I do agree though that MAME/MESS are much more important then just for being able to play games right now, but there’s no reason MAME standalone and a libMAME couldn’t coexist, and there’s no reason standalone couldn’t implement something that couldn’t currently be done in RA and just not give a shit (and if it was good maybe I’d rather use standalone then) But, libretro and RetroArch are FOSS projects. You could always make changes to facilitate a certain feature if they were reasonable. And even if you only you though they were reasonable, even then it could always just be forked.
Note: I’m note saying you should make libMAME or anything; I don’t really care. I’m just talking theoretically here.
Lastly, there’s no reason the actual emulation work would suffer because of libretro. In fact, the libretro ports are where a lot of major core emulation work has been done for some projects, which was then backported.
Apparently RetroArch already does have bleeding edge SVN MAME, MESS, and UME libretro cores, so they already do coexist. Problem solved…?
IMHO, the only problem with retroarch is that if you want e.g. to add a module to run Apple ||gs programs you have no easy way to reuse the amazing CPU code written by byuu for his SNES emulator (which uses the same CPU).
the only way to do so is to write the Apple ||gs as part of bsnes/higan code, but in that case then you would have no way to borrow any code handling floppy disks in other supported modules, because they are completely separated from bsnes
and so on, re-inventing the wheel whenever you want to add new modules
in MAME/MESS everything is shared and while this makes maintenance delicate, it offers a lot of pro-sides
for instance, the ISA cards emulated for PC systems were available to be re-used in the Apollo machines without any further effort
and the Apple ][ expansion cards were an easy drop in for the Apple /// driver
That’s basically what I was saying eta, and why I think a UME style MAME is a better future than a bunch of otherwise unrelated emulators living under one roof.
Indeed it sometimes causes issues, as we’ve seen with trying to unify the 68681 implementations we have, but in the end it’s only BECAUSE we’re aiming for a single project with single implementations of those chips that we’ve even noticed that one or them is wrong, or one of the drivers is using it in an incorrect way. With the approach a lot of other people are taking that would have never been noticed because each emulator would actually be completely independent aside from the common Audio/Video layers hiding it.
I know you’re not a huge fan of the UME approach, but this is exactly what we are competing with, and exactly why it’s a good idea because somebody has to try and encourage things to be done *properly* and that somebody is us.
People are actively seeking out all-in-one solutions like these, so to me it makes sense if we offer that because it significantly raises the chance of people using our code for things and only looking at other modules when that fails.
We need to move with the times, but like always, attempt to do it properly unlike these solutions. We need to lead the way with a proper all-in-one solution using the MAME brand we’ve established over the years otherwise our efforts will be in vain. This remains my opinion and will continue to do so…
I don’t understand all this talk about libretro port, finally it’s just like the sdl port which use sdl library to handle A/V.
the libretro port just using libretro library to handle A/V.
And as said previously the benefice is to have good support for Audio/Video and Shader . that help to run on older computers .
the only major changes done in the source code are in the osd/retro and in makefile .
No speed hack or change in emu core ,
the rest of code is sync with the mame svn.
There are no interest in retroarch of taking the credit of the mameteam or hide ume/mame/mess behind opaque monolithic application called retroarch.
It’s just about using ‘libretro library’ to handle A/V.
@etabeta
non sense , it’s like say “with sdl you can’t re-use sdlmame in hatari emulator (that also use sdl)” .
libretro is a library , retroarch is a frontend for libretro library .
@rtype: nobody thinks that retroarch people tries to steal credit for the emulation (they are clear about who made who)
we criticize the whole approach of gluing together separate emulators without any kind of integration outside the inputs and shaders handling, because it does not help people who might want to emulate new systems.
if it’s never been their goal, it is not their fault, of course. but at the same time it makes retroarch not particularly appealing to my eyes, that’s all.
@etabeta
Ok i understand your point of view , and i am not in the head of libretro authors so i cant speak for them .
I think we should distinguish retroarch the engine “Reference frontend for the libretro API” and libretro the API , and finally the retroarch release pack.
I only said that in my point of view , libretro is just a library which provide good audio/video sync , multi shader path, opengl and that is multi platform … and mame-libretro is just using libretro like the “sdl osd port” is using SDL library. That why i use it and not because it is a all-in-one solutions. that’s all i’ve to say on it.
To stay on the topic , i don’t think that MAME/MESS have less interest for the users. and i think that UME will be a good default choice for mame/mess release , because i don’t really understand what is the difference that using mess and mame separetly instead of using ume.
right, the problem is more how other people see things.
people tend to take a very simplistic view of things, if everything appears to be in one container then that is the emulator. given that so many people these days are looking for some kind of all-in-one solution it suits them, so it becomes their favourite ’emulator’ even if it is not.
that is not your fault, or our fault, but it is a little depressing.
re: mame / mess / ume, no, there is no difference between running ume and running separate mame/mess binaries, the same argument can be used for and against the idea.
Historically we’ve never split MAME into multiple binaries for 70s, 80s, 90s, 00s, because it doesn’t really make sense to do so, and the situation really is no different. Actually I dare say we’d be in a worse position in terms of userbase if we had split them because a lot of people using the ’80s’ build would probably simply never upgrade, thinking we’d perfected those a long time ago. Instead people upgrade the whole thing because they see interesting more recent additions (90s, 00s) and get the improvements we’ve made to the 80s stuff as a result because we package everything as a single program.
Personally I prefer the UME approach. There is one config file, you know the binary is of a single code revision, it clearly shows that our code is doing everything and can do everything, and sends out a clear message that we’re interested in everything meaning people are more likely to submit things to us and realise we have a project where they’re free to work on anything they desire.
I also prefer it because in the long run it would avoid some of the petty arguments over what belongs where in the code, and instead of illogically splitting certain things because they’re home / arcade they could live together more easily; doing CPS / CPS Changer in a ‘correct’ way right now would involve moving 99% of the driver code into emu/machine which makes no sense at all if you’re looking for the code. If we simply had a /sys folder (instead of /mame and /mess) to match /emu and in it we place all our system emulations (be they arcade or home) then it becomes a lot more logical and the focus turns to the hardware rather than the project; in one folder you’d have emulation of systems & system specific manufacturer customs, in the other you’d have emulation of generic components, for a hardware emulation point of view who cares if what is being emulated runs software that accepts coins or doesn’t?
The UME approach is also easy to favour because it’s convenient, people who use MAME have the opportunity presented to them to try out other systems without having to download any other emulator, this opens doors, it means people who might not have otherwise bothered downloading MESS do end up using our code for things. People want this type of convenience, that’s why people are seeking out the other all-in-one solutions, we should be taking advantage of those desires, not hiding from them.
Unfortunately a small core of the actual MAME developers do not want MAME to grow in this direction, so instead of MAME becoming that you have this UME side-project I host here which lacks the strength it would have if we were actually doing this with MAME.
I can understand some of the dev concerns, building a full UME does increase the link times, but then we’ve always had the option to build smaller builds, and it would be quite easy to put together a modified makefile system whereby you could build a ‘tiny’ build from any given manufacturer, or one with the arcade/home split, so those drawbacks are somewhat imaginary, maintaining the ability to build separate home/arcade binaries wouldn’t even be much work.
So I’m really still not sure why it hasn’t happened yet, we have nothing to lose by going down that route officially as part of ‘MAME’, but in the meantime if people do want the complete / combined version of the project they can get it here.
Libretro/RetroArch is NOT an emulator project. I despise the “all-in-one emulator” label that gets attached to it. I don’t pretend like I don’t know where this comes from since the vast majority of cores are emulators – all the same, it is my intention to offset this with more game ports and more non-game cores so that the emulator connotations can get thrown to the wayside.
There is no real good way right now to pigeonhole libretro/RA. It’s not an all-in-one emulators – it’s not SDL – if I had to come up with a term for it, I’d say it’s an ‘integration API’ in the same sense that Google Maps gives you an API that other apps can hook into to provide them with maps functionality. The difference here is that libretro does this for any application that gets ported to it. I view this as being far more powerful than just being another ‘all-in-one emulator’ or ‘just another SDL’. But that might just be me.
Nearly all of the concerns listed here are wrong about RA/libretro and are founded on fears of ‘losing control over one’s own project’. A simple e-mail or inquiry would have been enough to dispel most of these myths. I have no such intentions and neither does anyone working on this stuff.
Finally, I/we are open to upstreaming the libretro port (only a very, very small number of changes to .mak files would have to be made for it to succeed). I do not intend to ‘usurp’ MAME/MESS/UME/whatever because that is not the goal of this project – it does not intend to replace ‘any’ emulator. It’s simply there to show the virtues of the API and the frontend that has been built around it – and because I and others like emulators and feel they can run better as libretro cores.
I think you’re being a little defensive here.
Most of the posts acknowledge it as not the fault of the project directly, but the way people see things.
Unfortunately in emulation ‘the way people see things’ is always an uphill battle, we’ve faced that in MAME with trying to properly document NeoGeo sets (with people for a long time insisting that anything that doesn’t run in NeoRageX is bad) and we face it in MESS too, with people claiming our Softlists are full of bad dumps, because our dumps don’t run in other emulators (that happens because we use real dumps with real filenames where possible)
While a different problem this ‘issue’ does still simply come down to the way people see things, which you also acknowledge. Trying to get people to understand that these type of things aren’t emulators (when they end up packaged as such) is difficult, and makes convincing people that what we’re doing is the correct way to develop high quality emulation cores even if it’s a much longer road.
So do you want it upstreamed or not? I never got a valid response to that offer.
I don’t see what there even is to argue about here. The libretro port is exactly the same as – say – the SDL port, with the key differentiating factor being that a libretro core can be played by many ‘players’ implementing the libretro API.
There is absolutely nothing that is being ‘taken away’ from MAME/MESS/UME by running/implementing MAME/MESS/UME this way through libretro. I don’t even see what there is to argue about – you’re making up some ‘danger’ that doesn’t even exist.
It’s not up to me if it gets upstreamed or not.
Keep in mind that there might be significant changes to the MAME audio / video output at some point tho, especially if we want to do full 3d scene rendering of machines etc. with complex lighting etc. (for fruit machines and the like plus some 80s games with strobe effects etc.)
but the ‘danger’ remains IMHO, it’s what people see. NeoRageX wasn’t inherently dangerous, but it set back dumping the *proper* romsets by many many years even if I’m sure that was never the intention. There’s nothing you can do to prevent people seeing what you do as some all-in-one emulator, but they will.
We can handle 3D just fine with libretro GL, so that’s not an impediment to the libretro port being upstreamed at all.
ok, just thought I’d best mention it because significant A/V changes in the history of MAME are what killed off other targets like AdvanceMAME, it simply couldn’t handle the prospect of multiple screens each at different resolutions, different refresh rates etc.
> but the ‘danger’ remains IMHO, it’s what people see. NeoRageX wasn’t inherently dangerous, but it set back dumping the *proper* romsets by many many years even if I’m sure that was never the intention. There’s nothing you can do to prevent people seeing what you do as some all-in-one emulator, but they will.
And why does this matter to you so much what they see RetroArch as? Is the concept of an API and an official reference frontend foreign to you?
You’re not even making sense at this point. So if MAME/MESS/UME gets ported to ‘libretro’ – it sets back ROM dumping by many many years? What?
I’m merely using the ROM situation of an example of something that shouldn’t have been inherently bad but had unintended consequences.
The way these ‘lib’ projects are ending up packaged as all-in-one emulators is similar. The idea isn’t a bad one, but it seems to be having unintended consequences.
So basically your preconceived notions of what a “lib”-type project is, is slamming the door shut on an endeavor that actually has very similar goals as yourself in terms of the whole “non-commercial” aspect of it.
I’ve offered already to upstream it if the interest was there – it wouldn’t take many changes – just some minor changes to the .mak files and adding the osd/retro files. If it gets upstreamed, MAMEdev in effect controls its direction.
But hey, if you don’t want it, you can just tell me and we’ll leave it at that. Only reason I came here is because I saw a lot of assumptions being made about RA/libretro that didn’t make sense in my view.
As I’ve said, it’s not up to me to accept / reject upstream, you might find it accepted regardless of split opinions on if it’s a good / bad idea.
What matters more is if it will be maintained, SDL is in mainline because it’s very actively maintained and updated for every change due to being the official way of using / developing MAME on non-windows systems.
You don’t have to worry about maintenance since we will maintain it.
Me, r-type and AndresSM do a lot of work on it on a daily basis. The only drag right now is that we have to continually git pull from redump every day or so to stay in sync.
I’d rather just commit to mame git directly and cut out the middleman.
Here is the repo in case you’re curious –
https://github.com/libretro/libretro-mame
BTW – not sure if you know this or not – but we already have MESS / UME libretro cores.
So again I’m not sure where the MESS vs. RetroArch comparisons come from or what they’re even based on. MESS can be just one core that already runs in RA or any other libretro player for that matter.