shmups.system11.org

Shmups Forum
 
* FAQ    * Search
 * Register  * Login 
It is currently Sun Jul 21, 2019 7:37 am View unanswered posts
View active topics



Post new topic Reply to topic  [ 181 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next
Author Message
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Thu May 09, 2019 10:28 pm 



Joined: 08 Mar 2019
Posts: 61
Square_Air wrote:
WelshMegalodon wrote:
There are also regular contributors to the Hi Scores section that have never so much as let out a whimper about MAME's lack of autofire in this thread.

Because it doesn't seem very productive to speak with developers who have a limited understanding of the community. Most of us just live with whatever ratchet autofire/custom button setup we can get our hands on. I'll always get by like this, but progress towards a better fork/implementation/plugin will only be of benefit to the community.
MameHaze wrote:
This community is maybe 0.001% of the userbase, none of the people demanding this are as special as you seem to think you are, outside of this community nobody even really cares about this.

Then why are you here? I understand that you can do whatever you please with your emulator, but this just comes off as petty.


I registered an account, because I thought some people here might be interested in the Plug and Play I emulated in MAME ( https://www.youtube.com/watch?v=5BMiCuQ90sM ) since prior to emulation there wasn't really a great deal of information on it aside from a few original hardware YouTube videos. Since this thing is part of the history of the genre you care about here, albeit not an arcade game, and significantly behind the technological curve, I thought it might be interesting, especially as the company that made it is headed by an ex Compile guy etc. To me it's an interesting piece of history and I thought by posting here it now the machine is emulated it might prompt a few people to dig around and explore it in more depth, see if it holds any interesting secrets etc. I guess the reasons are similar, outside of this community I doubt anybody is really going to care about this progress, so I brought it here.

As for the rest, maybe I am making it harder on myself. I do suffer from a lot of autistic traits, and often have to ask friends to point out when people are trolling, or not trolling, or purposely trying to waste my time. Without being sure I just answer questions honestly and try to make sure people are as well informed as possible, trying to give them a good insight into the processes we go through. I contributed to this thread because somebody seemed to want genuine insight, maybe they didn't.


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Thu May 09, 2019 10:36 pm 


User avatar

Joined: 03 Oct 2011
Posts: 3692
Location: Southern Ontario
Dude, you're welcome to post here and we're grateful for your emulation work but we're also allowed to disagree with you on what we feel are essential core elements of MAME. You being a dev doesn't mean you're immune from criticism either, and if you say something that's ignorant like "if autofire is so common, why aren't people just playing with controllers that support it, negating the need for emulator support entirely" we're totally allowed to call you out on it. Autofire's pretty damn important to shmuppers and it's been kind of a running joke for years that the main MAME build's support for it sucks. We're not all shitting on you as a developer or the devteam just because of one issue, and if the devteam doesn't want to have autofire as a standard feature in the main build (regardless of exactly how it's implemented, that isn't relevant as long as it works) then that's their prerogative. We're still allowed to shake our heads over it and go back to the sweet comfort of MAMEPlus and ShmupMAME, etc.
_________________
YouTube VideosTwitch
1CCsRestart Syndrome scores


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Thu May 09, 2019 11:14 pm 


User avatar

Joined: 13 Dec 2014
Posts: 3361
Location: Ringing the bells of fortune
I feel that there's a disconnect in what you guys are actually arguing about - whether it belongs in MAME at all, whether it should be implemented in Lua or C++, and how it should be prioritized are all different questions but they've gotten mixed together a lot in the thread and added a lot of unnecessary fuel to the fire.

BTW a basic autofire implementation only takes like a dozen lines of Lua code if you hardcode everything. Of course building a UI and saving/loading would add to that, but just FYI.
_________________
Image
NTSC-J: You know STGs are in trouble when you have threads on how to introduce them to a wider audience and get more people playing followed by threads on how to get its hardcore fan base to play them, too.
1CCs | Twitch | YouTube


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Mon May 13, 2019 4:15 pm 



Joined: 10 Sep 2014
Posts: 10
Location: CA, USA
This is a really simple clear cut feature present in most other emulators. MameHaze

Also:
"ends up being too much to ask of some people to the point where we they want to aggressively abuse us for it"
There was no aggressive abuse about this warning button thing. He never proved your case about it. He has an opinion about it but the situation is not the clear cut thing he purports it to be about preventing dev problems etc. There are other ways to deal with those problems, there always are different possibilities for solving problems. You do seem to have some sort of emotional instability related to criticism or the perception thereof. Mostly, people are just trying to discuss things, period... whereas you are the one aggressively shutting down all possible criticism by labeling it as toxic hostility etc. and painting an entire community with the same brush based on your overreaction to individual posts from individual people.

Etc.


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Tue May 14, 2019 4:44 am 


User avatar

Joined: 13 Dec 2014
Posts: 3361
Location: Ringing the bells of fortune
Imagine if someone here had, instead of whining for the past week about "user hostility," actually spent that time learning Lua and implementing an autofire plugin. Imagine if said plugin included the features and flexibility people in this thread have been arguing for others to implement, and then some. Imagine if there were a pull request open at this very moment to have said plugin included as part of the official MAME releases. Now wouldn't that be something?
_________________
Image
NTSC-J: You know STGs are in trouble when you have threads on how to introduce them to a wider audience and get more people playing followed by threads on how to get its hardcore fan base to play them, too.
1CCs | Twitch | YouTube


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Tue May 14, 2019 6:52 am 


User avatar

Joined: 11 Dec 2015
Posts: 795
^inb4 "This is the problem with the OSS/Linux community"

I guess the demand for autofire isn't "widespread" enough that more people with decent coding knowledge would have attempted to implement such a feature in Lua. Alternatively, given that there are sites like TASVideos with pages on basic Lua scripting, I guess most of those interested in implementing such things don't play shooters.
_________________
Indie hipsters: "Arcades are so dead"
Finite Continues? Ain't that some shit.
RBelmont wrote:
A little math shows that if you overclock a Pi3 to about 3.4 GHz you'll start to be competitive with PCs from 2002. And you'll also set your house on fire


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Tue May 14, 2019 7:28 am 


User avatar

Joined: 05 Nov 2013
Posts: 6620
Location: block
@Shepardus: if that means you have, then big thanks of course! :wink: *thumbsup*

Though I don't know about your skills and experience but I can tell you about mine; I've looked into it myself before, not just for autofire, as I was told it's 'easy' and all...and I didn't get the first thing. It's all gibberish to me, clearly if one doesn't already have experience with programming it's impossible. I have none, zero, and no matter how I look at it it's still all something completely out of my world.
I've tried to use the 'cheats finder' too as I was again told it's easy, and didn't get anything, apparently you need a certain level of understanding of the meachanics to use it.

So yeah, it's only accessible to a certain minority demographics, other people are helpless with it. Should I make a joke about discrimination there like Haze did?
Really if that's a 1st class citizen feature, then what category are all the people like me who don't know crap about computer science and programming?
That move from mamedev cannot be interpreted as anything but user-hostile by the majority, unless there's an untold but implied idea that only certified geeks deserve to experience the benefits of emulation fully...
_________________
mycophobia wrote:
have tyou ever played dodponpatchi


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Tue May 14, 2019 9:13 am 


User avatar

Joined: 11 Dec 2015
Posts: 795
If you're capable of grasping the concepts behind RGB, using clrmamepro, or setting up a frontend, you're capable of learning basic programming. I say this as someone with a better understanding of the latter than any of the former.
Xyga wrote:
That move from mamedev cannot be interpreted as anything but user-hostile by the majority, unless there's an untold but implied idea that only certified geeks deserve to experience the benefits of emulation fully...


Being that the MAME devs profess their intended userbase to be geeks who care about preserving and researching hardware, it doesn't seem user-hostile at all. Even if one were to argue that MAME is in fact still aimed at people who want to play games above anything else, autofire is a secondary feature.

Is it user-hostile if a nude beach denies admission to creepy men with cameras?

Is it user-hostile if women aren't happy about the deplorable portrayal of women in porn for straight men?
_________________
Indie hipsters: "Arcades are so dead"
Finite Continues? Ain't that some shit.
RBelmont wrote:
A little math shows that if you overclock a Pi3 to about 3.4 GHz you'll start to be competitive with PCs from 2002. And you'll also set your house on fire


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Tue May 14, 2019 10:23 am 



Joined: 25 Jul 2008
Posts: 1106
Location: Leeds
Xyga wrote:
So yeah, it's only accessible to a certain minority demographics


Yes, aka a target demographic. You found getting into it difficult? Imagine the job it is to start/manage/keep track/continue/do anything with this project especially as a hobby? We're probably talking weeks/months for any significant contribution. Thus, mame has a limited remit to help keep a lid on things and fix issues when they occur and keep things (as far as possible) in line for those that do this work - not the wider community.

Mame is basic platform, with a limited remit. Contributors are encouraged to add to the project along that remit. Users are encouraged to expand upon it as they want and release their own versions.

Whilst the majority of people use mame to play games this does not make them the de facto target demographic, nor should one assume that the developers want to serve them, rather than make their own decisions. The limited remit may change, but there will be some things that are just decided upon - at least for significant periods of time. Feedback from a larger community is valued in terms of publicity/bug reporting, but it's not necessarily going to dictate project remits/directions - which are beholden to the goodwill/interest of the devs.

BareKnuckle's point that autofire was implemented by MAMEPlus is exactly how the mame project wants things like this to be managed: people are welcome to do what they want with mame; further it, tweak it, break it, fix it, whatever it, support a specific community etc.

Shmupmame took an approach that wasn't preferred by some devs, but they were welcome to do it.

In both cases this is fine. The problem for mame is that people then come back and demand mame itself incorporate some/all of such features/approaches found in different emulators. Some may be totally antithetical to choices made by the main mame project. Others, such as autofire, may be minor considerations, but something that was ruled out for whatever reason. It might be the 'wrong' reason objectively AND subjectively in the majority of scenarios, but it might be 'right' in terms of keeping control of a project (e.g. rational behind what is/isn't supported/policies over project direction/use etc.).

The problem for any developer-community relationship is persuading the dev to stay (for free) and support a community. No matter how you look at it many attitudes displayed here will not be terribly encouraging to shmup inclined mame devs... which as people may gather, even if they are about (I suspect there are more than a couple immediately capable of this, some quite quiet atm), they need both the time and inclination to do the work... and to keep doing this for... ever...?

And, yes, minor or major issues you may well see changes depending on developer inclination or interest - however I do think mame on issues such as this, has remained pretty consistent over the years and - even if this can make them a bit blunt/abrupt sometimes to the majority - I have to think this has helped their longevity.
.


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Tue May 14, 2019 10:47 am 


User avatar

Joined: 05 Nov 2013
Posts: 6620
Location: block
WelshMegalodon wrote:
If you're capable of grasping the concepts behind RGB

I know next to nothing about it except it looks better. If you think everyone's mentioning it is like Fudoh, marqs, Viletim etc, well...

WelshMegalodon wrote:
using clrmamepro

failed at it countless times and got tired of tearing my hair out with it, it's notoriously hard to understand and master
anyway it's more for people who have large collections or roms or full sets, i guess...

WelshMegalodon wrote:
or setting up a frontend

depends on the frontend, some are very user-friendly, some almost require the user to code it himself

WelshMegalodon wrote:
you're capable of learning basic programming

nope, depends on who you are and what experience/skill level with the latter you have, because it's not a general culture thing, it's a specific field of knowledge.
most people used OSes, use programs, play games, but they don't make them period.

WelshMegalodon wrote:
I say this as someone with a better understanding of the latter than any of the former.

I would have guessed.

WelshMegalodon wrote:
Being that the MAME devs profess their intended userbase to be geeks who care about preserving and researching hardware

edit: This, was never stated by mamedev anytime anywhere in the history of MAME. And of course it wasn't, that'd be offcially giving the finger to most of their users.

There's a deep cultural rift most people skilled in computer knowledge and programming absolutely refuse to acknowledge, that video games have alway been an all-demographics pop culture thing, not reserved nor tergeting specifically real computer geeks demographics.
It's natural for the non-geek demographics to have a lambda player perpective over games, that's what they have been designed for, that's whom they've been designed for.
Now if emulation is a different thing in that it makes the general mass of lambda users and skilled geeks niche cohabitate, the communication and understanding are often broken.
But while we should mostly always get along, what goes wrong then ? the way i see it there's a ton of widespread misunderstanding prejudice against the lambda crowd, the way mamedevs perceive users is one of the most brutal examples i've ever seen, where the users are vilified and looked down upon with arguments like 'youre pirate kiddies who just want to play free games', 'this and that is wrong and cheating', 'you want to slave developers' etc.

I've said it enough those are ridiculous points, no labda user can reconcile with the idea that someone who makes the dumps and codes and distributes the emulator would charge his users guilty of piracy, no lambda user will accept a single or small group of developers who clearly lack proximity with the players and their culture would think he's entitled to state good morale practices and ethics in gaming, no lambda person who enjoys playing games should be belittled for not being a skilled programmer and not share the same kind of logic and thinking like it's the most common and natural thing and made feeling bad or guilty not to

Just be real, which demographics excludes the other the most to begin ?
I'll give you a simple example like anyone could quote a thousand if he's honest; language. My english's not the best but for my people who notoriously suck at learning foreign languages I'm comfortably above average, which compared to them significantly expands my access to information material and locations, sharing etc.
So then, do I look down on them for not being like me ? never, whether in a work environment or in every day life, where I'm asked to do or help, I'm aware that I have that skill, it took me decades to learn, many around me don't becaus they had different lives, they have their own knowledge that I ignore, most of them don't treat me like some ignorant peasant because I don't share the same knowledge they do. That's normal behaviour in a society.
Yet 'most' is not all. Some specialities have a tendency to host a number of hostile-to-outsiders, and computer science/software engineering is somewhat notorious for that, maybe it's the result of feeling excluded to begin, as this field often has very intelligent individuals whith social issues who've always suffered and felt threatened by 'normies'.

Now, in the typical pattern of reaction, they probably don't realize their own tendency to exclude, be agressive and offend those they percieve as outsiders/threats.
The cure to all that to be open-minded, a developer could realize users ask questions and expect things that are completely normal, they're not telling the dev he sucks nor are they trying to exploit him like a slave, and the dev should realize the world outside his own spcialized logic and interest is massively different, that it's normal and not some kind of design against his kind.

They should at the same time learn to speak honestly, instead of using deaf-blind, tunnel-visioned politics-heavy ugly BS narratives and dishonestly telling users they're vile, ignorant and ungrateful, because it's just not reality, it's wrong, and anyway...you naturally have to question the health of a project dedicated to video games that has his developers clashing with its userbase of video gamers so much. And no, again you cannot say it's the users fault, they're not developers. One individual or a working group of people believing they're right against maybe hundreds of thousands if not millions of users, on the same topics for like 20 years long, no need to explain which side is the most disconnected from reality there.

Honesty from developers would be telling users when they don't want to do something either because they cannot (skills/time/interest), or they could but don't want because it's too bothersome and hard to maintain, yet still consider what those users say and not close the door to the possibility of doing it in the future, and also understand the users will look for alternatives and not blame them for that, a dev has to reasonably acknowledge the legitimity of the user's needs, wishes and culture, not blame them for that or their lack of same-skills.

They also have to stop thinking users are ungrateful or ignore the incredible work developers do, because we have criticism or wishes - which again as i've said earlier generally concern the smaller portion of what the project is, like useability and playability parts - doesn't mean we don't recognize the immense value of the greatest part (dumping, coding etc) the gratefulness and recognition is immense and has been voiced countless times over decades.
But the reactions against users wishes and criticism have been absolutely overkill and toxic, largely showing the group of developers is disconnected from the reality of users and that situation has been fueling hostility from both side for a very long time.

@gray117: you've posted while I was typing mine. I'd have a lot to say to you but that'd be for later.
_________________
mycophobia wrote:
have tyou ever played dodponpatchi


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Tue May 14, 2019 12:31 pm 



Joined: 25 Jul 2008
Posts: 1106
Location: Leeds
Xyga wrote:
Just be real, which demographics excludes the other the most to begin ?

Xyga wrote:
Now, in the typical pattern of reaction, they probably don't realize their own tendency to exclude, be agressive and offend those they percieve as outsiders/threats.


You're not wrong. But in turn, you're being pretty (inadvertently) offensive in your assumption between work / isolation / inclusion / ownership / nomal, and the ability to be polite. Talent should not be confused with work. You still need work. Education in terms of code could hardly be more democratic and less elitist, but it does require time. Being polite, can be difficult, maybe costs some time, but is hardly costly... I think the thing to beware is who is asking who for the favour.

Making someone breakfast in bed is hardly a complicated or big task. But we know why it is a big ask; you're sacrificing your comfort time for someone else's.

...

Toxic-ness:

So, presuming you have to start somewhere, or else you'd have nothing: They put something out there for free. It's not finished, it will probably never be. It does not rely on the larger community, but it does want some help and welcomes the attention. You provide hooks and liberties for the community to do it's own work.

There's 'issues' with the larger community. Many of those problems do not start with any thanks or with a community member willing to accept their interests (whether right or wrong by anyone's judgement - an issue in itself) shouldn't come first.

This isn't toxic per se, just unpleasant. But it can start a toxic effect when this becomes an exchange and ongoing relationship. The danger to the project is that it undermines the motivation to continue it. Actions to protect your motivation/control on the project are going to be somewhat abrupt.

And here we are.

...

Me:

I've zero problem with autofire. I don't have a problem debating/criticising a free product. I do have a problem with how people often go about it, and starting from the footing that the dev is wrong for not being inclusive, and then being upset that the dev might say no... After all, even if the dev is in the 'wrong', they're perfectly entitled to their opinion effecting the project roadmap - it's their project, not yours, there was no exchange of money/services. You are likewise entitled to your opinion, but there's conceptually there's no reason you should expect to necessarily effect the project roadmap. You certainly shouldn't tell the owner it's effectively your project and they should work for you because there's more of you than them...

Despite all this I wouldn't be surprised if autofire cropped up as a feature some point, the irony is any ill will from demands such as this for it's inclusion, will probably only serve to put devs off ... why attract the debate... there's plugs anyway... and who wants to responsibility for it... It's a non issue. A small issue; sure. But why bother with it to begin with, let alone any support requests/bugs it might create if so?

...

Inclusion/ownership, the dictionary example:

Think of all the languages/sounds/combinations/characters/comparisons/explanations a complete dictionary would need. You can indeed include and track the usage of everything to be more inclusive, but that is more work, it would also be an impossibly sized book. So maybe you limit it per language? Of course you do.

Now imagine all you were actually interested in was generating a game system your own house rules of a game of scrabble. Imagine your motivation for this was interest in the game system, rather than just playing scrabble.

You include a bunch of non typical 2 letter words, exclude a lot of commonly used words/abbreviations, but exclude some you don't agree with.

You've got what you want. You give it away for free hoping others might be interested.

A load of French people find it useful to learn English, but complain they heard many words/phrases/uses on their holiday that weren't included or explained. You could make a new book for them. Or go off and pursue that Brazlian version of scrabble you were interested in. Or just improve your version as the game of scrabble changes, and your preferences change, along with the relatively small amount of people that like your take on things, you may or may not include some features for foreigners or those unused to scrabble.

A lot of other people try your rules, and many think your rules are wrong. Some people think it's a bad dictionary. Some people think it's a poor way to learn a language. Sometimes you agree with them, sometimes you don't. Sometimes you change your project, sometimes you don't, sometimes you want to change but don't have time/people to do it fully.

Through mediation/goodwill Hasbro (or whoever it is) doesn't sue you. Your project ticks along and keeps going - mostly thanks to those who agree with you and contribute. You support some spin-offs, others come and go. Some other people tell you that you need an education in how the community plays scrabble and that you should make their version.


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Tue May 14, 2019 1:23 pm 



Joined: 08 Mar 2019
Posts: 61
As per what Shepardus posted, there is now an open pull request to add the basics of autofire via the lua system
https://github.com/mamedev/mame/pull/5050
Hopefully it will be merged in

and as per my comments there, I still feel this is the right approach.

input manipulation is a complex subject, and autofire scratches the surface of it; I mention games where you alternate 2 buttons to get even faster autofire (Quarth is one such game, although you can even *break* the game by doing it too quickly and overloading it with blocks) and again it's much neater to expand a plugin to handle such things (which would then include 'fast running' style button alternation etc)

the natural expansion of that is button sequences for easy moves on fighting games (another MamePlus feature, command.dat etc.) as well as recording and editing of said macros. the plugin system will allow all these things to run on top of MAME's input system without making the core code ugly.

this _is_ MAME being user friendly rather than adding very specific hacks for one audience or excluding the features entirely.


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Tue May 14, 2019 4:27 pm 


User avatar

Joined: 25 Jan 2005
Posts: 642
Location: Virginia, USA
MameHaze wrote:
As per what Shepardus posted, there is now an open pull request to add the basics of autofire via the lua system
https://github.com/mamedev/mame/pull/5050
Hopefully it will be merged in


If it was someone in this thread who did it, thank you! This is a very good thing. I haven't updated since 0.185 (and I did the complete full shebang, all the icons and screenshots etc.), so whenever this releases I'll be bumping my version.


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Tue May 14, 2019 5:10 pm 



Joined: 02 May 2012
Posts: 10
Just tested it and works perfect!
So now we can get a rapid fire button for games like Blazing Star using any Mame version :)

Thanks a lot to jackrjli for the plugin :)

