UME 0.153

Thank you for this release.

I’m not a fan of the libretro approach, why would I offer binaries of such?

I offer Windows binaries because I’m on Windows and this is my personal site, and frankly I’m also sick of the flood of faces that appear everytime somebody says a bad word about something like libretro. My experiences with it, and more specifically users of it have been entirely negative.

The whole point is these are 100% stock binaries compiled from 100% stock source, no modifications, just TARGET=ume

If other people want to compile libretro versions etc. they can I’m not stopping anybody doing anything but the only method for using our emulator I 100% trust is the one we ship, that’s also why I don’t ship any kind of MAMEUI / MESSUI builds for UME either. I have no desire to deal with bugs that may lie outside the official project code.

>> I offer Windows binaries because I’m on Windows and this is my personal site

> How lame and how narrowminded

would you like to pay me for my time? I’m providing a service here to benefit people, you’ll note the official site only offers Windows binaries too.

> If this is how you behaved towards the rest of MAMEdev during your previous temper tantrum, then I can see their gripes with you really.

I come to my own conclusions based on the evidence available to me.

> Sounds like you have extreme ownership issues based entirely on prejudices and a misunderstanding of actual factual matters regarding any subject you dislike – whether it’s about a license or an API/frontend paradigm.

I have a clear understanding of what it is having done further research, I also have personal experiences with people who don’t and think Retroarch is the actual emulator.

This does not make me like it.

Of course I prefer the frontend code to be under our control, so we can develop it and change it how we please. There has been talk in the past of using the SDL target even for Windows (which would be more portable) but that one apparently is less capable when it comes to some multi-keyboard / multi-mouse / multi-monitor stuff which is key to the project.

> But as several people have told you already, your own ‘frontend drivers’ are just inferior and the whole thing just runs worse vs. RetroArch. We want it running inside RA vs. your ‘official’ frontend which serves no purpose and is not even portable in any way, shape or form.

This is not my problem to deal with, I’m happy with how things run for the most part. If people are not happy with it they can go elsewhere. I would rather people ran it through the official frontend via the commandline or using something like QMC2.

> Face it, you have no actual reason to dislike it or be against it being upstreamed except for an irrational fear of libretro/RA not being under your control.

I have told you, it is not up to me if it gets upstreamed, it IS up to me what I host here, and I do not want to host libretro stuff here if it is not part of the official source distribution. If it *was* part of the official source distributions and the official default OSD layer I would host it even if I didn’t like it, but it isn’t.

Despite my differences with the team over certain issues, my allegiance remains to distribute builds that operate as closely to the official targets hosted on mamedev.org as possible.

If you hadn’t noticed the team do value integrity, and that does sometimes mean keeping tight control over things. While not directly related to this I’ve seen too many projects I like go the disgusting way of adware bundled installers and the like, but instead as a team we like to keep control of things, we always ensure that our offerings are 100% clean and do not depend on any other applications. If we go down that slippery path and start saying you need x,y and z installed to use MAME, recommend ‘y’ for years then ‘y’ starts bundling adware we’d have done a huge disservice to our users because many will keep downloading out of habit, or because there is no alternative much as is the situation with Java apps today.

While we’re here, RetroArch frontend has some really nice features that I think should be standard for all emulators.

Dynamic rate control. It’d be pretty awesome if MAME/MESS/UME added it.

https://github.com/libretro/libretro.github.com/raw/master/documents/ratecontrol.pdf

and what happens if somebody builds a far fancier version which does happen to be ad supported, and ends up being the most popular one, or you change your mind? Suddenly we have to go into reverse and use our own code anyway to avoid it, hope people no longer download the rogue software, and even then we’re left with a bunch of old versions people can’t use without risking installing something else.

The problem is, as you’ve seen on Mobile platforms doing this is actually quite a popular option and this is the exact kind of BS I’ve had to deal with “I have this amazing emulator X but…” and when they show it me it’s an ad-laden piece of crap thing driving libretro cores because the situation makes it all the easier for people to do that.

MAME is still far better for being a standalone application, we bypass that problem completely, it just works(tm)

So no, I’m never going to be a fan of handing control over to 3rd party applications.

> MAME is still far better for being a standalone application, we bypass that problem completely, it just works(tm)

Yes, have fun with your ‘it just works ™’ official single binary for Win32. LOL

> So no, I’m never going to be a fan of handing control over to 3rd party applications

You don’t have to hand over jack shit. It’s simply an alternative OSD. Like I’ve been telling you for several times now but you seem to have some comprehension problem on that front.

> You don’t have to hand over jack shit. It’s simply an alternative OSD. Like I’ve been telling you for several times now but you seem to have some comprehension problem on that front.

and not one I want to host or support here. I’m not sure what part of me roughly mirroring the format of the official distributions is so hard to comprehend either.

like I said, if it becomes the primary official OSD it’s what will get hosted here, if not, it won’t. It is currently of no interest to me.

> The future is emulators as a pluggable core – the future is convergence of emulators with separate frontends – whether it’s a media player like XBMC or a general-purpose frontend like RetroArch.

and I strongly disagree. The future is an emulator with emulation cores that can handle whatever gets thrown at it, multiple emulators with the same frontend / OSD layer is not progress and is not the future, at least not any good future.

That’s what I dislike the most, it’s completely anti-progress.

Yes you’ll end up most popular because you can take the ‘best of all worlds’ and give the illusion of having a ‘better emulator’ by giving multiple emulators a common frontend and OSD layer and people will lap that up, while instead we’ll be trying to do the real work of making one emulator that actually emulates every component to a high enough degree of accuracy to run anything.

Which is exactly why I said I think it’s damaging in the first place.

I can only speak for myself however, you probably have the rest of the dev team on your side because they don’t like the UME idea much in the first place and would probably rather see MAME glued to BSNES and Gens under a common front end and OSD than ever adopting a UME style MAME as the actual official approach.

Thanks for a new compile, Haze.

I hate to add to the flame bait, but I for one hate freaking glue type front ends. UME is very convenient for me. I just make a .BAT file for every game that I want to play and then make shortcuts for those batch files which are placed in a section of my start menu. With these batch files, I can custom configure every game to my liking, even if it wouldn’t have it’s own CFG. Further more, I can do the same thing with all of my other emulated games and toss them all together in one well sorted system.

Front ends like QME and MAMEPGUI fail to provide enough functionality and are just plain obnoxious in comparison. You know what’s a good GUI? My freaking operating system.

> People see retroarch / libretro based solutions as ‘all in one emulators’ It does not matter if that is not your intention.

Let me try this little rhetorical game of yours for a minute and apply it to your pet project:

People see MAME as an emulator that lets you play illegally downloaded rips of arcade games. It does not matter if that is your intention. That is what it is.

Therefore it’s bad.

Am I playing this right? Irony is a bitch huh?

> Putting multiple emulators under a single frontend / OSD does not make for better emulators. You seem to think this is actually the future of emulation, I couldn’t disagree any more strongly. Even within MAME we work to reverse this trend where emulation of different systems have ended up with duplicate implementations of the same chips.

MAME will never be an ideal vehicle for the platforms that matter the most in the future – mobile.

Your idea of a homogenous ‘perfect’ emulator that covers every system and that scales across every platform perfectly is a total pipedream, and not based on reality. I live in the real, and the project I head is based around that.

> These often also more often than not make it easier for people pushing adware on mobile platforms to do such. I do not really like this, I prefer us to maintain a level of integrity and not hand control over.

You were banned years ago from #mess. You are not controlling anything, and there is no ‘us’.

At this point you have no degree of control over this project worth a damn.

Therefore I’m going to stop this silly war of words for you since there’s really nothing I have to gain from prolonging this discussion with somebody who is not even in charge of anything at this point.

> I simply want to encourage PROPER emulation development

Good luck with that when you admit yourself the project is in a death spiral. Thanks to people like you, I would like to add.

Get with the times and stop making yourself and the project you contribute to part-time irrelevant in the process. This is evolution. Evolve or die. Your call, but I know which way the wind is blowing.

so you’re now resorting to Ad hominem attacks too..

I agree the project needs to evolve, but I would consider the direction you push for to be devolution, not evolution.

Strangely I think even the majority of the dev team would agree with that, you’ve only got to look at the number of things being moved to shared devices, reusable components etc. to see that. We’re not creating 10 different device cores to emulate the same device in different drivers based around specific needs of those drivers, we’re creating 1 that works, and is therefore more trustworthy if you need it somewhere else.

Yes, MAME could do with more people doing things properly, call it a death spiral if you want, doing things properly is hard tho, the cheap-out solution is much easier. As for blaming me, I still maintain the arcade side of things would be even more irrelevant now if not for a lot of the actual driver / reverse engineering work I’ve done over recent years, work that has been greatly AIDED by the approach MAME has taken when it comes to shared components etc. Things would be a lot less trustworthy if every component needed implementing from scratch for every driver.

Mobile is, and will always be an awful platform for emulation because when doing proper emulation is always going to require beefy systems, moulding the future of emulation around mobile just because it’s *popular* would be stupid.

Getting MAME to scale well is a challenge no doubt, but the cop-out of not bothering and simply using other emulators is no better.

Even if we take advantage of some of the supposedly better features available running as libretro OSD we’d still need to maintain the others, as for reasons I’ve already specified I feel becoming dependant on an external application would be unwise.

And if you’re seriously suggesting the future of emulation is something similar to the XBMC based clusterfucks like CoinOps then I can only laugh… aside from the gamers a lot of people aren’t exactly happy with that and the politics surrounding it.

I find it hilarious that some clown who glues other people’s work together has the nerve to say that MAME/MESS/UME are “facing obsolescence.”

Clue to dumb RetroArch asshole: you’re completely dependent on these “obsolete” emulators. You offer nothing of value yourself. If developers like Haze weren’t doing the hard work involved in actually, you know, EMULATING HARDWARE, you wouldn’t have shit to cobble together and run from your shitty (yes, it’s shitty) frontend.

