shmups.system11.org

As long as the extra lua hooks are added in a clean way (and don't cause any significant performance issues etc.) then I can't imagine any of the devs being against things that give more power to the scripting. It is possible useful functions are not currently exposed because nobody has had a use for them but these things are only going to improve as people make more use of the functionality (that's how most systems like this develop)

Nearly all of these games are made in Japan, and most people outside of Japan/China/Korea simply don't care about these games. The original MAME project, before all the fruit machines and the merge with MESS, is a huge anomaly that likely only exists because there was a strong arcade import scene in Europe at one point. America cares even less about these games than Europe does. Other countries not mentioned mostly only care about the Neo Geo.


Simply adding custom buttons would simulate everything described in that post. Proper autofire and custom buttons have been in MAME Plus! for years. Now that MAME Plus! is dead, there needs to be a new solution.

There is absolutely zero need to emulate entire pieces of hardware to get this done. That won't make anything "more accurate" unless you set out to emulate the Battle Garegga cabs as they are in Mikado, which there is no sense in doing.

And it was to the detriment of North American arcades as a whole.

There was a huge North American perception that arcade games were not something you could play seriously but just existed as timewasting quarter munchers. I suspect this was in part due to companies like Konami messing with overseas releases to make them as such, as well as North American games by Bally-Midway that were rather more literal quarter munchers pretty much designed not to give a difficult but fair experience each credit but rather to flat out take money and encourage dumping large amounts of credits in to increase health such as in Gauntlet and Xenophobe).



Implement custom buttons and autofire as MAMEPlus! does, and perhaps don't require enabling "cheat" options to do it, which hides it away from people new to MAME. Problem solved. This is essentially what AutoMAME is currently.

The question is not whether the game is not being played as intended originally, the question is if the game is fun or not and remains challenging. Autofire for many shmups does not remove the challenge and is merely a convenience that keeps buttons and fingers from being worn out unnecessarily (allowing gamers to play longer and fully enjoy the game). This is why arcade in Japan are adding them; it's not to cheat and render the game stupidly easy, it's to make them as fun as possible by removing a stupid element (button mashing) in an otherwise good game. In games where fast autofire could remove the challenge and thus is "cheating" in the sense that you're using an external tool to turn the game into a piece of cake, you still have the option not to use it or set it to a "reasonable" humanly achievable speed. It's literally the best of both worlds!

Improving the controls in a way "not intended by the developer" is not necessarily cheating, even outside an arcade context, unless you define "cheating" narrowly as "not playing it exactly the way the developer intended" instead of the more commonly accepted definition of "doing something to completely defeat the challenge of the game". The people who doing this in arcades as well as in other games are often those who are actively keeping enjoyment in the game alive and try to actively find ways of enjoying the game more by working around on design limitations or poor design choices in older games. For example, even nowadays there are many games where there is limited or no built-in support for custom controls. Being able to freely remap keyboard controls in games with no support via AutoHotKey is a great example here. Another good example is Bayonetta: there are no control remapping options when playing on a controller, and the default lock on button in the first game is RB/R1, which makes it difficult to hold and dodge when RT/R2 is the dodge button. There's also a couple dumb minigames that require mashing shoot the whole way to play optimally and aren't really particularly fun compared to the main game. There's also QTEs that require mashing that are incredibly difficult to win normally, where console players generally simply dodge and ignore the QTE prompt (Jeanne's QTEs in Hard/NSIC are nearly impossible to win by humanly doable mashing, especially in the 60 FPS versions).

The PC version fixes most of this; you can remap the controller freely using Steam's admittedly awful interface in the "Big Picture" menu (it works but the interface is horrendous). You can also use JoyToKey to enable autofire by mapping keyboard inputs to the D-Pad (you do not need the D-Pad in combat ever, using items is best by going into the menu to do it anyways). The game registers keyboard inputs along with gamepad inputs. I know of several serious Bayo players who appreciate this and we don't see these as cheating but rather as conveniences that allow them to focus on enjoying the best parts of the game. And, if you want to play the game as a "console" player would you can freely disable these features when you want. Currently I use:

I disagree. The whole point of emulation is to model things as close to the original intent as possible and keep options that change that hidden away. Have you seen how many *bad* games that simply aren't ever going to be fun or challenging we've emulated? You're talking about emulation fundamentals here.



This tends to be the MAME philosophy tho. "This existed, we have a working example of it, let's emulate it"

Not "Let's emulate some theoretical thing we don't really know how works"

If you think about it, that's why there is emulation in the first place, and not just fan remakes.

Again, this is why such options are now considered best left to plugin developers etc. For one there are too many conflicting views; the views being expressed on this forum for example are polar opposite of those expressed elsewhere. A plugin system allows different communities to create plugins that modify behavior to suit their own needs.

I know there's a growing movement for emulation being a way of making games 'better' than they were in the first place, but MAME has never really subscribed to that. Better is also subjective, it usually means 'easier' Things like widescreen hacks, draw distances hacks, utterly gross input delay removal hacks etc. are all the same, they make games easier by changing the balance in favour of the player even if the games were originally balanced around not having those changes.

In something this community might find relatable, one area MAME gets wrong is the Cave SH3 slowdowns. One day those will be fixed (it could be 10-20 years, but one day...) and once they're fixed we won't be giving the option to run them with incorrect timings. I already know for a fact that other communities will crucify us when we add slowdowns to those tho because plenty of people like them the way they are 'better' than the original. Again the long term goal is to just get things right and move towards 'as originally intended' not try to please everybody. The only difference in this case, and the reason I guess this community doesn't like this specific enhancement (no slowdowns) is because in this case, while it improves the games, it makes them more difficult, not easier, and people are more drawn towards things that give them an advantage (cheating) not a disadvantage.

There's no good reason for MAME to not have decent autofire options out of the box. What options it has are lackluster and should not be hidden away. Period

This was in reference to specifically the question of what is considered to be cheating or not, but at any rate you are absolutely, 100% wrong about what emulation is. Allowing for more freedom in terms of what controls are available has nothing to do with accuracy of the emulation of the game itself and only affects what inputs the game "sees" as being fed into the game.