Image

Image


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Tue May 14, 2019 5:18 pm 


User avatar

Joined: 13 Dec 2014
Posts: 3361
Location: Ringing the bells of fortune
The PR has been merged now, by the way, so keep an eye out for the plugin in the next MAME release or just download it from GitHub now and drop it in your plugins directory if you can't wait. It is compatible with MAME 0.190 and above, and with some modifications might work with some older versions. Be warned that it does things a little differently from what you may be used to from MAMEPlus, and the UI can be a bit wonky.

I'll also add that Lua is far more accessible a language than C++, so, short of mamedev implementing every feature request, a Lua API goes a long way in making things workable for everyone. The documentation for the API is a bit lackluster, but that's been worked on as recently as a week ago. And as that PR shows, it's not that mamedev will reject outright reject a feature like autofire if someone implements it, it's just not a high priority for the main contributors to do themselves (if it is a priority at all).
_________________
Image
NTSC-J: You know STGs are in trouble when you have threads on how to introduce them to a wider audience and get more people playing followed by threads on how to get its hardcore fan base to play them, too.
1CCs | Twitch | YouTube


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Tue May 14, 2019 6:28 pm 


User avatar

Joined: 22 Sep 2016
Posts: 443
MameHaze wrote:
As per what Shepardus posted, there is now an open pull request to add the basics of autofire via the lua system
https://github.com/mamedev/mame/pull/5050
Hopefully it will be merged in