The more experience I get with video game emulation, the more I realize that MAME/MESS/UME are pretty much the only options for the long haul. The standalone emulators are all primarily driven by one person, and attrition and entropy always take their toll, and they always dry up, and MAME/MESS/UME end up working better than they ever did, and another standalone emulator becomes useless/forgotten. You just can’t compete with the community of developers that MAME has.

Let me tell you a little story about a Saturn emulator. A guy in Japan made it. It ran a lot of games pretty well. You can download it here:

http://www7a.biglobe.ne.jp/~phantasy/ssf/

Oops. It’s fucking gone. It was close sourced, the author dropped off the map, it’ll probably never be updated or improved again, and tons of games it couldn’t run will never be playable. Meanwhile, MESS’s Saturn driver will keep inching forward until it’s eventually better than SSF ever was, and nobody will remember that SSF ever existed.

And coincidentally, I wouldn’t touch RetroArch’s interface with a 10 foot pole. I LOVE that MAME/MESS/UME are simple command line programs and that we can make our own frontends to launch games the way we choose.

> And if you’re seriously suggesting the future of emulation is some similar to the XBMC based clusterfucks like CoinOps then I can only laugh…

That is what people are already using OpenElec-based media players for.

Seriously, I know nostalgia is all the rage with projects like this, but really, this isn’t 1999 anymore – it’s 2014 – why don’t you try living in it?

Thing is, as I have noticed in every MAME/RetroArch discussion, it would seem you haven’t even tried RetroArch.

The OSD works just as it does in standalone. Softlists work and even CLI support is being added. The big advantage is instant portability to pretty much any relevant platform available and a consistent experience across the board.

RetroArch’s drivers are thin and the devs try hard to have them as optimized as possible, try RetroArch MAME under KMS and you will see a real difference in latency for instance.

Anyway, that’s just my 2 cents

> SDL already fills the role of the secondary OSD for non-Windows platforms right now which is important because a non-trivial number of developers use those platforms. It is actively maintained by a member of the dev team who does work in MESS, so if it breaks at any point it gets fixed within a day because it is in constant active use.

The SDL OSD implementation is not going to be running in XBMC anytime soon by itself, or any other external app implementing the libretro API.

The libretro OSD will. There is simply no possible way you can win this argument. You lack the vision and the understanding to see why it is important. But I do see why it is important.

Thankfully then, you don’t have much sway over this project anymore these days.

And if you guys don’t go for it, that is fine too. Right now we have a shallow fork going so we don’t need you guys anyway for any particular purpose – it will still get out the same way it does now.

This is just about me (graciously I might add) offering to upstream it so that we can get over any future conflict over a ‘fork’ of MAME and how this supposedly is so detrimental to certain people wanting to play control freak over everything under the sun.

> I don’t see where it fits in. Nobody can use any extra features offered by it without having to go and implement a way of doing the same thing with the other OSD layers, so nobody will because nobody is ever going to want to make MAME depend on something not available when using the primary OSD layers.

The idea here would be to obtain push access so that we can maintain it ourselves.

> Seriously, I know nostalgia is all the rage with projects like this, but really, this isn’t 1999 anymore – it’s 2014 – why don’t you try living in it?

The approach you’re pushing for is about as 1999 as you can get, people developing lots of small but otherwise unconnected emulators with the twist they get shared under a single frontend with a shared emulator interface / API.

We’ve moved on, and evolved a long way since then, that is exactly what MAME is, the evolution of that idea, the proper way, an emulator that shares actual emulation cores and therefore can present things under a single frontend / interface simply because they’re all part of the same application and use common emulation code.

I don’t know why you feel like you’re talking to somebody stuck in 1999, because I’m feeling exactly the same way about your ideas.

> The approach you’re pushing for is about as 1999 as you can get,

yes, because a 160+ MB binary is surely solid software engineering in the year 2014.

“Yo dawg I herd u like ur instruction cache misses, so I made a 160+MB binary so u can trip over cache misses while u trip over cache misses!”

Cue Xzibit pic and all that shitz….

Which is why MAME’s performance has totally not gone downhill on anything but ‘insert Core i CPU that MAMEdev actually tests’.

Seriously, if you think there hasn’t been huge knockon effects on MAME’s performance on memory-strapped systems over the years, you clearly don’t know anything.

I do because we actually have the liberty to test all these versions out on all these different platforms thanks to libretro. Therefore I can put my mouth where my money is when I make claims.

Which is more than can be said for certain totally unsubstantiated stuff I saw being said on MAMEWorldInfo…

The only reason newer versions of MAME are slower is because the emulation’s more accurate and hacks have been removed, you clueless douchebag.

You have NO idea what you’re talking about.

> The only reason newer versions of MAME are slower is because the emulation’s more accurate and hacks have been removed, you clueless douchebag.

That doesn’t explain it either. There are drivers that have seen no discernable differences between version 0.139 and (say) version 0.150 – and even still a 6% degradation in performance is almost uniformly constant.

So much for that then.

> “Yo dawg I herd u like ur instruction cache misses, so I made a 160+MB binary so u can trip over cache misses while u trip over cache misses!”

Protip: the OS (and by this I mean all of them: Linux, OS X, NT-kernel Windows, *BSD, QNX…) only loads pages from the executable that are in active use. So for something like Pac-Man, the subset of MAME that’s running probably *does* fit in cache.

But then, if you actually believed that 160 meg thing you would never have made a fork of it to put in retroarch.

ProTip: There are consoles that don’t even HAVE 160+MB of RAM.

So what are we to resort to for that? Virtual memory?

Again, this is assuming that you actualy want to go the Haze route and make MAME this ‘universal emulator’ that will start competing with this ‘supposed all-in-one emulator’ called RetroArch (according to him). Well, you already fail the mustard test then if your precious ‘universal emulator’ is too big to even fit into RAM.

Whichever way you look at it, it is simply non-scaleable the way it is now. Either admit that it is only meant for overpowered Intel PCs and leave it at that – but that has its drawbacks and disadvantages.

Hahaha consoles?

You’re talking about the FUTURE and you think consoles are relevant at all?

Yeah, let’s gimp MAME so that we can run NFL Blitz at 10fps on a Nintendo Wii.

GEEZUS. Talk about living in the past.

Hi. It’s 2014. 16GB of ram costs nothing.

WELCOME TO THE FUTURE™

We don’t especially CARE about MAME on those platforms.

We CARE about making the best emulator, and by that I mean the best actual emulation of the hardware components even if it has high requirements. We care about creating component emulations that can be reused for many purposes.

That’s the proper way to do things.

If you Raspberry Pi or PS3 can’t run things boo fucking hoo.

I’m sure we could add back 20 speed hacks to make MK3 run at a better speed on the PS3, patching out all the idle loops, HLEing half the sound system etc. but that is not needed by our primary targets, so these things were removed, it keeps the code clean.

We emulate entire high frequency MCUs used for protection even if all they do is add 2 values up at startup and return a fixed result if we have the actual MCU code, this is MAME, that’s what we do.

You tell me it’s not 1999, but you seem to be the one obsessed with how things run on technology that is years out of date, severely underpowered, or just not really designed for emulation and expect us to not do proper emulation of things just for the sake of those platforms.

> We don’t especially CARE about MAME on those platforms.

> If you Raspberry Pi or PS3 can’t run things boo fucking hoo.

Admit you don’t know much about modern CPUs and IPC performance please. You said that the principal problem of a Raspberry Pi was ‘not enough Gigahertzzzzzz’. I already have given you an example of where that falls flat on its face.

And all the development in CPU development right now is centred around thermal control and making sure things are as small and compact as possible. We are no longer seeing drastic single-core performance increases, and certainly not on the astronomical rate where suddenly – after five years – N64 in MESS finally starts becoming playable. It is simply not happening.

> You tell me it’s not 1999, but you seem to be the one obsessed with how things run on technology that is years out of date, severely underpowered, or just not really designed for emulation and expect us to not do proper emulation of things just for the sake of those platforms.

It was you that said you wanted a “proper multi-system emulator” that did it “properly”.

And I’m telling you that if what you mean by that is something you call ‘UME’, it is only going to run acceptably on Core i3/i5-based PCs. And it’s going to be a total crapshoot on any console/tablet/phone.

So if you don’t care about marginalizing yourself and your project, please go ahead and make up a rivalry between MESS/UME and RetroArch that doesn’t even exist.

Again, your entire argument for ‘we need to make MESS/UME into a competitor for RA and things of its ilk’ can be put to crap with just one sentence –

‘MESS/UME already runs as a libretro core inside RA’.

End of argument. There is nothing to ‘win’ by trying to ‘keep up with the Joneses’ and turning MAME into some ‘all-in-one multi-system emu’.

So please don’t change the subject again. It was you that insisted everybody should hop onto the UME bandwagon and turn MAME/MESS into that. Don’t be upset when I show the futility of such a thing.

Actually, the PS3 (and Xbox 360) PowerPC cores run at 1/2 clock (1.6 GHz) and run strict in-order. They benchmark similarly to a Power Macintosh at a hair below 1.0 GHz once you’ve added in all those demerits.

> And I’m telling you that if what you mean by that is something you call ‘UME’, it is only going to run acceptably on Core i3/i5-based PCs. And it’s going to be a total crapshoot on any console/tablet/phone.

I’m told that MAME exactly as we ship it runs terrific on the Apple A7 – 60 FPS in even many PlayStation hardware games. I always expected mobile CPUs would catch up with us, and hey, I was right.

> Actually, the PS3 (and Xbox 360) PowerPC cores run at 1/2 clock (1.6 GHz) and run strict in-order. They benchmark similarly to a Power Macintosh at a hair below 1.0 GHz once you’ve added in all those demerits.

Because you certainly need to tell somebody who actually programmed for this stuff and had the SDKs that they are in-order CPUs.