This would be like saying that an NES emulator that offers autofire is inaccurately emulating the games unless Nintendo released a first-party controller with autofire support (which, for the record, it did: https://en.wikipedia.org/wiki/NES_Advantage).

There is no reason for MAME to have autofire built in at all.

It's 100% feasible to do with a plugin, which would need to be enabled like any other plugin.

If that plugin is to be distributed by communities, or by the actual project will end up being decided later, probably based on the quality and maintainability of the plugin.

I think I might just removed the existing autofire support entirely to try and push things along a bit.

Okay. Why not make savestates and frame advance/slowdown plugins too?

There's literally an entire thread here explaining why it should have autofire options built in.

Or are you just posting here to reinforce the general consensus that there's a disconnect between the people working on MAME and the people who are actually keeping real, serious interest in the games alive by playing them...?

Because we use them for development?

There's an entire thread with no compelling arguments for why it shouldn't just be a plugin.

An entire thread that if anything shows exactly why it should just be a plugin, so that it can be designed to the spec of the communities that want it by the communities that want it.

So dev tools should be included without obstruction in stock MAME but common tools that help players shouldn't?

Yes? Development always comes first, or there would be no development and you'd have 1000 more bugs to deal with?

That one is an absolute no-brainer.

But I sense you're trolling at this point. I should have picked up on that when you shared the bullshit image in the first place tho, typical attitude of those sharing it.

I'm not trolling. I legit don't know why certain things are considered essential emulator features and some aren't. If the goal is to be as hardware-accurate as possible, that is hardware-accurate to the exclusion of features that wouldn't exist in the original hardware being emulated, which if I'm not mistaken is the reasoning behind not including autofire as a first class standard feature, why are savestates and slowdown there by default in regular MAME?

Seriously, what is with this? Is it just the wide proliferation of C64/Spectrum/Amiga/etc euroshmups acting as a stepping stone or something?

The problem is what people seem to be considering a 'first class citizen'

The plugin system IS a first class citizen. It was created specifically so that MAME could expand in this direction of optional things that aren't really emulation, but might make life interesting for specific groups of users.

Yet there are people here seemingly demanding it be baked in MAME. The only reason it is at all right now is because the plugin system didn't exist at the time. (so these optional 'niceties' that enable people to 'cheat' including autofire and cpu overclocks etc. got hidden behind the cheat option which is where the community deemed the most appropriate) The actual MAME cheatfinder / cheat system has actually been moved over to lua already, the legacy one is still there but will likely vanish eventually too (and probably take the existing autofire implementation with it)

In terms of development, yes, anything and everything that actually helps development will be done, that's the primary focus of the project, to make life as easy as possible for those developing the emulation and make things as easy to understand for anybody new arriving. That is what has set MAME aside from other emulators that have come and gone over the years, readable code and a development focused design with tools (such as the debugger etc.) to make developing things as easy as possible. Other emulators didn't have that, they were more difficult to develop for, and they ultimately vanished or just turned into emulators that people ported code already written for MAME to (things like FBA).

MAME might have started out as an arcade emulator etc. but one of the reasons it has moved onto other things is also that we saw (especially for the obscure systems) how lacking the scene was in having a recognized project (MESS wasn't recognized) for people to deal with them in. Again, very much development focused choices based on a sense of responsibility and duty.

The image in question, showing Psikyo (you could just have easily picked NMK) breakage is simply the result of a shift in developers. New devs are learning the ropes by trying to make improvements to the arcade emulation, sometimes they break things. Those new devs are important tho, because without them you're very unlikely to see much improvement. Older devs are pursuing things that are of more interest to them at this point, or things they feel have been neglected for longer and are in greater need of saving. Some devs tend to be more interested in technical challenges too, and much of the material being done now presents more interesting ones and is a better use of our skills. Other devs have simply moved on entirely, plenty of the original ones are on the wrong side of 50 now.

Overall there has been a shift, with things like the plugin system, to give power to the community tho.

Again the inclusion of non-arcade stuff has also been part of that, and intended to get a more technical audience on board which is also essential for taking the project forward. Most people who simply use MAME to play games aren't actually providing fresh blood in terms of project developers.

Cheap-shot type insults like the image shared aren't really productive. There's also a slightly irony insulting something very Japanese (Mahjong games) which have got more Japanese developers / users into MAME than anything else, and have no doubt contributed a lot to the parts you do enjoy indirectly.

An emulator having a lua plugin system is good and offers more choices. The problem, as Despatche already stated, is that plugins are not going to be seen by the average user and the more plugins that exist, the more playing have to hunt for specific ones to find what they're looking for. Burying custom buttons and autofire under a plugin system or under a menu you have to toggle also is not going to be seen by the average user.

It's not a question of "should it be a plugin or not". It's a question of why is something essentially being hidden away and being de-legitimized by the dev team when it's is seen as an essential tool for people still playing the games in actual arcades? And when it's very common for emulators of other consoles to offer autofire options in the controls and not require players develop and mess with a separate plugin system?

Yeah this. It's weird to me to not just have custom turbo buttons available as standard controller options. In terms of feature set, if not implementation, its inclusion seems trivial

I also have to wonder why, if it's so common, people aren't just playing with controllers that support it, negating the need for emulator support entirely.

That's a closer analogy to how it actually works in the arcades, it isn't a function of the game PCB etc. (unless as mentioned before, there's a complex logic PCB with it's own CPU etc. for the autofire) but instead it's just some extra thing the operator has bolted between game and controls, something you could do too?

I have actually noticed it seems to be more common in China than Japan based on what I've been told, although they do seem to acknowledge it as cheating? (although there it's just part of all sorts of hacks, including code changes, especially things like cycling character during play with the start button in beat 'em ups)

Maybe my issue here is that putting it behind cheat isn't really what I'd consider *hiding* it anyway so I'm not sure why people are getting so hung up on that side of things. I mean, you'd have to turn on the plugin just like you have to turn on cheats. I can understand the criticism of it not being very good / flexible, but it was only ever intended as a cheap hack in the current form anyway.


Also it's funny to read all this about auto-fire, because auto-fire growing up literally meant auto fire, it was a switch on your pad you turned on that meant it fired without you holding anything. What we're calling auto-fire now was always 'turbo fire' on the home systems I grew up with. We did however always consider both cheating and pads supporting it were always banned in competitions the same way macro keyboards, aimbots etc. are banned in online games today.

I'd argue that an autofire option isn't something the "average user" is going to care about in the first place, given how unpopular shooters are even among people that do revisit the classics in any capacity. As for any lack of reach that such a feature implemented as a plugin would have, ShmupMAME does a fine job getting around here. I wouldn't expect an autofire plugin to be any different.

This issue will be solved the moment someone gets around to actually making a Lua plugin for autofire and custom buttons. Or everyone just uses AutoMAME and the like instead.



Not sure about other sticks, but the Hori RAP 4 Kai offers turbo functionality out of the box. Not everyone wants to shell out $150+ for something that could be done in software, I guess?

Maybe the best solution is something like the ever-popular JoyToKey, but for turbo.

Are all MAME devs this actively user-hostile?

This entire thread is the perfect example of what I mean when I talk about the gaping divide between people who only think of arcade games in the sense of the nostalgic western arcade experience they had, and people who've actually been to Japan and/or have seen and understood what the modern arcade community has evolved into thanks to serious and dedicated players. Your average North American doesn't know anything about arcade games, and doesn't care to know anything about arcade games because they're still in the mindset of seeing them as mindless quarter munchers and not worth playing seriously.

How is any of this user hostile? I'm just suggesting real viable alternatives that really should be the first option anyway?

If it's that common, why aren't people just using controllers that support it? Maybe the anger is being directed at the wrong place.

Having a good retro experience can be expensive / require specialist equipment, it's like how we can't really do anything to avoid the need for a g-sync / freesync monitor if you want a good experience without games / sound running at the wrong speeds etc. Thankfully, after years of useless LCD screens manufacturers have actually started making capable displays now, maybe they can start making capable input devices too?

So not having an interest in saving you money is user hostile?

No part of doing emulation has ever been about saving anybody money..... That's literally the last reason any of this is done.

You seem to be confusing 'user hostile' with 'not of our concern'

I take it AutoHotkey failed to catch on among users here?

AutoHotkey and JoyToKey both are great programs, but AutoHotkey requires more intensive setup for autofire and cannot be used to send joystick inputs directly; I only use it for remapping keyboard inputs and adding autofire functionality for keyboard input games.

JoyToKey is more useful for games where you can play with keyboard and disable the gamepad from being registered by the game. If the game doesn't allow you to disable the gamepad being "seen" by the game, JoyToKey can fight with native gamepad mappings and not function properly. It's also a great program for a variety of games and I use it for mapping keyboard inputs in games where the LT and RT on Xbox controllers may not be seen properly, due to being read as a single axis and not a button.

Both of these are external utilities which can do way more complex stuff than just autofire or 1 button = 2/3 button inputs, and some programs handle inputs in ways that make one or both not function correctly or difficult to setup. They're both good programs, but they're way outside the scope of what is being talked about here compared to a basic, functional autofire option in MAME (which already exists as shown in MAMEPlus, Shmupmame, etc).

Anyway, I don't really see what more there is to add here.

The existing cheat system, including autofire that gets enabled by it is a legacy MAME component. It will eventually go away.

There's a plugin system. It is a primary part of MAME and the future of these things going forward. How it operates is going to depend almost entirely on what the community puts in to both write and improve plugins as well as adding relevant hooks to MAME.

This isn't really the primary dev responsibility / interest at this point, the long term devs are much more interested in figuring out weird pieces of hardware as that's where their skillsets reside, and where they feel a level of responsibility when it comes to ensuring our history is all taken forward. Insulting them for this isn't going to help. The project is always going to follow the interests of the core development team, even if their interests change, I know some people thought that by insulting the devs in the past they'd drive them away and suddenly what they wanted would be worked on instead but that's not really how it works.

The arcade stuff is generally also left to the hands of newer developers with some support from the older ones (it's often an easier starting place for learning the MAME code) Insulting them for their mistakes in learning isn't going to help. You want to see improvements in the future, encourage them, accept that they make mistakes. Admittedly a lot of new devs are diving straight in with the non-arcade stuff instead tho, as it's generally a lot more interesting to people with good skills but most are transferable, and the arcade stuff benefits from being in the same project.

I'm not really sure what people expect as it all, MAME has been developed this way for years, and it seems that cases where opinions have been taken on board in the past are actually some of the ones people question the most now.

Is there a disconnect? probably, why wouldn't there be? I have the reaction times of a slug, I'm not going to 1CC a shooter, but I am going to figure out how a lot of hardware works and do my best to emulate it. Progress relies on multiple people with different sets of skills, more player oriented features are going to have to be programmed by somebody with more player oriented skills, hence putting things to the community. This isn't user hostile.

For some reason I never got AutoHotkey working with MAME, though admittedly I didn't try very long.

The way I see it is that savestates and the like are "core" emulation features, i.e. it's one of the critical things an emulator provides that wouldn't be replaceable with external tools. Autofire isn't like that, it's more of a wrapper around the basic input methods that MAME does provide. That's why I think a plugin would make sense. If it would become a part of the main MAME distribution I think it would be accessible enough, even if you have to manually enable the plugin. You're not going to be convincing anyone that you "should" or "shouldn't" be playing with autofire by making it more front-and-center, but not having to go out to a third party to find the plugin in the first place would be a significant benefit.

for most of the external hotkey stuff you'll have to set MAME to use dinput instead of rawinput or the like

MAME requires rawinput for many cases as it needs to be able to support far more complex configurations (multiple keyboards, multiple mice, multiple lightguns etc.) but most of those tools aren't programmed around that so you have to use the compatibility modes.

Haze, you are the last person on the planet to start accusing anyone else of trolling. I respect what you do a lot, and I know that a lot of people have had issue with you at least in the past. You are wrong here, and you're misconstruing what people are saying.


Yes. I would argue that Haze is actually the least user-hostile. Most of the core MAMEDEV absolutely despise the people who actually use the emulator, while repeatedly offering "we're saving history" as a defense. Haze wants to defend save states and such as "developer tools", but it's really a miracle MAME has any of those things at all.

Every single other emulator developer understands that adding more features is a good thing (as well as a typically much easier thing) you can do between sessions working on accuracy, and that it becomes the only thing you can do when accuracy is more or less perfected.


The problem is that you're talking about emulating the Battle Garegga cabinet as it is in Mikado, like I said. There's no sense in that. MAME Plus! has been a thing since well before most people even knew what Japan was doing to their cabinets. What's the point in changing gears to emulate a very specific piece of hardware that only exists to do something more easily done by software?


Absolutely not. The reason why those input delay hacks exist is because of your project dropping the ball for years. The only thing "utterly gross" is comparing widescreen and draw distance hacks to having to fix your error. ShmupMAME was specifically created for the era where basically every driver in MAME handled input lag very poorly. It's not as necessary anymore, but still to this day, MAME adds multiple frames of lag over the real thing. Yes, some of it is Windows overhead, but things like GroovyMAME still find enough to work with.


The only reason people whine about "no slowdown in muh Futari" is because of a feedback loop centered around worshipping CAVE games and superplays (that they barely watch and will never be interested enough to match even 1/10 of). Those people are clowns. Please do not base decisions on their input.

Not giving the option to overclock the hardware is a bad move. Please allow users to overclock hardware. There's a reason bsnes allows for things like overclocking the Super FX chip.