and as per my comments there, I still feel this is the right approach.

input manipulation is a complex subject, and autofire scratches the surface of it; I mention games where you alternate 2 buttons to get even faster autofire (Quarth is one such game, although you can even *break* the game by doing it too quickly and overloading it with blocks) and again it's much neater to expand a plugin to handle such things (which would then include 'fast running' style button alternation etc)

the natural expansion of that is button sequences for easy moves on fighting games (another MamePlus feature, command.dat etc.) as well as recording and editing of said macros. the plugin system will allow all these things to run on top of MAME's input system without making the core code ugly.

this _is_ MAME being user friendly rather than adding very specific hacks for one audience or excluding the features entirely.


good stuff
_________________
Image
My YouTube channel: link
Also I stream here sometimes: link


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Tue May 14, 2019 10:28 pm 


User avatar

Joined: 28 Feb 2015
Posts: 614
Location: Rome
Everything is more accessible than C++ (aside from, maybe, functional languages like CAML or shit like Cobol).

And remember: no one really knows C++.

Spoiler: show
/s


EDIT: also, good shit to whoever did this.


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Wed May 15, 2019 12:14 am 


User avatar

Joined: 04 Jun 2018
Posts: 27
Location: Barcelona, Spain
I'm happy to report that the plugin is excellent, it covers all needs. This is greatly appreciated. However, be aware that it has one small issue:
For some reason, if you press F3 it removes your current configuration. You need to set everything up, then press escape so it saves, load the rom again and then you'll be able to F3 freely. Not a big deal but it can be a bit of a pain when experimenting with different rates in some games.
Another question: will this work for future builds without the need to update the plugin itself? At least as long as MAME doesn't change drastically.


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Wed May 15, 2019 12:34 am 