The Cell PPE is a 3GHz in-order PPC core. Doesn’t mean it’s any good though – it barely runs 20% faster than a Wii CPU.

Xenon (the 360 CPU) is a 3-core variant of Cell sans the SPUs and with VMX128 extensions. It performs just as crappily.

In short – what I was trying to say is that to make a stupid comment like Haze’s “you can get a 3GHz CPu for pennies” means exactly nothing in terms of how well it’s going to run code.

The Raspberry Pi has a 700MHz ARMv6 CPU. It runs code exactly two times slower than a Gamecube. Careful reading here now – that is a Gamecube. Not a Wii – which is two times faster than a Gamecube.

You realize that Core 2 Duos were released in 2006 and are relatively sluggish by today’s standards, right?

2006 processors, PS3…did you fall into a coma in 2006 and just come out or something?

>With a G-Sync monitor or GroovyMAME, every game in MAME runs glass smooth at its native refresh rate with no issues

Why go through all the trouble if you could just RA with KMS?

>RetroArch isn’t doing SHIT for MAME’s audio or video sync

It does have reduced latency, especially when compared to any sort of SDL-frontend.
Writing “SHIT” in Capslock doesn’t help your argumentation either.

>Horseshit. Complete horseshit.

Instead of proving your points you’ll keep swearing, which is a sign of either ignorance or dumbness.

They’re not 3 GHz PPC cores though. On each core, thread 0 runs on even clock cycles and thread 1 on odd clock cycles. If they both ran every clock they might have been tolerable. (And a lot more Xbox360s might have unsoldered themselves from the PCB).

Raspberry Pi’s a chimera anyway – it doesn’t even represent the fastest SoC you can get for $30, just the one with the least amount of binary firmware necessary to boot Linux.

And yeah, A7 does indeed perform great.

Still, no competing CPU for Android is at those performance levels right now so MAME/MESS as this “universal emulator” would still be exclusively reserved for the most high-end systems out there (iPad mini Retina/iPhone 5s) and for Android you wouldn’t even be at that stage.

So it would take at least another good 3/4 years for any kind of decent uptake of decent hardware for something like UME to even be practical as an ‘all-in-one emulator solution’ for such systems.

And on these systems you really want to do everything you can to conserve battery or else users are going to bitch. In short, if the future is indeed post-PC, then MAME/MESS/UME in its current form will not be in a very enviable position by virtue of the very high performance bottleneck.

It’s hard enough getting decent A/V sync on Android as-is with all the crap that goes on with that scheduler and the stupid throttling policies vendors impose. Performance-focused coding like Drastic will become more important in the long run than ever – and I haven’t seen too many people say that Exophase’s fast NEON renderer for PCSX ReARMed is too ‘inaccurate’ compared to Mednafen PSX. So ‘accurate’ doesn’t have to equal being abysmally slow either.

So why does a driver that didn’t even have any major significant changes done to it run at least 6% faster in MAME 0.150 vs. MAME 0.139?

I’ll try making some performance figures sometime so that we can actually get some conclusive figures on this.

>> and I haven’t seen too many people say that Exophase’s fast NEON renderer for PCSX ReARMed is too ‘inaccurate’ compared to Mednafen PSX. So ‘accurate’ doesn’t have to equal being abysmally slow either.

The ‘problem’ is getting from 95% to 100% is what can kill your performance by 400%

this is exactly what byuu found with things like bSnes, emulating 95% of the library is easy, the remaining 5% actually need really really tight emulation.

usually that 95% cover all the games people care about, so they’ll instantly assume the slower emulator is worse.

if you goal is to actually write a proper emulator then 95% ISN’T good enough tho, that’s why MESS is attempting LLE with N64 first, in the hope that it can run the remaining 5% of games all the higher level emulators fail on, of course it’s still some way from doing that.

Convincing people that the slower emulator is better.. near impossible, maintaining 2 entirely separate emulation cores just so you can run the 95% with one and the 5% with another, crazy (and how can you be 100% sure)

Trying to allow per-game tweaks to get around this seems to have ultimately what has backed the various Saturn and Jaguar emulators into corners.

So you can aim for the correct approach (and I’ll admit, we do currently miss in significant ways for many MESS drivers) or you can accept that the majority of the population will be happy with 95% and push no further because you know it will kill your performance..

I feel we have a duty to try and do things correctly, and push on for that 100%, even if it has a high cost, this is why the recommended platform for running MAME / MESS is always the best on the market.

It does concern me that we’re not seeing the advances we’ve seen in the past, because if we want to do certain things properly we have an unavoidable barrier of NEEDING more CPU power, but making compromises to the emulation in cases where the required CPU power does exist isn’t really logical.

We emulate hardware, not games.. If we do a good job all the games run on all the platforms using that hardware. That’s why I prefer the UME approach (and also why I think the MAME/MESS split is silly because so often the hardware is the 99.9% the same) you have more test cases than you can dream of to prove your emulation. That is why ultimately that approach is the future and why encouraging that approach is preferential. Unfortunately some people seem to like to stick with other solutions even long after they’re redundant, which doesn’t help our cause at all. The mobile platforms will, as you observe, catch up eventually.

The problem is people stick with things out of habit, so annoyingly may always favor other solutions ahead of MESS/UME even in cases where it is perfectly adequate, this is why I like the idea of having it as a part of MAME, they’re at least more likely to try it that way if they already have MAME for the arcade part before looking for other solutions if it doesn’t meet their needs.

Squarepusher go back to posting on 4chan you miserable autist. Why does emulation always attract these kinds of characters?

I meant accusing of course. Bloody autocorrect ;)

just 2 minor bits that needed to be said

about RA vs SDL
> All you have to do to convince yourself of that is to run the two side by side.
> You don’t need ‘me’ to convince you on anything.

I dislike anything beyond command line and the internal UI, so a side-by-side comparison just shows me that SDL OSD is definitely better than retroarch, because it already contains all I need and it starts faster

if I want fancy UI, I go with the web interface which got added short ago and equally well works in every OS with a web browser

I really have no use for RA at the moment, but I have no problem if other people use it: to each their own

> The future is emulators as a pluggable core – the future is convergence of
> emulators with separate frontends – whether it’s a media player like XBMC
> or a general-purpose frontend like RetroArch.

Such a future sucks. I don’t want a media player to take my hand and lead me where *it* thinks I want to go, I want to be able to fiddle with the cores so to have the experience *I* want to have

So there was a 0.153 release? I couldn’t find any mention of it in the 100 hostile comments here… :)

Anyway…. make MAME work on my Nokia 3310 David!!!! I demand it… its the way the market’s going. I think mobiles are gonna be HUGE! I can feel it…

fwiw We optimize things too sometimes, eg. the tagmap reductions.

Sometimes the video functions too, I spent a while optimizing the PGM sprite renderers a while back, no visible differences or ‘major work’, but I felt the code could simply be more efficient without compromising any accuracy.

If you want another example of going the other way Tempest is (significantly) slower in 0.153, but for the first time ever it should actually be 100% reliable as far as the protection emulation goes, everything now runs in single step, but this naturally has much higher requirements. Only expert players are going to notice it working properly now, whereas 99% of the public will just think we made it too slow to run on their mobile devices. In the end that was a one line change, doesn’t look like major work, but it did have a major performance impact. Things like The New Zealand Story got similar treatment in the past, as did one of the Data East drivers; running in perfect sync allowed removal of some ugly hacks to avoid unwanted IRQs. Some other stuff slowed down because the cost of doing dynamic memory mapping ‘the old way’ increased somewhat, although MAME has other more modern neater ways to do some of that now.

6% over the course of the versions you specify can easily be explained by some of the work being done to make the code easier to work with, which will help with actual emulation development. Nobody is claiming that doing things properly doesn’t have a cost.

Mobile platforms with limited power, or where you have to worry about battery life all the time will always be at odds with doing things the proper way, that is unavoidable, despite people having a desire to run emulators on these things they are at odds with the goal of actually creating and providing a good quality emulator, rather than one full of hacks. If MAME and other emulators are to thrive and survive the code needs to continue to evolve to be as easy to work with as possible, that is how it has always survived where other emulators haven’t.

What a MESS about all this !

First i’m a little sad about all this because i have
lot of respect about the two project . MAME & LIBRETRO
I also have respect for the Haze and SquarePusher .
But also for the mamedev team and the libretro dev team.

MAME/MESS/UME is one of the great project i follow since many years.
(i’m more a user of MESS , then i use UME which give the best of the two in one ) .
Like big project , he had advantages and disadvantages.
A policy made ​​by MAMEDEV not always understandable to the end user.

LIBRETRO , another great project that i follow .
That clearly give good A/V sync ,input , good support for shaders , and that is multi-platform.
this is why i used this API for some of my dev and some of emulator ports.
and i personnaly use Libretro core UME on linux ( BTW using UME command line style , not the RGUI ways ) .
it gives me better result than the SDL port on my old Intel Core 2 .

Well , i’m also sad because i understand , that the Libretro OSD part will never be “upstreamed” .

Even if it would be a third choice for the user , “the upstream ” would lead to have a better choice for OSD . Not because Libretro is superior to SDL or D3D , but because it will add more choice to the user. ( this is my personal opinion ).

I also understand , than more than Libretro library ,
it will be difficult to have another library for osd other than SDL or D3D in mame. (do not evolve here )

But i also understand , that this is certainly not the right place to discuss all this.

As you said haze , it’s your site , the place where you express what you want /like and not an arena where we are fighting for have the last word.

Squarepusher , I know that your project is important to you, (and I think this is a good project) but do not want to force others to absolutely use it , let them come to you. If they have interest on it , then they will come to use it themself.

Sorry for the babelfish english : )
and congratulation for the 0.153

My two cents…

>If you want another example of going the other way Tempest
>is (significantly) slower in 0.153, but for the first time ever it
>should actually be 100% reliable as far as the protection
>emulation goes

