shmups.system11.org

MAME was one of the FIRST emulators to allow you to do this, as I pushed to have the option back in the day. It's right there, if you enable cheats (which as I've already said, is the catchall for this kind of thing) It doesn't save because it tends to actually break things quite badly and we'd rather not have people boot up with broken options from previous experiments. People made a big deal with Bsnes did this a year or so back, but people were doing it with MAME in the 90s.

It was also one of the first emulators in which people did fake hi-res modes (there was a hi-res NeoGeo hack so that the zoomed backgrounds in SamSho didn't lose detail etc.) of course that stuff was never integrated because it was gross. Amusingly people mostly rejected that idea back in the day.

As for input lag, MAME started ignoring the scene complaining about it when the scene complaining about it started making various false claims about the level of lag on certain PCBs. It became a toxic scene so MAME tuned out completely (people were sending me close to death threats for adding sprite buffers in certain drivers that were hardware verified) The gross hackery shmupMAME did, and now other stuff like RA is doing really ensure nobody serious wants to touch it at all these days. If GroovyMAME works, great, but afaik that's still doing some risky stuff.

A haiku:

There was input lag.
The devs blamed all the players:
"It's not our problem!"

- BKR

So even within this scene, when we actually improve things there is going to be conflict.

Good to know....

This is kinda what I mean tho, whatever we do, somebody is going to be unhappy with it, even when it's objectively the right thing to do. Emulation developers get a disproportional amount of hate considering practically all they do is give.

So instead of realizing that certain people are obviously out of their minds, you legitimize their behavior and use it as an excuse to do nothing, and also use it as an excuse to misconstrue what people are trying to tell you.

Instead of painting huge groups of people with the same brush, how about read what they're trying to tell you and apply some common sense? The overly hostile way you treat users only leads to users (and non-users!) treating you overly hostile right back. This cannot continue... you'll destroy each other eventually.


Which I am well aware of, as I use it to get certain older games on questionable hardware (Final Star Force) in an actually playable state.

You just said you wanted to take this power away from people for newer CAVE games, and the way you phrased it made it sound like you were trying to do it out of spite. Everything about how MAMEDEV communicates sounds like they always want to be so spiteful to users. Since this is something that comes up so much in programming (long before they get irate users whining at them about stupid nonsense), it's not surprising or unusual to point out.

That's what I'm concerned about. I'm especially concerned because it always seemed like you understood the problems with MAMEDEV and you wanted to distance yourself from them to an extent.

People create conflict because they enjoy conflict. That's not new or interesting. It's definitely not interesting, it actually really gets old after a while, and it makes it very difficult to bring forward and solve real problems. See: politics.

Whew, complaining about not being able to cheat... Shakin my head guys.


I'd at least prefer if people were simply willing to admit that they're playing a different game. Different rules; different game. Sadly, they don't always do this.

I mean, as it stands even the cheat plugin is supported better than autofire in MAME...

nice bait

I said that once the blitter delays are fully emulated the option to run them without the blitter delays being emulated won't be there.

That has nothing to do with CPU overclocking, you could change the CPU to 10000% and the blitter would still slow it down by the same amount as it's a fixed period of time depending on what it has to blit, unrelated to the CPU. Yes, the CPU waits in a loop for the blitter to finish, which means the CPU is 'busier' in blit heavy situations, but if a blit takes more than 1/60th, or even 5/60ths of a frame, the CPU is still going to be sat there waiting for more than a frame regardless of how fast it is running.

There are zero instances where MAME provides configurable blitter speeds once the correct speeds are known, and Cave wouldn't become a special case. Cleaning up the ugly hacky code that's in there right now (because the correct values aren't known) would be considered a priority once the correct details are known.

This isn't out of spite. Don't read into things that aren't there.

I'm going to try to defend RA's run-ahead feature, please bear with me.

I used to own real hardware. Real consoles, controllers, software, and CRT displays. I remember what it felt like to play those games, and emulators by-and-large do not replicate that experience due to various factors introducing input delay. Those are from operating system, graphics drivers, USB polling, and the nature of LCD/LED monitors. Those simply cannot be addressed without sweeping, industry-wide changes in architecture and programming (although I've read that adaptive sync monitors and Vulkan drivers are addressing some of this). Without drastic measures such that RA (and GGPO games) took, there is no way anyone is going to make an emulator that looks as smooth and feels as good to play as their original counterparts on a CRT. Run-ahead (as well as their Hard GPU Sync feature) simply makes up for the inherent lag in the most common of today's computer systems plus the penalty from Vsync. It doesn't make it better than original hardware. If you set the RA frames too high, you'll start seeing weird shit with sprite movement. For what it's worth, I never liked how ShmupMAME would make the sprite layers seem off.

I'll always recommend RA on a suitable PC for the best possible non-arcade emulation experience, despite their atrocious UI. Even with arcade games, their core of FBA runs far more things than I expected it to, far better than I expected it to, and with far better input response than standalone MAME. It's not exactly on-par with it in most aspects, though.

That's not to say I don't like what you've done and are proposing with MAME's plug-in system. I think that is the best solution for the topic at hand.

The problem is the point at which you start seeing movement isn't the point at which you've exceeded the original limit.

A lot of original hardware has 2, sometimes 3 frames of buffering for all video, some 2 or 3 from IO MCUs or the like. You can end up killing that off with the runahead without even realising it, without seeing any glitches. At least with shmupMAME you got ugly glitches due to the way it hacked code, so you could tell people were using it in most cases.

Then a whole bunch of people will swear blind the original hardware doesn't have that buffering, even if it does, even if we can show them the RAM on the PCB that is adding those buffers, or in some (none-automatic cases) the triggers in the program code that is doing a DMA that they're now using time travel save states to bypass. Insisting they have the right to get rid of that delay and still compete, the delay that really is there on a PCB.

RA, as a result, has utterly destroyed any concept of high score runs on emulators, because people will use it, maybe even unknowingly, and be getting less than PCB lag times, and games that no longer play as they were originally balanced. We've already seen enough people claiming otherwise and defending the feature to know this is a legitimate problem.

That's the problem, it's an irresponsible feature that now sets completely unrealistic expectations for people doing it correctly. As I said, I got what were messages that basically read as ill concealed death threats for simply adding a single frame buffer people didn't think should be there in MAME drivers. Putting people back on the right track, even once proper solutions are available (if anybody bothers to develop them now) is going to be a horror show now that this is the 'norm'

I'm sorry, but if a feature has the potential for such consequences then it shouldn't be implemented, but the RA devs are all about implementing things they know will have deeper negative side-effects on communities and really not caring, because they know they can create enough hype, and enough people saying those features are amazing that it will boost their popularity due to the features, on the surface, looking good. I've said before, and I'll say it again, LR / RA is parasitic.

Again you can say MAME is user hostile for not wanting this, but I'd argue that MAME instead has just acted in a much more responsible manner, it would have been selfish of us in the long run to add such a feature due to the damage it causes. At least right now if somebody is running a proper version of MAME you know for sure they're not using that kind of cheat. I'll admit, yes, with the inherent lag you get from emulation you are at a slight disadvantage instead, but better that, while working on a proper solution (which would have arrived in time) than the mess that has now irreversibly been created.

lol at "implementing irresponsible features". runahead isn't the nuclear bomb dude

Well it has a similar effect on the legitimacy of the emulation high score community.

I consider that pretty damn irresponsible, and highly selfish to implement.

the legitimacy of high scores in videogames has always been on an honor system, especially in "unofficial" settings. it's ridiculously easy to cheat informal online leaderboards and runahead does nothing to change that fact. leaderboards that don't allow runahead (or any other feature for that matter) should specify as such and the best they can do outside of catching really obvious cheats is assume that players won't be shitheads

All this little exchange has shown me is that Haze has actually started drinking the Kool-Aid® that he tried to warn everyone about. Great. I'm pretty sure you only have one or two examples of people genuinely getting angry over "supposed" added input lag, but carry on, yes.

By the way, you can absolutely do hijinks with blitters just as much as you could with CPU overclocking... why wouldn't you be able to? There not being any cases of allowing this sounds like proof of a problem that needs to be fixed, not proof of an orderly system.

Let me rephrase what I said earlier in a way that might be more directly repulsive to you: allowing the user to manipulate hardware characteristics, and being able to do things like overclock hardware performance or remove sprite limitations, is as inherently good as emulating the hardware exactly. These two things basically need each other. You might not see that now, but you will eventually. Might as well get started early though!

Let's be real. This isn't just about autofire. This is about all the genuinely great things MAME could do, but that MAMEDEV does not personally want to do, even if it would help them far more than it would ever hurt. It's funny because this is the whole point behind FOSS. Doubly funny because abusing this fact is why FOSS culture as a whole is in the sorry state it's in.

Also the real takeaway here is that fruit machines are supposed to more important than proper autofire support, because one is "real" and the other is a "bootleg". Just saying.

For what it's worth, I do not agree with BKR's writeup at the beginning of the thread. Playing certain games without autofire should still be respected. People repeatedly try to bring up CTS when that only occurs because of everything else: terrible posture, not taking breaks like you should be doing when engaging with anything for a long period of time, etc.

Even if it is, does that mean they have to go out of their way to implement it? Especially when RetroArch is already doing it and there are bound to be spinoff projects that add them?

Even byuu admitted that inaccurate emulators had their place. Though I seem to recall higan becoming a far more accurate emulator after he stopped trying to please everyone.

The Dolphin team also claims to have made far more progress after abandoning plugins and actually focusing on reproducing the behavior of the hardware. And you're delusional if you think the plugin hell days of PlayStation emulation are at all preferable to what Mednafen helped make possible today.

Somebody else will make a(nother) MAME build with autofire if the interest is there, the same way RetroArch made Beetle-PSX-HW and the same way there seem to be random emulator frontend projects popping up every other week.

If we're being 100% honest with ourselves emulation high scores are all illegitimate. Or at least not even really comparable to each other except in the most controlled circumstances. There's too many variables between PC setups. We're all playing with different response time impediments due to multiple external factors. Yet we just ignore those because it would be too much of a pain to deal with.

I don't see how something like run-ahead is an affront to the 'legitimacy of the emulation high score community' but save states aren't. I guess it's because save states have a development-related use so they aren't irresponsible and selfish to implement? (and yes, there are people in this very community that think ANY use of save states, even to practice a boss basically mean you are some sort of a dirty cheater, even if your "real runs" are done without save states).

Like the guy above said, this is all honor system anyways. There are ALREADY a multitude of features that can be misused, and probably are on a regular basis. I can get thinking that something like run-ahead is disgusting, fragile hack (because it pretty much is). I can even understand how lots of mamedevs feel towards libretro/RA due to their inclusion of some janky as fuck old versions of mame. But man, I can't really get behind something like run-ahead being the bridge too far in the realm of irresponsible features to implement. That's just absurd considering what's already possible. We've been dealing with people using all sorts of emulator features to cheat/get an advantage for decades. This isn't any different.

All I'm seeing is

"Attempt to do right by a community by not doing something that could be damaging" *get attacked for not doing it by parts of the community that don't care about the dmaage*

"Don't go out of our way to please a community but instead work on what we care about" *get attacked for doing what we want by the parts of the community that would rather something else had priority*

"Hand power to the community so they can create / maintain things for their own niche" *gets attacked for not treating it as 'first class citizen' by those that don't want the power but instead want the developers to do everything for them*

"Listen to one section of a community and implement what they ask for the way they ask for" *get attacked by the rest who didn't want it that way but some other way instead*

and you wonder why I just end up concluding that the scene is toxic, and we should just tune out and get on with doing things our way. Attempt to explain why and provide some rationale for our choices, and even then we have to put up with insults for daring to try and show a public face because it isn't what people wanted to hear and because opinions aren't going to be simply flipped on their head based on a few comments on one forum. Meanwhile, there are others praising those same decisions. There's no "Kool-Aid" involved here, just developers getting on with the things they care about while becoming ever distant from a scene where it's quite clear they can't do right by everybody no matter what they do so simply default to their own moral compass and take personal reward from overcoming the technical challenges involved.

I see this has also now descended into attacking the decision to want to emulate fruit machines. So predictable how these threads go, use anything you don't personally like to try and discredit the decision making skills of those doing the work. In that case, sure, people have also been put off working on them in MAME because they don't want to work on something they're going to be hated for working on so give yourselves a pat on the back? Those people haven't actually contributed anything else tho, the hate being spread has simply stopped MAME from improving.

I'm not even one to always agree with the decisions made by MAME as a whole, but things like this aren't even a constructive means to an end. Right now the project has struck a good balance of when to listen, and when not to listen, when to be stubborn and when not to be, and I'll happily praise it for that as I can see just from the current development patterns that things are working well, while that hasn't always been the case. I've tried to highlight to you how the project has moved to be more in your favour, with things like the plugin system, but I guess I've ultimately failed to communicate that in a way you find satisfactory here. I've also expressed why MAME isn't really interested in doing things that would be damaging to the community, but again, seem to have failed to express that in a way that everybody is going to accept.

As cranky as it makes me when a quite old game I like can no longer run properly on some older CPU of mine because the MAME team suddenly jacks up its system requirements, for what it's worth I think their dedication to accuracy and archiving is admirable.

Though emulating video gambling machines does seem marginally outside the idea of "arcade game".

This discussion indeed is toxic. I am astonished that you even bothered to communicate to these obvious idiot trolls. You owe them nothing, you own them no explanation or anything, they don't own or your work or your time. Anyone who is not happy with Mame is welcome to come up with their own emulator.

I have used Mame since it first appeared in the mid 90's, and I have always appreciated it for what it is - to sample and try out arcade games I have no access to, but I rather play PCB's or console conversions if I want to play for high score. In my mind this whole conversation is absurd. Just a bunch of self-entitled spoiled rotten kids screaming for free service they think they are entitled to. Ugh.

1. The MAME-MESS merger is old news. So now MAME is (among other things) also the only usable FM Towns emulator other than UNZ. In fact, despite persistent issues with compatibility and the driver not actually 'working' yet, it may already be better than UNZ simply by not requiring you to mount CDs to a virtual drive.
2. Going off the American and European definition of arcade games as time-wasting quarter-munchers, Gauntlet and Defender have nothing on one-armed bandits.

damn, I forgot that if something is free then all criticism of it is invalid. stupid me

there's a line between criticism and abuse.

usually when this nugget is dragged out and thrown at FOSS projects it's to justify the latter. see those who always cry 'freedom of speech' to justify hate crime also.

sometimes it's important to respect those making the decisions, and maybe try to understand why those decisions have been taken etc.

you've had the reasoning behind the current state, and most likely future direction of the things you're asking about explained, that is what the thread was about.

frankly, if you ask me, the project is already going far too out of it's way for this kind of use case as it if of no technical / developmental benefit, but some middle ground was found, compromises were already made, effort was made to accommodate you; MAME has bent over so far to NOT be user hostile, it's ridiculous when people start screaming that it is, on the handful of things where we choose not to.

the most likely outcome of continued abuse is that one day MAME will just throw the towel in, trash the OSD layer entirely and become nothing but a crippled RetroArch core, which would be devastating. It would severely limit what the project could actually do well in many other areas, provide a degraded user experience, and a _significantly_ worse development environment but might actually be the only way to get people off our backs. (although honestly, at that point MAME would be dead, I don't think it would recover, the development experience would be too bad)

I'm legit sorry that you've received death threats over stuff you've done in MAME, no one deserves that shit. But I don't think anything anyone's said in this thread in particular constitutes "abuse".

Maybe not in this specific thread yet, although some of the insults are heading in that direction, and usually that's where these threads end up at the point where people aren't happy with the answers.

I mean I get it, some people are passionate about the games, we're more passionate about the technical side of everything; hardware as a bunch of circuits and custom chips with specific purposes, software as a bunch of interwoven code and data and a position in a history book showing how all the dots join together. There is very little interest in the frills on top of that. As I've said a few times, this is why things are being pushed more to the community for that side of what is being offered; we're not going to do a good job of it, I'll be the first to admit that, a well organized community on the other hand can do amazing things (look at the quality of the external artwork being made for the recent Game+Watch emulations for example, they're night and day compared to the base offering)

user-hostile design

The opposite of "user-friendly" design, it defines the likely product of design work that does not include continual involvement of users in the requirements and design process.

I get that you are clearly and obviously totally unaware/clueless about the current status quo of how actual players play these games (and you're posting in a forum where the community consists of active arcade game players). Stupid people saying shitty things to you is indeed shitty and death threats are not excusable, but some people behaving badly towards you does not automatically mean you get to use it as an excuse to shield you from any and all legitimate criticisms of failings in your project.

But hey, silly us for having the audacity to want to use an emulator to play games I guess.



It's not that I disrespect people who choose not to use autofire; it's that I feel that games should be as widely accessible as possible, and there are a lot of shmups out there that are simply not accessible to a wide audience without autofire. As stated, a lot of scoreboard go by the honor system and respect if you mark autofire ON or OFF in the score. Not everyone will have the luxury of being able to own/afford an arcade stick to play these games nor will everyone be able to own the fanciest top-of-the line sync monitors. And as it stands, these games are quite playable and enjoyable even on sub-optimal equipment like a lower end LCD monitor, so why not make the controls as accessible as possible? It's widely recognized that a lot of arcade shmups demanded strenuous game-long mashing. Button mashing is also an issue is for people with arthritis, etc; it's simply not a mechanic with any central appeal, and I've yet to hear someone say "this game is great because it has lots of button mashing!".

It's the same reason why I'm fundamentally opposed to North America's nostalgic fetish for stand-up arcade cabs as the "standard" arcade cab. Sitdown candy cabs are a vast improvement thanks to being much more widely accessible for kids, short people, people in wheelchairs, etc.

I still say you don't understand just how much the project already bends to NOT be 'user hostile' it's practically at breaking point.

Except no matter how much it bends, it seems to be a case of 'never enough' for certain groups.

The reason some features aren't fully to your liking is because by having them at all it's already placing an undue burden on those doing the dev work.

What i'm saying is that really, limits in being user-friendly have been hit. To work around those, things have been pushed more into community hands so that the developers can concentrate on what they're good at.

Why is this a problem?

So, you're arguing that wanting something to be implemented properly that exists in the current version of MAME in a fundamentally broken and unusable state for games with separate tap/hold functions for buttons, and exists in an easy-to-implement way as demonstrated by other builds, is a case of "feature creep"?

When it could, and should be done with the plugin system, yes.

Note, just how many of the other builds have actually died out, because the feature sets they were trying to maintain on top of MAME were a ridiculous amount of work to maintain, and that was with dedicated maintainers for those features.

On top of that, even with those features, there would be criticism because they weren't to the exact spec somebody wanted too.

When things like MAMEPlus decided to try and do the sensible thing, and split the GUI into a real frontend, again they just got hate for it from vast parts of the community even if it was objectively better.

It's all frill on top of the actual emulation.

This is actually why things like RetroArch have come about, because it means the developers don't have to even consider this audience. The appeal of it to developers is they *never* have to deal with this scene and demands for features they literally have no interest in. Unfortunately it's so badly done, and so limited (in simple terms, it basically assumes everything will fit the user interaction design of a retail SNES) that it really isn't suitable for MAME use, because MAME is much more demanding in terms of flexibility than such a wrapper could ever offer; it simply strangles MAME.

Autofire support is a relatively trivial function to add built-in to any emulator and having it expected to be available is normal and a reasonable expectation nowadays. If you can't understand that and want users to have to wade through a totally separate section of third-party plugins looking for the thing that will add basic functionality to your emulator, hoping that the plugin does not break in the future if the emulator changes its plugin system (which can and does happen), then quite frankly you're beyond help.

Your inability to recognize what things consist of basic and useful emulator functionality does not mean they are not basic and useful elements to expect in an emulator.