User avatar

Joined: 13 Dec 2014
Posts: 3361
Location: Ringing the bells of fortune
SynthRicardo wrote:
I'm happy to report that the plugin is excellent, it covers all needs. This is greatly appreciated. However, be aware that it has one small issue:
For some reason, if you press F3 it removes your current configuration. You need to set everything up, then press escape so it saves, load the rom again and then you'll be able to F3 freely. Not a big deal but it can be a bit of a pain when experimenting with different rates in some games.
Another question: will this work for future builds without the need to update the plugin itself? At least as long as MAME doesn't change drastically.

The plugin saves its settings on rom stop and loads its settings on rom start. I think when you do a soft reset it calls start without calling stop, thus reloading the settings without saving them. Doing a hard reset (shift + F3) should work fine though. Probably not too hard to fix for soft resets as well...

The plugin should work for future builds as long as the Lua API doesn't change drastically.
_________________
Image
NTSC-J: You know STGs are in trouble when you have threads on how to introduce them to a wider audience and get more people playing followed by threads on how to get its hardcore fan base to play them, too.
1CCs | Twitch | YouTube


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Wed May 15, 2019 9:50 pm 


User avatar

Joined: 25 Jan 2005
Posts: 642
Location: Virginia, USA
Aurel wrote:
Just tested it and works perfect!
So now we can get a rapid fire button for games like Blazing Star using any Mame version :)