It’s actually a hack needed after the rewrite because of limitations in how it was done. Using device_execute_interface for anything other than cpu’s right now just doesn’t work properly unless you run everything with 1:1 interleave (which is the “fix” in 0.153). I would have personally just reverted to before the rewrite.

>If you would compile the libretro core to go along with it, you could have versions for non-Windows as well (Linux, OSX, etc).
>I don’t understand having Windows-only binaries in the year 2014.

I don’t understand how you thought starting out with this attitude would end well. It’s built from public svn, so there is nothing stopping you from doing it.

I do understand having Windows-only binaries in the year 2014. I don’t understand what makes someone run Linux or OSX.

smf: I know it’s not your use case, but accurate low resolution output to real hardware is not happening with current versions of Windows…

Mind you, with Linux it’s dead easy to just grab the latest source and compile.

> Even if your code is the best thing since sliced bread you’ve made yourself look like a “hostile upstream” and no one wants to depend on stuff that is controlled by a complete asshole.

Yeah right – as if anything was ever going to be “upstreamed” to begin with. Scummdev and Mamedev are notorious for this kind of cult-like behavior so I’m just happy with a shallow fork as-is – I don’t really “need” upstream for anything – I just thought it was a nice gesture since I saw all the talk from Haze in a prior thread about how “RetroArch is a dangerous project ” blablabla.

Haze came after RA/libretro first – I did not go after Haze, MAME or MAMEdev first until I was sick of their misinformation and lies.

> I don’t understand how you thought starting out with this attitude would end well.

That’s because I did not “start out” with anything – it was Haze that started shittalking about RA being “dangerous” and lots of other accusations thrown the project’s way.

He should have expected a reaction one way or the other.

MAME invented “dynamic rate control” back in 1998. It’s still there, but we strictly limit how far out of tune the audio is allowed to go, and the growth of CPU power in that time means that finding games “on the edge” where that might help is strongly unlikely. Things essentially either run 100% or 20% once you have a fast enough processor.

This is not a flame, but a question. How can there be console emulators running on the next generation system? I have heard of emulators: Saturn for Dreamcast, PS2 for PS3, and X-Box for X-Box 360. They say they run near 100% compatibility and speed.

smf does not reflect the attitudes of the team as a whole. Among active devs, Windows is actually bordering on being a minority platform, but we like to keep the skids greased so any and all would-be developers can work in an environment they’re comfortable with.

you seem to ignore that around half of the MAME/MESS devs develop their code on Linux or MacOSX, and that a lot of users just compile the svn on both Linux and MacOSX as is
as such portability is not an issue at all with current source and we still try to support PPC Macs and machines with OS/2, just because we can

even for lazy users the situation is not that bad: even if binaries cannot be found here at Haze’s blog, most Linux distro have the latest builds in their repo and MacOSX users can easily find this website http://sdlmame.lngn.net/ or one of his mirrors

in conclusion, I can’t understand why you’re pushing RA as the solution to make MAME/MESS available on other OSes: it is already available since 2006 and it has the exact same interface on Windows/Linux/MacOSX
for people who don’t like our interface or for people who wants to use the emulator on their Android device, RA might be a great alternative, but I don’t see why we shall replace our current portable code with the RA API

RetroArch is “dangerous” to the survivability of MAME/MESS/UME because what you want requires sacrificing accuracy in exchange for performance. You’ve been around long enough to know that’s not what those projects are striving for. Accuracy is paramount. The hacks that exist are only there until accuracy can be improved. Be glad that you are able to run games on your digital toaster at all.

Throwing a fit and slinging insults when your “suggestion” was refused certainly didn’t help your case either. If your parents didn’t commit suicide from having raised you, you should go get them to give you all of the ass-beatings you clearly needed because the time-outs didn’t work.

> And now you want to insult somebody who has done more for SNES emulation in a year or two

That’s bullshit.

Anomie and zsKnight did infinitely more work. Byuu just picked up the pieces from prior existing work and turned it into bsnes.

You are putting a person on a pedestal that does not deserve being put on a pedestal, and his code certainly isn’t anything to be proud of.

as I’ve said already, it’s that last 5% that is the REAL work, that’s the 5% byuu did, that’s WHY actual emulation coders hold him in such high regard.

making 95% of the games run with approximate hacks and hoping people won’t encounter the glitches is easy.

again you’re just showing that you know nothing about actual emulation.

It is your prerogatve to put people on a pedestal all you want. Doesn’t mean I have to buy your bullshit.

All of these “talking points” you are telling me I have heard over a million times already by his cult fanbase.

I’m sorry, but I simply don’t regard the “work” he did as being all that significant or even noteworthy. He is just a glorified ROM hacker that arrived at the current accuracy levels through lots of trial-and-error. So yeah, he surely invested a lot of time to look into all those edge cases. Doesn’t mean he is Jesus that walks on water.

And FYI, I don’t regard “emulation coding” as being all that significant either.

I certainly don’t put any of you guys on a pedestal. None of the work you do is really any more “special” than writing a game is or a business application. I know you don’t like hearing this but it’s true.

It would behoove the entire emulation community if they would get back to Earth, stop losing the ego and just accept the fact that they’re just another branch of software engineering and that they’re not in any way “better” or more “skilled” than anybody else.

And that’s why you should accept responsibility for singlehandedly inciting a shitstorm. Because you were fully aware of what you were doing and you knew it would turn into this because you created the pretext for it.

As this is an emulation discussion I will judge people by their contributions to EMULATION.

With that in mind Byuu is nearly unsurpassed in the work he has done, even if I disagree with some of his later choices.

In the end what Byuu created will be looked back on by people who actually understand these things as the pinnacle of SNES emulation for the time, it’s a shame we haven’t managed to achieve that with MESS but in terms of getting a standalone emulator ‘just right’ you can’t look beyond bSnes.

But you’ve shit talked me, despite, in actual emulation terms, many of the things I’ve worked on being the more memorable emulation events over the years, and now you’re shit talking Byuu, yet you’ve achieved nothing in terms of emulation, and appear, from your previous comments, to have a VERY limited knowledge of how things work and what actually makes for a good emulator.

Why is any of this ‘special’? Well the actual emulation discoveries we make are once in a lifetime events, once something is discovered, and done properly it exists and is known for the rest of history, for our kids, our kids kids etc. Getting things RIGHT while the real hardware still exists is important. You can slap a million frontends on things, but without the actual emulation you have nothing, hence why Raiden 2 isn’t in any of the recent re-release packs (the clowns at DotEmu really can’t emulate / reverse engineer anything themselves, they’re front end coders). I wouldn’t really use the term special anyway, but I would say it’s important work, securing knowledge from our past for the future and to do that you really need ONE correct implementation of every chip, not a dozen because it’s faster, in the end faster won’t matter, correct will.

Keep in mind this is the main reason I still contribute to MAME despite my personal differences with the team, I feel the actual project is too important to let rot over some personal disagreements which exist for a tiny period of history compared to the value of what is discovered and the period for which that will be relevant and important. We owe it to the generations that come will after us to do the best we can while we can.

> But you’ve shit talked me, despite, in actual emulation terms, many of the things I’ve worked on being the more memorable emulation events over the years, and now you’re shit talking Byuu, yet you’ve achieved nothing in terms of emulation, and appear, from your previous comments, to have a VERY limited knowledge of how things work and what actually makes for a good emulator.

Yes, because obviously people who don’t understand what an API even is or still think raw clock speeds is what makes a CPU fast are obviously SOOOO much more knowledgeable than I could ever hope to be.

I asked you again why emulation coding should be considered as any more significant or “hardcore” than game coding, demo coding, business application coding, and you never provided a suitable answer to that.

Face it – the reason you’re not answering that question is because there is no answer to it. None of the stuff you’re doing is really all that significant or “noteworthy” compared to other fields of programming.

> I had a look at your code by the way. There are some nice “not x86/amd64? make general assumptions” in there that are pretty funny.

Yes, because obviously I commit code under the nickname “r-type”.

FYI – I commit code under the alias “twinaphex”.

Now how about them glass houses and stones and all that?

> FYI, I regard the work I’m doing with a generic API and loosely coupled frontends as being infinitely more important than any of the stuff you’re doing with MAME. But that is just me.

You need UME more than it needs you. It has some of the best emulation that exists and a mediocre frontend. Your frontend might be the bee’s knees (haven’t tried it) but you have no emulator. Everyone and their fucking dog is working on a frontend. How is what you’re offering infinitely more important than anything?

@Squarepusher

>Yes, because obviously I commit code under the nickname “r-type”.

It’s your fantastic project mate.. you should be in there sorting all of the nastiness out before trying to make out a library for gluing other people’s work together is something amazing that people with actual skills should be taking notice of.
You are expecting Haze to answer for all of the MAME source so you should expect your whole codebase to be fair game.

>Now how about them glass houses and stones and all that?

Do you know what that phrase means? If I had said your code is crap because of XYZ and I had done the same thing in my code then you could use that retort but it makes no sense here matey jim.

> MESS/UME/MAME already runs in libretro frontends like RA with zero hacks.

I was referring to the hacks that exist in MAME/MESS/UME until accuracy can be achieved. You didn’t read everything I said before you posted. Do you even understand what reading comprehension is?

@Moo

You don’t want to mess with this guy.. he can write cycle exact cpu cores that emulate all undocumented behavior in his sleep. That work is simple so he leaves it to others. He uses his mad skills on the hard stuff like cutting up other peoples code and making menus.

> It’s your fantastic project mate.. you should be in there sorting all of the nastiness out before trying to make out a library for gluing other people’s work together is something amazing that people with actual skills should be taking notice of.

Good thing I didn’t do that now did I son?

This might be hard for you to understand – but it was Haze that started off this entire thing – not me.

I frankly don’t give a rat’s ass whether you think LR/RA is significant or not. All I know is your official frontend sucks ass in the departments where it matters and it will continue to suck ass for many years to come. Which is why me and others made an alternative implementation of it.

