Is MAME going downhill?

[DNA Dan]

Perhaps with all the success of MAME and the lack of new things to fix, MAME just lacks a real goal anymore.

Then again perhaps it's more a reflection of ourselves. That we've all played these games over and over so many times we just wish there were more to the story?

[RayB]

So maybe the RIGHT question we should be asking is, how can we get MAME into more aerodynamic clothes?

Or Haze could just shave his legs.

[torino]

It's my understanding that the decision to convert mame to c++, for example, was to make mame easier to debug and compile.  It is, btw, much easier. 

C++ does not make it easier to compile or debug, it's rather the opposite. The only thing that is easier about C++ is to misuse it.

Right now mame is trying to address the fact that it's code is very old and things need to be tweaked/changed so that the source doesn't become some cobbled together dinosaur.  That kind of transition is slow and painful and it happens every few years. 

You only need one good programmer and several months, or extraordinarily good organization and management of many wannabe programmers, and still a single good developer would have a better chance to do it faster and better than 50 average developers, especially if they are not organized and there is no any actual discussion going as to what to do and how to do it.


The first thing they have to do is to isolate game drivers from the main emulator engine, so no one needs to fiddle around core functionality in order to include any new game or fix something in already supported game, and fear some other game might stop working because of it.

[danny_galaga]

Do the BYOAC users on this board have a version of Mame they just stick to?  If so why?

78 for me. It does most of what I want, and it's too much bother mucking around with ROMs all over again. I suspect that is the reason most people stick with the version they are first happy with- updating ROMs.

[danny_galaga]

The reason for the post regarding the downhill part, is to figure out where arcade emulation is going.

Why? Are you writing a dissertation on it? What's it matter to you where it's going?

Nice to notice.  I am writing my dissertation on emulation. 

I think the better question: Is MAME going uphill?  Its a lot harder to go uphill.  Especially on a bike.  Lets think about that.  What is the metaphorical bike in this struggle? Why can't we get to the top of the mountain?  And who is peddling that bike?  And why, for Pete's sake are we peddling the bike when we could just jump off and walk it up the hill?  How many speeds are on this bike?  Is our clothing aerodynamic enough?  This is a big deal, you ever see bikers, even casual weekend warrior ones, it appears that aerodynamic clothing is a big deal.  So maybe the RIGHT question we should be asking is, how can we get MAME into more aerodynamic clothes?

Nice comment, but uphill was the first 10 years of Mame, as all the hard stuff has been done, the next 10 is all down hill.

Ethan Tremblay: My father always had a saying "When a day starts like this it's all uphill from here.
Peter Highman: Uphill? No, it's all downhill from here.
Ethan Tremblay: But nobody wants to be down, everybody wants to be up. It's all uphill from here.
Peter Highman: But it's easier to go downhill. So your dad had no idea what the ---fudgesicle--- he was talking about.

[torino]

You have a situation where people are looking backwards for a usable version, rather than looking forward.

That's it. But do you see it's not logical? The meaning of that sentence really begs the question: Is MAME going downhill? And if you are right, if your statement is correct, then it actually answers that question with "yes".

Progress and evolution is when things become consequently better and you look forward for the next iteration to see improvement, but when you need to look backwards to find "better", then you are obviously looking at what is called digress and devolution, or plainly said "going downhill". It's plain logic really, so the only question that remains is whether your statement is indeed true, and I think it is, it's certainly true for me. However, I also agree with you that this is not directly caused by "wrong" actions, it's more about the lack of right changes and reluctance or inability to make important decisions.

[Grasshopper]

C++ does not make it easier to compile or debug, it's rather the opposite. The only thing that is easier about C++ is to misuse it.

Agreed. C++ is a truly horrible incoherent bloated mess of a language.

If you want maximum portability and readability combined with speed then I still think it's best to stick with pure C, making sure your code conforms rigidly to the C89 standard. The C99 standard (which isn't properly supported by most compilers) introduced a lot of pointless bloat without adding significantly to the power of the language.

[gabe]

It's the circle of life.

[Haze]

The first thing they have to do is to isolate game drivers from the main emulator engine, so no one needs to fiddle around core functionality in order to include any new game or fix something in already supported game, and fear some other game might stop working because of it.

At the risk of replying to this nonsense.

Yes, MAME is going 'downhill' in the sense that it's getting worse (it's not however 'on the downhill straight' by a long stretch, there is a lot of hard work to do but also plenty of easy stuff which is simply being overlooked)  The reasons are varied, some of them built on sound logic, others complete nonsense.

The statement above makes absolutely no sense tho.

Each and every game board MAME, or MESS emulates is a bunch of off-the-shelf components in some cases mixed with custom chips for video / sound.  Take for example the YM3812 sound chip.  Emulation of this is in common, shared files, there is one copy of the emulation, shared by (according to MAWS) 404 different individual game boards.  Using a CPU as an example instead, the Z80, used by 4945 drivers.  M68000, 3175 drivers.

Of course there is going to be a risk of breaking one of those games if a fix is made to one of those cores, but the alternative would be to duplicate the sound core 404 times, once for each individual game, just to ensure that no chances could possibly affect anything other than the game being fixed.  That would be insanity to say the least.

Each of those emulation cores also often relies on common core implementations of other components.  There is the timer system, used to emulate accurate timing in the core, to schedule future events, run the CPUs for the correct amount of time etc.  Practically every core component in MAME depends on this, so again, if that were to be broken by a change, the fallout would be large, but likewise the alternative would be for each and every core to have it's own implementation of exactly the same thing.

Every component MAME emulates is like that.  Some of these chips were used thousands of times, some only once.