Thanks a lot to jackrjli for the plugin :)

Image

Image


That's a cool shader you're using, what is it?


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Thu May 16, 2019 12:04 am 



Joined: 02 May 2012
Posts: 10
This is just MAME's BGFX crt-geom chain (with only customized setting values)
If you like it and don't want to change the values yourself you can take it here :
http://www.mediafire.com/file/5ql5xcg1h ... m.rar/file
(how to use included)

And thank you Shepardus ;)


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Thu May 16, 2019 3:59 pm 


User avatar

Joined: 04 Jun 2018
Posts: 27
Location: Barcelona, Spain
Image


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Sun May 19, 2019 7:23 am 



Joined: 20 Sep 2017
Posts: 5
Btw, and so I don't forget to file on the GitHub pull request later as well, the Linux version of MAME refuses to work with the Lua plugin (I've been using the MAME 0.209 package on Arch Linux for reference, building stock 0.209 from the website should give you most of what you need to reproduce this behavior on any Linux)


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Sun May 19, 2019 6:43 pm 



Joined: 26 Jan 2005
Posts: 1368
Location: Vienna, VA
Sapphire wrote:
Btw, and so I don't forget to file on the GitHub pull request later as well, the Linux version of MAME refuses to work with the Lua plugin (I've been using the MAME 0.209 package on Arch Linux for reference, building stock 0.209 from the website should give you most of what you need to reproduce this behavior on any Linux)