Sucks for you maybe that other people like using it as well but that’s just what it is.

Gentlemen, pls don’t feed the troll. 2^7 posts should be enough.

>This might be hard for you to understand – but it was Haze that started off this entire thing – not me.

That isn’t entirely accurate:

“If you would compile the libretro core to go along with it, you could have versions for non-Windows as well (Linux, OSX, etc).

I don’t understand having Windows-only binaries in the year 2014.”

You probably don’t see why someone would find that offensive.

>but it was Haze that started off this entire thing – not me.

It went like this didn’t it:
You: Only a Windows binary in 2014. You act like this is your own site distributing binaries generated from source that you have been involved in developing. Use my API or I will cry like a baby.

Haze: We don’t want to depend on your library. It doesn’t offer anything we want. Feel free to develop a frontend but it’s not something we will use.

You: MAME sucks. You guys don’t know shit. My library is amazing. (Background noise of your mum calling you for diner).

>All I know is your official frontend sucks ass

There are plenty of frontends for MAME. The only thing special about yours apparently is you.

> Haze: We don’t want to depend on your library. It doesn’t offer anything we want. Feel free to develop a frontend but it’s not something we will use.

Good thing it has already been developed and the port has already existed for months now hasn’t it?

Are you going to continue talking shit about a subject matter you know nothing about or are you going to do something actually productive now?

Emulation doesn’t have to be “special” to you. You clearly care about getting your way more than you care about having things done correctly. Haze did answer your question as to why the work is important. Just because YOU didn’t like the answer doesn’t mean it was the wrong answer.

> I’m certainly tired of this entire ‘debate’ and I’m going to do something else now. Whatever MAMEdev does or says about RA/libretro/me is no longer any of my concern

That was posted by you a while ago. Guys usually aren’t the type for long goodbyes.

well, you stated many times that pluggable emulators with a common API is the future and that merging the libretro API was the way to go to support other OSes. this sounds to me as a suggestion to replace the current OSD handling, even if only at a later stage, and I wanted to point out that I would never support such a move

OTOH, I have browsed last week the libretro OSD layer available in the git repository and at the moment it does not offer all the functionalities of the other OSD layers
this is the main reason why it has no hope to be included upstream as is

feel free to clean it up, following the example of other OSD layers, and to submit it in a better shape, and then we can start discussing whether it offers something we want to endorse or not
if we were as tight as you claim we would not have neither the web browser nor LUA support [1] to make possible auto-loading of tapes or disks in home computers…

[1] even if we would need someone to start providing a series of default scripts for popular home computers, if we want to better inform users about the scripting possibilities

If you don’t care if you come across as offensive then you were just baiting so you could use the negative reaction you expected as an excuse to talk shit? Why should anyone give a fuck about offending you if you don’t care about offending them?

The OSD being garbage is hardly news to anyone on the MAME or MESS teams, Squarepusher. It’s one of the least-refactored parts of MAME over the last 5-10 years and is desperately in need of a re-write. The only problem is that you’ve effectively plumbed the existing OSD layer into RA and then called it a day, which certainly helps RA be a jack of all trades and master of fuck-all, but doesn’t really help one of the many projects you half-heartedly plunder in your quest for fawning fans. Hell, in terms of caring more about users than accurate emulation, by that metric alone you and Haze should get married, you two are perfect for each other.

It’s about time for you to give up. You’re obviously not going to get what you want here. Do what you want without official support from MAMEDev, write your own emulator or leave. Not much else you can do except troll and be trolled.

Byuu did a ton of reverse-engineering on his own, and he’s backed all of it up with test programs that run on hardware. I have certain differences with him, but he’s actually an excellent software engineer (he got into C++11 about 2 years before everyone else) and bsnes is not in any way deliberately inefficient.

> I had a look at your code by the way. There are some nice “not x86/amd64? make general assumptions” in there that are pretty funny.

>Yes, because obviously I commit code under the nickname “r-type”.

@dgp @squarepusher

Could you explain here ?
I really want to know why i am here ?

Is this related to the part of MAME Libretro OSD i done ? or another libretro port i done ?

I repeat once again I do not belong to the authors libretro and I never writing a line of code Libretro library.

I am just a user of the API and i have done some ports .

>Seriously, if even MAMEdev doesn’t comprehend the model and doesn’t want to comprehend it then it’s time to leave this thread.

You’re going to sulk because insulting us hasn’t worked?

> It’s quite sad that you think this is actually a valid comparison.

That’s true. Mednafen actually creates their own emulation cores. And they’re of high quality.

>Libretro is an integration API for real-time apps,
>providing audio/video/input callbacks.

Sounds amazing. Oh wait.. is it actually shipped in any Linux distribution yet? Is it used by anything that isn’t just a crappy toy project?
Your “Technical Brochure” is comical. All you have created is yet another abstraction layer for a bunch other libraries/os layers. Woop -de-doo.
So you take a bunch of high level applications written by someone else and wrap a bunch of interfaces that do the work that are also someone else’s creation.

> Sounds amazing. Oh wait.. is it actually shipped in any Linux distribution yet? Is it used by anything that isn’t just a crappy toy project?

RetroArch happens to be a good A/V frontend layer that is kicking your own ass right now.

I wouldn’t call that a ‘crappy toy project’ without you having anything better to show for it.

> Your “Technical Brochure” is comical.

I could look at any technical explanation and ridicule it. Doesn’t mean you actually have a point.

> All you have created is yet another abstraction layer for a bunch other libraries/os layers. Woop -de-doo.

And in a way that it’s not limited to any one application and in a way that any program can hook into this API and get access to the same content in a uniform way.

You simply still don’t get it.

> So you take a bunch of high level applications written by someone else and wrap a bunch of interfaces that do the work that are also someone else’s creation.

Still having problems with getting the whole significance of something being an “integration API” I guess.

>Still having problems with getting the whole significance
>of something being an “integration API” I guess.

No, that is understood perfectly well. The problem is you don’t actually offer anything that’s worth having that isn’t available elsewhere in libraries that people actually use.

You seem to have mistaken one developer uploading a Windows binary to their personal site as meaning the MAME/MESS don’t work well on other platforms when it works perfectly fine on all of the platforms people actually care about via SDL.

So all you have left is a frontend.. Which can be done without MAME/MESS being linked with your library in any way shape or form.

> You seem to have mistaken one developer uploading a Windows binary to their personal site as meaning the MAME/MESS don’t work well on other platforms

It doesn’t. Nobody on a Mac would even think of touching your garbage “official” frontend MAME version (none of which run worth a damn BTW – my own personal experience).

Hence why people would rather use something like OpenEmu. You simply aren’t delivering there, and never will in a way that will satisfy Mac users.

Just admit your entire project is a Win32-focused project with only lip service being paid to OSX/UNIX.

> You seem to have mistaken one developer uploading a Windows binary to their personal site as meaning the MAME/MESS don’t work well on other platforms when it works perfectly fine on all of the platforms people actually care about via SDL.

SDL is garbage dude. I wouldn’t even touch that crap with a ten-foot pole.

> So all you have left is a frontend..

No I don’t. I still have a reference frontend AND an API that allows projects like XBMC and Arcan to play games with MAME cores,or any other core that they fancy.

Something SDL on its own cannot accomplish.

But see – this is what you and your MAME ilk are actually afraid of – that the standalone MAME application is no longer the only way to actually ‘run’ MAME. Well tough shit. That’s evolution catching up with your punk ass.

See, I get why you people are against it. You fear that it will ‘dilute’ your brand. Well, fuck your brand – there is nothing ‘significant’ about your brand.

What it should be about is the ‘core code’ that MAME/MESS/UME provides. You don’t want other apps plugging into your work – well tough shit, that is what is aready happening, and not a goddamn thing you can do about it.

>Win32-focused project with only lip service being paid to OSX/UNIX.

MAME and MESS both work perfectly fine for me on Debian/AMD64. One thing you’re missing is that MAME/MESS isn’t just about playing games. The source code uncompiled is worth more than you can probably imagine. You seem to think that your limited range of use is all that matters.

>SDL is garbage dude.
That might very well be the case but I don’t really see yet another library that wraps exactly the same libraries and interfaces that SDL does that no one uses being any better.

>Well, fuck your brand – there is nothing ‘significant’
>about your brand.

If you want your framework to take off you might want to stop insulting the people that develop the only “killer app” you have.

> nobody wants to help you because you so clearly just want to fuck everyone over.

As a man thinketh, so is he – and all that…

I don’t want to fuck anyone over. It’s you guys that want to cast aspersions on this project and decide that it is detrimental to MAME/MESS/UME.

I’m offering you a way for both projects to work together. It’s you guys that don’t want to do that. And then you turn it around and claim that I’m the one that wants to “fuck you over”. You’re quite a deceptive guy aren’t you?

>Err – no. You think too highly of yourself.

You seem to have failed to realise that I’m not a mamedev.

>You also have all of these –
>http://www.libretro.com/index.php/ecosystem/

Ah yes, lots of emulators that were mostly already using SDL right?

This is a school project gone too far right?

>But the end result is going to be the same anyway – MAME/MESS/UME will continue being a library, it will continue being usable in applications that have nothing to do with MAME, and there’s nothing you can do to stop that.

I think you’d be surprised how quickly MAMEdev and Haze can agree on new license terms if you want to keep playing that kind of chicken.

> I think you’d be surprised how quickly MAMEdev and Haze can agree on new license terms if you want to keep playing that kind of chicken.

So what do you want to do? Disallow MAME from being usable in separate frontends?

You’re batshit insane if you think that is what is in order here, and BTW – since you’re already dual-licensing – this would never fly in court – the GPL would certainly never allow you to do this, so better go and remove all the GPL portions out of it as well.

I have to say you people are simply unbelievable. Why don’t you go and make your entire project closed-source to begin with? Sounds like that is what you want to do.

