The heroes of old you refer to helped mame to be what it is today.
The current team seem to be maintainers and tinkerers than the hardcore coders of late.
I am not including the usual suspects of the team.
I feel nothing but embarassment for your comment towards those coders you tend to ignore.
If you're talking about the arcade devs then the topic was preservation, I'm not saying they didn't contribute towards making the games. I said they're not contributing towards preserving them. They're not.
If you honestly think that MAME isn't 'hardcore' then you're wrong. Having talked to people, in person, who also programmed during that era they are impressed by the sheer scale and complexity of modern systems.
Even if you talk to the old people who worked on MAME they're impressed by the scale of things, and attention to detail. It's done things they never imagined possible, it's done things even I never imagined possible. Each generation has to pay more and more attention to details, get things right, understand things in even more detail to remove hacks. There is some absolutely amazing stuff in MAME, that's been figured out! Every now and again we'll manage to remove some little kludge or hack that the old devs put in and get a 'wow, so that's how it worked' comment, the understanding of arcade hardware has come a long way since then, hence many drivers seeing near complete rewrites. Each generation is doing things the previous one deemed 'impossible'.
The hardcore coders of old were mostly the demoscene coders on the likes of the Amiga, not the arcade coders; if anything the arcade coders had it easy because much more money was being pumped into arcades and technology, it was always ahead of the consoles and computers at the time which meant they COULD be a lot more lax with the coding. There are VERY few arcade games that come close to pushing what the hardware they run on can do, most are actually incredibly lazy uses of the technology because cost wasn't much of an issue. Likewise most of the technology wasn't even around for long enough for them to start pushing it, or coding to it's strengths.
The people writing Speccy code, Amiga code, SNES, Megadrive code, PSX code etc, had far heavier constraints put on them, they couldn't just ask for better hardware, they had to work with what they had. That's why you find games pushing the boundaries of the hardware, exploiting every little trick in the book, and using some REALLY hardcore techniques. You disassemble some of those games, or look at how they made use of the hardware from a technical point of view, and have to admire it. I can't say I've honestly seen the same in any single arcade title. This is also reflected in my earlier statement that the MESS side of things provides a better component stress test than MAME. Arcade -> Console ports might have been for the most part garbage, but there were generations between the systems at the time.
Unfortunately this type of 'hardcore' programmer isn't much good for MAME coding*, these guys pushed hardware, hacked things up to give an illusion under very specific conditions etc. etc. which aren't actually useful skills for creating an emulator. You don't want 'hardcore' code of that kind in an emulator, you want reliable, readable code! MAME is a different kind of 'hardcore' in that it demands correct code, and correct understanding of everything. We did allow this kind of code in areas of MAME a long time ago, and it set the project back years, look up 'AchoCode'. It's a prime example of why the fast type of 'hardcore' code should be kept as far away from MAME as humanly possible, no error checking on anything, prone to crashing, hardcoded for specific cases, unmaintainable and the cause of many bug reports where his code simply fell apart when new use cases showed up. (*ones who will write test code on real hardware are useful for figuring things out tho when the actual game code we have doesn't supply enough evidence)
Old projects were smaller, original ideas could sell, the industry was more open, and there was little risk in trying things, the scope of the approximations you needed, was more defined, expectations were entirely different. These things more than made up for the constraints imposed by the hardware. I've programmed for the 8-bits, I've programmed for modern systems. Again the same comparisons can be made with MAME, the old versions of MAME you didn't have to care so much about accuracy, it's been said before, 95% of the effort is making the last 5% of the software work for any emulation platform / fixing the emulation bugs for any given platform. You could write cores and video emulations that 'mostly worked' You could write quick dirty multi-pass sprite code that caused additional glitches in the games, and nobody noticed. The old versions in almost all cases do not represent good QUALITY emulation, because understanding has moved on since then. They were good for the time, even impressive, because there was nothing better, and that was the limit of the understanding at the time.
Let's take a real example I've used before.
http://mamedev.org/source/src/mame/video/twincobr.c.htmlThis is a 'classic' MAME video implementation of old.
The function starting at line 379
379 static void wardner_sprite_priority_hack(running_machine *machine)
nice little hack that. Why is it there? because at the time nobody understood that sprite->sprite priority should not be affected by sprite->tile priority. Implementing it PROPERLY, without this hack makes the driver 2x slower because you have to have a priority buffer for every pixel of the screen, rather than the quick and dirty approach being used. It's also significantly harder to code properly, than simply hacking it as has been done here. The final code is much more elegant however, and will work for ALL cases on this hardware, not just the specific one hacked here.
There are still many drivers which take such an approach, they don't always have hacks to hide the glitches, some glitches people have never reported / noticed, however, it's now up to the current team to actually PROPERLY understand these things and replace them with correct code. Obviously these hacks aren't desirable, but that was the limit of the understanding back then, from a developer perspective it was 'huh, this doesn't make sense, WTF is going on??' Cleaning these things up is hard work, it has no 'rewards' apart from much cleaned code, people only moan that things got slower. Are they worth cleaning up? Of course.
You're quick to insult Derrek here. Do you think holding a microphone up to an arcade cab and playing a few sounds in test mode then playing back the wavs is more of a hardcore task than trying to figure out how the PCB generated them from the circuits, and writing the code to accurately reproduce that? It's a perfect example of how expectations have changed, evolved, and how actually getting things from a crude approximation to perfect is so much more work than the initial coding. He's doing things the original development team could only DREAM of being able to do, part of that is because the technology is available to do it now (it simply wasn't feasible on a P2/P3) and part of it is because he simply has skills the original team didn't have to actually figure these things out and code them.
If you want to twist my words into some kind of insult that's your problem. Time change, you are stuck in the past, and you seem to fail to recognize the amount of hard work being done today, simply because the real hard work of doing things properly has less 'rewards'. At the same time people here are also very quick to bash the devs of old, saying they lacked foresight. Maybe you should make up your mind, or just realise that it's a project which is always evolving and building on what came before it.
As for my statement that the names don't matter much? I don't think they do, people working on MAME should be working on it because they think it's an important cause, the good feeling comes from knowing you've achieved something worthwhile. I do a ton of work for every release behind the scenes, and don't ask to be credited for most of it. If I have something I think other people will find interesting, or I find curious, I post it on my site for discussion, not for fame.