Works fine with the ubuntu 19.04 package (0.206)

Just dropping it into the plugins directory isn't sufficient, you have to enable it. Either via plugins.ini or via the plugins menu in MameUI. Once I did that I was able to configure per-game auto fire settings
_________________
Suck


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Tue May 21, 2019 1:28 am 


User avatar

Joined: 06 Mar 2018
Posts: 17
Seconding what Sapphire said. I'm using 0.206 I compiled from git, and although I can configure autofire settings, the hotkeys set do nothing in-game.


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Tue May 21, 2019 3:38 am 


User avatar

Joined: 13 Dec 2014
Posts: 3361
Location: Ringing the bells of fortune
FabulousVioletGuy wrote:
Seconding what Sapphire said. I'm using 0.206 I compiled from git, and although I can configure autofire settings, the hotkeys set do nothing in-game.

Do you happen to have the same key bound to non-autofire in the regular input menu (e.g. set Z to autofire button 1 and also Z as button 1 in the input menu)? In that case the non-autofire button will take precedence so the autofire won't work.

I have also noticed that the plugin doesn't work with AutoMAME for some bizarre reason, not that you should need both anyway.
_________________
Image
NTSC-J: You know STGs are in trouble when you have threads on how to introduce them to a wider audience and get more people playing followed by threads on how to get its hardcore fan base to play them, too.
1CCs | Twitch | YouTube


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Tue May 21, 2019 6:35 am 