But see – you can’t – because you didn’t even make this thing – Nicola did – before you were even involved.

@Squarepusher @dgp,

Maybe one of you can tell me… you tell me and tell that i code shit, aim i would like to know Where and when?

“Not at all. We love frontend authors who respect our work and don’t attempt to rain shit on us for made up slights like Haze not posting binaries for machines he doesn’t own. So you’d still be able to run MAME, you’d just have to call out to an executable we provide like normal frontends do. (QMC2 even can pull MAME’s audio/video/input into it’s own window without our having to do anything, it’s a neat trick).”

There’s no possible way such a license change would fly and how you could possibly enforce that.

You might as well make the project closed-source if you’re going down that road – oh yeah, and add an EULA as well to it.

Fact is – you don’t believe in opensource. You believe in proprietary software and in your own kind of virulent licensing.

I think it’s related to the make rules you had to tweak, nothing else man

“I had a look at your code by the way. There are some nice “not x86/amd64? make general assumptions” in there that are pretty funny.”

Then you are simply batshit insane. I’m sorry but that is what you are.

Seriously – just start calling yourself “proprietary software” from now on and stop calling yourself “open-source”. You don’t want any of it.

BTW – your recent license change is still considered by many to be illegal.

@dgp Don’t start antagonizing others now and attributing that to me.

That code comment simply wasn’t something I added so the only people that could have added that could be either r-type or AndresSM.

Anyway, you never explained why it was “bad” so no, I have never accused him of anything – it was “you” that said that without providing any further explanation.

> Fact is – you don’t believe in opensource. You believe in proprietary software and in your own kind of virulent licensing.

Nope. We were willing to ignore you and let you do anything you like. We might even have accepted your OSD as a submit. But that was before you decided that Haze’s inability to post binaries for machines he doesn’t own meant you needed to insult MAMEdev. (And wait’ll byuu sees this thread…)

Let me be very clear: anything that happens is going to be your fault, and your fault alone. You can still untangle your project from the consequences of your mouth by apologizing, but that’s not a window that will be open forever.

> You started antagonizing me – I don’t antagonize you guys.

Your problem here is that people can look up thread and see what actually happened. Haze posted a release announcement, you told him he should provide non-Windows builds, he explained politely why he didn’t, and you immediately started in on the insults with “How lame and how narrowminded”.

Like I said, this thread sells your own demise by itself.

@Squarepusher

Get your “modern software engineering principles” cap on and work it out. Blaming members of your own team without even knowing what you’re blaming them for tsk tsk.

> Like I said, this thread sells your own demise by itself.

Whatever you want to tell yourself man.

BTW – I don’t give a shit about byuu.

And BTW2 – illegal license changes are still a big deal. I’d be more worried about how utterly ridiculous this would make your project look and how nobody would want to ‘borrow’ any more source from you if you are going to impose this license change.

> He didn’t tell Haze to provide, he said IF HE WOULD provide.

Sure, but Haze still responded in a polite manner. It was Squarepuncher who chose to go directly to insults after that.

> And if it’s not only for emulators, why’s it called “retro”?

Because there’s no point in doing another name change at this point – we already went through that before with libsnes and there’s no point in doing it again.

>> You seem to have mistaken one developer uploading a Windows binary to
>> their personal site as meaning the MAME/MESS don’t work well on other platforms
>
> It doesn’t. Nobody on a Mac would even think of touching your garbage “official”
> frontend MAME version (none of which run worth a damn BTW – my own personal experience).
>
> Hence why people would rather use something like OpenEmu. You simply
> aren’t delivering there, and never will in a way that will satisfy Mac users.

I do use it on a Mac, using command line and the internal UI. A dozen of my friends use it, combined with QMC2. Hell, even my girlfriend use it, using a mobile device to control the interface via the web interface. maybe in Italy we are all genius, or maybe you confuse your opinion with an absolute truth…

> I’m offering you a way for both projects to work together. It’s you guys that
> don’t want to do that.

point is we don’t see any gain to work together and you seem to offer nothing beyond what we see, except for easier support on Android devices which are not our main target at all…
maybe, with a more collaborative attitude from your end, things would have gone differently, but as things stand my interest in your API has reached 0.
we will see in 5 years whether the future of emulation was an integration between emulation cores like Mednafen and MAME or an API with pluggable cores like the one you propose

I’ve seen this before. It’s the ranting of a bipolar, psychopathic drunk.

Don’t go away mad, just keep the promise you’ve broken twice already and simply go away.

“And BTW2 – illegal license changes are still a big deal. I’d be more worried about how utterly ridiculous this would make your project look and how nobody would want to ‘borrow’ any more source from you if you are going to impose this license change.”

Who said anything about an ‘illegal’ license change? You aren’t allowed to distribute something called MAME or that implies any relationship with us without a trademark license for a start.

People steal our code all the time and include it in their GPL or closed source emulators.

>smf: I know it’s not your use case, but accurate low resolution
> output to real hardware is not happening with current
> versions of Windows…

There are some people using 15khz monitors on older versions of Windows, their hacked drivers don’t work past Vista (or some such version though). Just cut off the front of the tube and stick a full HD LCD TV behind it, .

I don´t like, that Retro arch doesn´t suport the debugger, because as I know it´s a very importand thing in emulation.
I don´t think, that Mame, Mess, Ume are thinks that need to run under Liberto, there are far better (less portable (in meaning of oc,cpuarch…)) projekts you schould concentrate on.
E.g. : Warzone2100, Widelands, pcsx2, cxbx, …

>Sorry but I have no respect for you or any of the people in >MAMEdev if this is truly what you BELIEVE.

It’s fine, I have no respect for you if you believe that I am not entitled to my opinion over what operating system I should use.

Or that Haze is entitled to only put out Windows binaries if that is what he wants to do.

>It explains a lot of things about your project though.

What does it explain exactly?