MAME drivers simply link components together in the correct configurations and provide the board-specific glue-logic needed in order for them to work therefore to isolate the drivers from the core would be to strip away the very emulation of the common chips the boards needed to operate.  How well does your Donkey Kong board work if you isolate it from all of the mass-produced CPUs, IO chips etc?

Right now a simple MAME driver can be a handful of lines of code, making drivers completely independent of the core yet still functional would result in an individual driver being several hundred KB of code which in the majority of cases would have been just copy+pasted from somewhere else.  You'd have no idea which implementation of any given component was actually the best with 4000 of them copy+pasted with slightly different hacks applied all over the place.  By simply merging the implementation of 16-bit Data East chips recently I was able to fix a number of long-standing bugs in things like Tattoo Assassins simply because the driver had previously been relying on an old copy+pasted implementation which hadn't been updated with the latest findings and thus was simply rotting; that's what happens if you're carrying duplicated code all over the place.

As I said, there are reasons things are getting worse, but that's not one of them.  Tighter sharing of component emulations, reuse of common implementations is hugely beneficial to the overall emulation quality even if it does incur the risk of things getting broken when common code is changed (which is a good indication that your changes are wrong, and thus useful to know)

The main argument thrown forward by the few remaining members of the team is that every left is just too hard.  This is something of a fallacy, or they're simply completely incompetent at actually writing *emulation* code these days.  Things like the Namco cocktail modes should be the most simple of fixes yet are completely overlooked, likewise broken save states, liable to cause MAME to simply crash on one of the most common sound chips doesn't help matters at all, but nobody looks at it.  I can't be bothered with fixing this kind of thing for them anymore.  There are also other systems which people have shown are nowhere near impossible to emulate (Model 2 for instance) which simply sit in a state of disarray in MAME.

[torino]

At the risk of replying to this nonsense.

Your blabbering is nonsense as it has nothing to do with what I said.

I was referring to "main emulator engine" and you are talking about "CPU cores".

I'm talking about host platform stuff, like control input and audio/video output handling.

[Haze]

At the risk of replying to this nonsense.

Your blabbering is nonsense as it has nothing to do with what I said.

I was referring to "main emulator engine" and you are talking about "CPU cores".

I'm talking about host platform stuff, like control input and audio/video output handling.

and I can't remember a single time a host platform related fix made for a specific game broke anything related to the actual emulation drivers.  Host platform fixes aren't made for specific games (and anybody attempting to fix an individual game bug by hacking such things would be pointed at and laughed at).  The two things are ALREADY isolated.  The actual OSD stuff is lightweight and portable.

If the OSD code is broken (which in the case of the HLSL stuff, it is, many games with dynamic resolutions fail) then it should be fixed, but nothing game specific lives there.

The most common cause (99%) of 'fix for game X breaking game Y' (your complaint) is the one I mentioned.  This is unavoidable, but as long as the breakage is dealt with, is actually a good thing.  If you want to misattribute the reasons for these breakages as OSD / host platform related that's where you're going wrong.

[ark_ader]

At the risk of replying to this nonsense.

Your blabbering is nonsense as it has nothing to do with what I said.

I was referring to "main emulator engine" and you are talking about "CPU cores".

I'm talking about host platform stuff, like control input and audio/video output handling.

and I can't remember a single time a host platform related fix made for a specific game broke anything related to the actual emulation drivers.  Host platform fixes aren't made for specific games (and anybody attempting to fix an individual game bug by hacking such things would be pointed at and laughed at).  The two things are ALREADY isolated.  The actual OSD stuff is lightweight and portable.

If the OSD code is broken (which in the case of the HLSL stuff, it is, many games with dynamic resolutions fail) then it should be fixed, but nothing game specific lives there.

The most common cause (99%) of 'fix for game X breaking game Y' (your complaint) is the one I mentioned.  This is unavoidable, but as long as the breakage is dealt with, is actually a good thing.

Ignore Torino.  He made me delete all my 720 roms from my collection.

Get the Mame project back under your leadership, and get rid of all those Mahjong kiddies.  I would be a shame to see Mame losing its focus with all this visual crap.  Playing the games was just a nice side effect , right?

Every release I see less and less, which should equate to more and more fixes.

[yotsuya]

Ignore Torino.  He made me delete all my 720 roms from my collection.

Get the Mame project back under your leadership, and get rid of all those Mahjong kiddies.  I would be a shame to see Mame losing its focus with all this visual crap.  Playing the games was just a nice side effect , right?

Every release I see less and less, which should equate to more and more fixes.

Interestingly enough, I can't even COMPILE Mame anymore since they introcused the HLSL stuff. It crashes on me, even though my video card has the latest drivers for it.

[ark_ader]

Ignore Torino.  He made me delete all my 720 roms from my collection.

Get the Mame project back under your leadership, and get rid of all those Mahjong kiddies.  I would be a shame to see Mame losing its focus with all this visual crap.  Playing the games was just a nice side effect , right?

Every release I see less and less, which should equate to more and more fixes.

Interestingly enough, I can't even COMPILE Mame anymore since they introcused the HLSL stuff. It crashes on me, even though my video card has the latest drivers for it.

I'm tripping the light fantastique with Mr Belmont on this very subject.  I like that guy. He has a wonderful sense of humor.

[torino]

Haze, at least we agree there.

I suppose I should now look into mametesters bugs database to find evidence and attempt to prove my point?


Can you tell me what's with "discrete audio" re-write? Why not keep such major re-writes separated until perfected and properly tested? Aren't such bugs too big and obvious to be released in public as official build, what's the hurry? I read too many complaints how games suddenly stop working as new releases come out and it's shame people have to roll-back to older builds. That simply does not fit the description of "progress", and it could be avoided even while constantly messing around CPU cores, with tighter organisation, more communication and better programmers.