User avatar

Joined: 26 Nov 2011
Posts: 257
Shepardus wrote:
The PR has been merged now, by the way, so keep an eye out for the plugin in the next MAME release or just download it from GitHub now and drop it in your plugins directory if you can't wait. It is compatible with MAME 0.190 and above, and with some modifications might work with some older versions. Be warned that it does things a little differently from what you may be used to from MAMEPlus, and the UI can be a bit wonky.

I'll also add that Lua is far more accessible a language than C++, so, short of mamedev implementing every feature request, a Lua API goes a long way in making things workable for everyone. The documentation for the API is a bit lackluster, but that's been worked on as recently as a week ago. And as that PR shows, it's not that mamedev will reject outright reject a feature like autofire if someone implements it, it's just not a high priority for the main contributors to do themselves (if it is a priority at all).


The spirit of open source sets an example for all.
Either write your own code and submit it. Or present a rational, coherent case to those who can.


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Wed May 22, 2019 12:37 am 


User avatar

Joined: 13 Dec 2014
Posts: 3361
Location: Ringing the bells of fortune
SynthRicardo wrote:
For some reason, if you press F3 it removes your current configuration. You need to set everything up, then press escape so it saves, load the rom again and then you'll be able to F3 freely. Not a big deal but it can be a bit of a pain when experimenting with different rates in some games.