1. Yeah, I wrote my own name wrong.
2. To be honest it would be totally great to get Wine running on Liberto.
3.You could try to port bochs
4.Mame allready runs on things like Raspberry pi. Soo, there aren´t many platforms left.
5.From an userperspective Mame seams lik a bunch of emulators glued together, like many packs out there. There for, they don´t get why they don´t use the existing emulators and bundle them. (Now I knew, this is because of (modularity?) there use of the same code for multiple machines (the same cpu code for the same cpu…)
6.I don´t think Mame wouldn´t gäin much out of this cooperation, if any at all.

Is SDL 2 officially supported on OSX yet?
Not trying to fan any flames, just wondering.

> Haze saying why he considers Retroarch dangerous isn’t a lie and is also a reasonable point. You just don’t share it because you don’t consider emulation programming special.

No, I don’t share it because there is nothing to ‘fear’ and because it is run by a guy who is as opposed to “commercializing” emulators as you guys are.

But then again if you walk into this with a preconceived notion and conclusion, then there is no possible way to convince you of anything otherwise.

BTW – it would really “help” if you would respond to my PMs on IRC instead of insisting on talking to me on this “forum”. The sincerity to resolve this with you is there – but it’s a two-way street.

Other wise you be seeing them doing those as well.

“BTW – it would really “help” if you would respond to my PMs on IRC instead of insisting on talking to me on this “forum”.

I didn’t see any PM on IRC because it’s running in the background. I did try to reply but you have gone.

EPIC! That was an amazing read through. I’m still confused on Squarepushers comments regarding Haze saying RetroArch is a “dangerous” project (Squarepushers comment: April 9, 2014 at 14:44). Given that Squarepusher uses quotes around dangerous it must be a direct quote, yet I cannot find it on this page. Must be a reference to a thread found elsewhere, anyone have a link (b/c if it is anything like this thread, it will be a great read)?

Anyway… I just did a: git pull -> git checkout tags/mame0153 -> make TARGET=UME -j7 (thanks to arbee for making SDL so easy) so would like to learn about the points of interest for this release.

> > and at the moment it does not offer all the functionalities of the other OSD layers
> > this is the main reason why it has no hope to be included upstream as is
>
> I’d like examples of what these are then.

I stand corrected. while browsing the git repository I read the README and seen various missing features (e.g. that only carts were working), but it seems I was not browsing the latest tree because that part is now not there anymore
unfortunately, your attitude still suggests that SDL is a better choice

You know what amuses me most about this whole thing.. Squarepusher constantly saying our OSD and frontend is shit.

A lot of people CHOOSE to use MAME because what we offer is already a lot better than the alternatives out there, people have been massively disappointed by many commercial efforts because they don’t offer the many options, flexibility and reliability of our very own project so often feel like they’re paying for something that is actually worse than MAME. Look at the DotEmu Raiden / IREM packs, you find a lot of people just wanting to use MAME instead because whatever OSD code they’ve put around the MAME CPU cores simply isn’t as stable / satisfactory as the one we offer.

Sure there IS room for improvement (which I’m sure will come with time) but you’d be surprised by how many people already actively choose what we offer.

> unfortunately, your attitude still suggests that SDL is a better choice

It’s not like your attitude is any better as of right now – I tried several times now to resolve our differences but none of you are having any of that.

Yeahyeah, I get that. Your pride got massively stamped on, yadda yadda. I get it now. Anyway, I’m out of this thread. If you guys want to actually talk constructively you know where to find me (and unlike you guys – I don’t autoban people by default when they’re away and then no longer give them a chance to resolve the situation).

>It’s not like your attitude is any better as of right now – I tried several times now to resolve our differences but none of you are having any of that.

Let’s play the innocent victim who got flamed for no reasons by nasty mamedevs

> Your pride got massively stamped on

I turn crazy because mamedevs say they don’t give a shit about my work and do not kiss my ass when I insult their work in return, that’s because they are jealous of me off course

> Anyway, I’m out of this thread

I will be back soon because I am obsessed by my own image and how people perceives my work (= me)

Wow, came here expecting to read the newest changes from the 0.153 release only to see over 200 posts talking about the same thing. Regardless, I see RetroArch as an excellent API and respect Squarepusher’s work on it but at the sametime I completely disagree with his views. You can’t tell me you actually believe that your work on RetroArch is more important than the work the MAME team has put into MAME/MESS, there is no comparison, MAMEdev has contributed much more and is more important than RetroArch can ever hope to be towards emulation. While they move emulation forward with their focus on accuracy and writing their own cores, all RetroArch does is glue a bunch of emulators together which really does not do absolutely anything for the emulation scene as a whole except provide a more convenient way to play games. I still LOL at people who rely on emulation on underpowered crappy mobile smartphones or outdated home consoles. Just hook a laptop to your TV and get a controller, it will provide a much better gaming experience.

The future of emulation lies with MAME/MESS, I can’t see it going anywhere else. Playing classic console/arcade games on mobile devices will fade to obscurity soon as any other fad.

> I prefer staying somewhere nobody dare to step on my shoes or even argue with me, it’s so much more comfy not having to call himself into question

Gee, sounds exactly like #messdev now doesn’t it?

#messdev is a private social club of people who sometimes also are devs. Back when Nathan ran MESS it was indeed an official channel where you could talk to the people in charge, but that hasn’t been true for several years now and trying to negotiate anything with the creatures you find there will not end well.

Hey David, thank you so much for your hard work.
I’m really happy about your last game Mega Phoenix.
I wish can able to donate you for gals panic II, if was avaliable to use paysafecard, because i don´t have MasterCard. If this people want so badly games fixed? Go get your wallet and help the devs, nigga’s.
Glu, Glu, Glu for your reply on me.

I don’t want your money for this.

I’ve looked at Gals Panic 2 in the past, I don’t understand it, I think it needs somebody to run tests on the PCB to figure out the MCU behaviour.

Giving me money would not help emulate it, if somebody else wants to look at it the boards are very common and cheap.

It’s to see the mamedev team work together

You have to keep in mind that Squarepusher has repeated many times that the work on emulation has very little value to his eyes compared to actual game development (which is an opinion I can understand, even if I don’t agree: they are so different that you just can’t compare them).

Hence, I guess that in his opinion having emulators using his API is just a way to show off how flexible the API itself is and that he doesn’t find a difference in value between a generic new Flappy Bird clone or a complex emulator as long as they use RA for controls and A/V.

Unfortunately, at the moment SDL already offers all we need (including handling of multiple mice and keyboards in 2.0, which we need to handle multiplayer mahjong games), so that we don’t feel any urge to drop a library which is well established (see Steam adopting) in favor of retroarch/libretro

By reading the posts here written by actual RA users it looks like most of the hype comes from RA’s supposedly revolutionary A/V synchronization. Well, a similar approach to dynamic rate control has been implented since very long, first by CabMAME, and now by GroovyMAME. Maybe we didn’t write a paper with differential equations as we don’t have curricular motivations. But the concept is much the same. GroovyMAME proves that just a few lines modification to the current MAME source base is required to achieve perfect A/V synchronization, and this by just using the mechanisms that are *already* built in MAME. The fact is you don’t need to create a new OSD to do this.

The author of SSF has apparently moved his site over to: http://www.geocities.jp/mj3kj8o5/ssf/index.html

Anyway, I’ve read some of the posts on there in Arcadecontrols and there was already some ambivalence towards RA (and me) even before this shitstorm erupted. Things were misattributed to me to create the impression that I hate all CRT users – when I went out of my way to get a replacement CRT for my old consoles after the old one broke down. I’m just not as obsessive about CRTs as the average 4chan /vr thread. Obviously that makes me ‘bad’.

Anyway, I refrained from making comments on that forum because (just like this thread) it would just have erupted in even more clique warfare.

It’s really disappointing as hell to see how insular these emu cliques are and what the gut-level reaction is towards anything outside their clique.

All it leads to is #dev A (Calamity) defending pet project #A and then #dev B (me) defending pet project #B and then we go around in circles forever and ever about it.

I sincerely request again that we stop this shitstorm. Of course I know this will fall on deaf ears because this is the emu scene after all and time wasted arguing is far more productive than actually doing something constructive.

The problem is, as we’ve concluded, you don’t really have anything of worth to offer.

That isn’t meant to be offensive, but simply how things are. You offer LESS functionality than we have right now (no debugger support etc.) and also any versions of MAME compiled that way have an additional dependency on external software, external software that isn’t as well established as SDL we’re already using.

Any ‘killer features’ could easily be implemented in our existing code, and as already mentioned some 3rd party builds already have variations on them.

The primary platforms you target aren’t really ones that suit MAME or MAME development either, and this will always be a development focused project. I’ve reiterated the point many times in previous articles that MAME isn’t a toy for playing games, but instead a powerful application and framework for the study and development of emulation and understanding of the original systems; by offering builds that lack that (for example the debugger support missing) we would again be saying that we don’t really care about those things, again a devolution to the time when the binaries we shipped didn’t have debugger support. I don’t feel shipping such binaries does any good for our image, because it does not clearly represents the true intentions of the project, such binaries ARE essentially toys.

I see no compelling reason for MAME to be mixed with what you’re doing at all.

> The primary platforms you target aren’t really ones that suit MAME or MAME development either, and this will always be a development focused project.

RetroArch has no ‘primary platforms’ unless you are talking about PC.

Once again further proof you still have no clue about our project and/or our development process.

But that is alright, ignorance is nothing new for me at this point after having to suffer through a good dozen of your prior posts in this thread.

I’m bored of you, you’ve said you’re going away countless times, but you’re still here, go peddle your shitware somewhere else.

Goodbye.

> SDL is not an integration API and hence any comparison to SDL just shows you STILL DON’T GET IT AFTER ALL THIS TIME.

Of course SDL is an integration API. It’s arguably more of one than RA, because there’s one consistent implementation of SDL, whereas libretro emulators have to worry about if a given host implements something in a different way than retroarch does.

This thread is an embarrassment and blame should be passed around to just about all involved.

@Squarepusher: I understand your frustration when people are dismissive of libretro, especially when they seem to misunderstand a lot of the specifics, but you gain nothing from burning bridges. There’s tremendous value in diplomacy. Even if you’re proud of the “Dutch tradition of directness” as I’ve seen you say elsewhere, there are still many ways to express any thought. Some ways are much easier to digest for the person on the other end while others can leave them feeling like they’re being attacked.

@Haze/Calamity/Others: The fact that I see people almost exclusively talk about Retroarch in a discussion about the merits of targeting libretro shows that the subject hasn’t really been fully researched/considered.

When Squarepusher made reference to xbmc he wasn’t talking about a frontend within xbmc for launching Retroarch. It’s nothing like coinops. It’s a plugin within xbmc for handling libretro cores within xbmc itself and (from what i understand) it was developed independently of any Retroarch devs. They’re targeting xbmc 14.0 for its inclusion in mainline. Once that does happen, I sense you’ll be hearing more about libretro from end users. Check out http://www.youtube.com/watch?v=8viUD5WPrCA for a somewhat older video example. Development was slow for a while, but I believe it’s picked up again as of late.

And that’s just one example of a libretro based front end independent of Retroarch. There’s also ArcanFE (http://arcan-fe.com/about/) and absolutely nothing stopping anyone from making a new one if they take issue with RetroArch or its devs.

As to your concerns about it undermining support for UME, i think that’s a bit baseless. Anyone who has interest in emulation as a tool for preservation knows that MAME/MESS/UME are the go to projects. Even if you look at libretro as simply facilitating the creation of a multi-system emulator, then I fail to see how packaging together a bunch of less accurate emulators competes with UME’s goal of accurate preservation.

Even more though, libretro doesn’t just have to be just about emulators. They already have cores for tyrquake (Quake 1 source port) and prboom (doom source port). I imagine more open source engines and games will be ported to it in the future as well.

UME in Retroarch with support for multi-pass shaders would be great. Make it happen Squarepusher and Haze instead of bickering. UME and MESS will never get any popularity without something like Retroarch.

QMC2 and our HLSL shaders (or GL shaders if used on Linux) are a more solid approach and how I’d prefer people to use UME if they use a frontend.

Like I’ve mentioned above, the ‘lib’ approach encourages too much of a ‘plug in and play’ system, and will end up being implemented by frontends designed to do far more than support emulators (see the XBMC module stuff above) but therefore often fail at picking up on the more advanced use cases (instead expecting a simple launch+play system) This isn’t really how I want to encourage UME to be used and will even become less and less how MAME is used once we start adding multi-machine support etc. Such frontends work better for emulators with auto-load hacks, auto disk change hacks and the like, but that’s never really going to be how MESS/UME operate.

I feel it’s bad enough that so many people are stuck on junk like MAMEUI for similar reasons, especially when QMC2 has so much more to offer in terms of being able to make full use of our applications.

“UME and MESS will never get any popularity without something like Retroarch.”

Hahaha, the funniest joke ever.
Maybe QMC2 is too complicated for the RA-fanboys. ; )

Nonsense.

I’m not the best person to explain this, but I’ll give it a try

Libretro cores are just that, cores, they don’t handle any system specific I/O (as in the user’s system). The frontend handles I/O from the user system to the core.

The frontend will call retro_run(), the core will perform it’s functionality for one frame, call the video/audio callbacks or query input state and that’s it, then the frontend will call it again.

The frontend is free to implement support for wheels, joysticks, gamepads, keyboards, mice, lightguns, etc. Also the frontend.

Many emulation consumers, including myself, are grateful both for the work by mamedev and by retroarch. It’s unfortunate that the above debate drifted from a meaningful conclusion. It’s unfortunate to reduce the debate to which projects have a greater impact.

Everyone here knows the impact of mame and mess. It has helped create a community where other projects thrive.

Retroarch has made a great contribution by delivering a finished project to end users, including emulation of games on the slower running tablet “computers”.

If the mess developers do not wish to collaborate with Retroarch, then it would be kind to clearly explain to Squarepusher why this is. I can understand that the mess development and mission is an engineering problem in itself and it is justified by this; not by solely delivering emulated games to end users. Would it harm the mess project to pursue their own direction and offer some technical advice to SP as a courtesy?

>This isn’t really how I want to encourage UME to be used and will even become less and less how MAME is used once we start adding multi-machine support etc

You do not get to decide this, and your encouragement is unneeded.
Haze, SP has made a great frontend for people playing games.
This, despite anything you have to say, or any more crippling efforts you and the mame/mess team make will be what people are using mame/mess for. Instead of embracing something that has true potential you’ve decided that your ideals are superior to the reality of the situation.

It’s already there and working really well

> You do not get to decide this, and your encouragement is unneeded.

We get to decide what the official distribution form is, which is what started all this here, with SqP seemingly thinking I should offer libretro binaries rather than the Windows ones I currently do. (despite me having no real interest in doing so, and personally believing it to be an inferior distribution form than the one I do offer, something which has subsequently been proven by further posts made here)

As long as we retain control of the OFFICIAL distribution, we decide how the official distribution is used (or at least ensure the official distribution actually has full capabilities available) that’s kinda the point.

> Haze, SP has made a great frontend for people playing games.

and the primary goal of MAME is NOT ‘playing games’ hence having all the extra features (debugger etc.) available at all times.

> This, despite anything you have to say, or any more crippling efforts you and the mame/mess team make will be what people are using mame/mess for. Instead of embracing something that has true potential you’ve decided that your ideals are superior to the reality of the situation.

if by ‘crippling efforts’ you mean improving our emulator…

This post alone is why I feel we do need to stick to our guns, and why I feel the other approaches to be dangerous, because they encourage the type of mentality that leads to posts like this.

Documenting hardware is important mission.But general functionality which Retroarch gives is also very important.
Emulators allow people play games they would never be able play otherwise and many emulators offer superior graphical quality and resolution compared to original hardware.
But regarding UME,MAME and MESS should have never exist in the first place.Its should have been be just UME from beginning.

The problem is, as RB hints at, we totally lose control over the user experience, different implementations could behave in different ways. Poor ones with lots of missing functionality could become the most popular ones if they’re flashier than the others (which is already a problem we have with MAME32) and we’d have no say over that, it would almost seem like we were encouraging it on an even bigger scale.

I think most people offering software would agree that ensuring that every end user gets the same (and intended) experience as the development team is important, especially for a development focused project which is in continual WIP. With MAME right now we get that, sure people can slap a frontend on, but once it’s running then it’s running 100% the same code the devs run and we know that, that is good.

wow that went amazingly sideways in a most nonproductive way…

What are the ‘cool’ bits of this new version of UME?

> Haze, SP has made a great frontend for people playing games.

And so have dozens of other people. We love all the people who make non-invasive MAME/MESS frontends, and sometimes we make changes to help them out.

> Instead of embracing something that has true potential you’ve decided that your ideals are superior to the reality of the situation.

Our ideals facilitate your reality. The internet is littered with the corpses of projects that were just about playing games, but MAME is still going.

When a strange bug appears, in most cases users will report to us, after all many users never read instructions, we try to confirm or at least encourage users to test in standalone MAME.

If that’s the case they report the bug all the same.

no hate… better to know about it and I can pick up an older version if it is an issue as I am a horrible exe packrat.

Nice to see about tempest. Know that one has been outstanding for awhile. May actually motivate me to mess around with the HLSL stuff.

Also related to the HLSL stuff has anyone done any study into what each game HLSL settings should be? Right now it seems rather ad-hoc and up to users to pick what they feel looks good. The way I figure is for each game board there were probably a set of 2-3 monitors that the manufactures would ship with. Those monitors would have ‘known factory’ settings? I know as boards were moved around from cab to cab that would change. But anything? Do the devs make a stab at ‘probably right settings’ at board init?

not a toy?
>…and the primary goal of MAME is NOT ‘playing games’ hence having all the extra features
…, because they encourage the type of mentality that leads to posts like this
…Our ideals facilitate your reality.

Just because you’ve added a disclaimer and a debugger doesn’t mean that you’re no longer reverse engineering GAME MACHINES.
Absolutely abhorrent.
Who do you think you’re fooling?

You called out RA because it exploits your intentions and not your ideals. The only reason that you would call out something like RA is because it’s actually GOOD.
I’m really sorry, but:
too bad.
Go on continue crippling your project: maybe if it’s slow enough and nobody can actually enjoy it you can legitimately claim that it’s useless intellectual exercise and not about your users.

>…kids learning computers.
oh, really?
That changes everything. My mistake.
…Yeah…maybe next time you should offer up some constructive ideas instead of trashing something you consider “dangerous”

Does that make sense?

Also, if you look at the Sept 2013 entry from SqP where he talks about MAME you should probably take note of the following comments he made.

“No stupid “web server” baked in for “frontend duties”. Quite easily the most stupid decision in emu land ever this year. I didn’t even want to believe this is what they did but they did (for 0.150). Let’s just hope this won’t become ever harder to “bake out” from 0.150 and up – it is stupid shit like this that leads to projects getting forked, libav/ffmpeg-style.”

now, while I’m not yet 100% convinced of the long-term value of this feature you can’t really deny that he’s been saying negative things about MAME for long before these posts.

to call it ‘stupid shit’ on the other hand strikes me as odd, for people wanting to do remote administration / debugging of MAME (eg cabs with NO direct admin controls, it has the potential to be a very interesting feature, likewise maybe it could be expanded / repurposed to provide a webserver for actual systems in MAME / MESS (to simulate online components no longer available etc.)

That’s the thing with the project we have, and while MESS highlights it better at present you simply can’t be narrowminded with regards to our requirements, it’s far from a simple gaming system / core.

This is now the 4th username you’ve used to post from the same IP after ‘Chiyoko’, ‘Fabez’, ‘johann’ and now ‘desjardinal’ all either pro-RA shill-like posts, anti-MAME posts and now trolls. Consider yourself banned too.

As for your actual post, you’re only proving my point, I’m quite aware nobody is going to care less about playing with a Cash Register, yet we still emulate such things because this isn’t a project about ‘games for people to play’ it’s a project about emulation development.

Also thanks for even further lowering my opinion of RA / LR users.

People who are wrong are just as sure you are wrong as you are sure they are wrong. The only difference is, they’re wrong. ; )

Yup. The full power of the web interface isn’t realized yet, but it could indeed also be used as the basis of emulating e.g. online high score servers that no longer exist and stuff of that nature.

> We have multiple working synthesizers and a working drum machine in MESS as well.

oh really, I didn’t know .
nice to learn that MESS emulate synthesizers.
thanks for the info. i will try it !

but how to know what are the synthesizer that mess emulate ?

anyways must sound better than a cash register :)

The register from “Pink Floyd – Money”…

Oh snap. :D

Squarepusher is having so much fun using Protocol IP, Proxy Servers or using Tor. :D

> but how to know what are the synthesizer that mess emulate ?

the complete list of systems emulated by MESS in 0.153 can be found at ProjectMESS, as usual

http://www.progettoemma.net/mess/sysset.php

sudopinion is not Squarepusher, sudopinion is a retroarch user and the developer of this tool: http://code.google.com/p/rom-jacket/

I can’t actually remember, but I think it’s something Micko submitted last year or the year before? Might not be in a working state yet.

Just my curiosity at work here… but I have been wondering a lot:

1. How are games selected to emulate (or not) or is it just any and all games that we have PCB access to? Is there some sort of priority system? I know it’s been stated that popularity/demand has 0 to do with it.

2. How is it determined which games should be worked on to improve emulation? Again, just curious what makes a game “due” for work on the emulation quality vs leaving it sit for a few years.

And yes, this is a veiled attempt to figure out if there is any way we will see improved CAVE SH3 emulation (to better match PCB performance/slowdown) now that the games are back in 153.

typically, whenever we a PCB is dumped (and we know about it), we try to at least document the dump by adding what is called a “skeleton driver” (typically only documenting what we know from the dumper: which chips are on the PCB, what is the layout etc)
if the dump runs on known hardware or if any of the developer is familiar with the CPUs present on the PCB, we try also to implement some further components, so to be able to verify whether the dump is correct or not (bad bits due to bitrot, mistakes in the dump, missing parts, etc.)

about determining which games should be worked on, there is nobody deciding anything. each dev works on what he finds interesting at a given moment (because he’s interested in the game, because the hardware represents a challenge he feels interesting or just because he’s bored and he wants to see if he can figure out anything he might have missed in the past). if he obtains any advance, he submits the code. that’s all :)

nice !
thanks you for the detailed answer
i will try this weekend, should works fine with my edirol pcr usb keyboard.

Hello,
I will be posting only here once, as I don’t want to cause a fight and actually don’t want trouble. I see both sides of the fence, but one thing bothers me:

>While they move emulation forward with their >focus on accuracy and writing their own cores, all >RetroArch does is glue a bunch of emulators >together which really does not do absolutely >anything for the emulation scene as a whole >except provide a more convenient way to play >games.

RetroArch is suited towards developers and such that don’t want to bother about reinventing the wheel when it comes to a OSD layer/framework. It is in no way opposition to MAME/MESS’s goals. Of course developers are fine to reimplement their own CPU cores as they see fit (if they make an emulator core), as libretro seems to me to be just a API for developers to interface with, nothing more. Its not really intended for emulation at all. Emulation is just one subset of the things it can handle.

wow, I did not know that they were releasing their API as GPL and then pretend to forbid commercial usage :o

it sounds like somebody did not read carefully the license they were adopting…

Just for clarification, the libretro API is actually under the MIT license and not GPL:
https://github.com/libretro/RetroArch/blob/master/libretro.h
Please inform yourself before spreading false information.