This should be fixed now. It's also merged in, so in all likelihood this will be the version when MAME 0.210 comes around.
_________________
Image
NTSC-J: You know STGs are in trouble when you have threads on how to introduce them to a wider audience and get more people playing followed by threads on how to get its hardcore fan base to play them, too.
1CCs | Twitch | YouTube


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Wed May 22, 2019 3:00 am 


User avatar

Joined: 06 Mar 2018
Posts: 17
Shepardus wrote:
I have also noticed that the plugin doesn't work with AutoMAME for some bizarre reason, not that you should need both anyway.


That explains it then. I was using it with a MAME build which has that old autofire/custom buttons patch.


Top
 Offline Profile  
 
 Post subject: Re: Reasoning for MAME not having proper autofire
PostPosted: Wed May 22, 2019 2:19 pm 



Joined: 08 Mar 2019
Posts: 61
Looking good, I have to wonder just how bad that old autofire patch was if it's interfering with this stuff tho.

I'm glad to see there has been a positive resolution to this, and people seem to have accepted that the plugin system is what we consider to be the primary / first class way of doing these things these days.

It's kinda funny that for years people have demanded things (like drivers, CPU cores etc.) be 'plugins' instead, which makes no sense, as they're the base emulation with an ever evolving API where fixes in components often require changes elsewhere (so mixing and matching them causes major problems) but have had such a hard time accepting that extras on top of the emulation should be plugins (where literally the same plugin can potentially work for years without needing a change - as pointed out, you can even use this with older versions dating back a few years)


Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 181 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next

All times are UTC


Who is online

Users browsing this forum: kibo and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Space Pilot 3K template by Jakob Persson
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group