PowerMAME - New Derivative Build

[RobotronNut]

(I'm belatedly renaming this thread, to reflect the bulk of the discussion...)

I dont think it would be a problem to allow more than one way to set up a driver.  For example, to allow the current method of shifting, and adding an optional method which mimmics the arcade hardware with constant hold down.

The problem mostly lies is submissions.  Nobody seems to know how to write code that the mame devs consider clean enough to be [acccepted]..  at least, thats how it appears to me.

this is an interesting new perspective on the discussions of the last few days. it struck me as oddly bureaucratic of the MAMEdevs to be so resistant to supporting multiple input devices, even in some cases controls that allow the games to be played as they were in the original arcade machine, even if the code is conditionally compiled and not in their official builds.

is the real issue merely good software design?

would any MAMEdevs listening in care to comment on this?

[Tiger-Heli]

How many threads do you plan to start on the same subject?  (I think this makes #4).

[Silver]

If you want to speak to mamedevs or get them to comment, IMHO, you need to go to mame.net forums or mamedev.org.

This is not the best place to speak to mamedev...

[RobotronNut]

well, in my previous threads, i was trying to work out specific solutions to specific problems for the mame system i'm constructing, but they all seemed to end up in the MAMEdev vs. arcade control discussion. even when i've said, "can we get back to the subject i originally asked about," everyone seems mainly to want to talk about this subject.

this is obviously a huge sore spot, of which i was unaware, since i'm a new-comer to arcade emulation.  however, i do have something to say about good software design. i've been passionate about good, clean C code for decades, since i worked on the Unix kernel at Bell Labs in the late 70's and led teams designing large system software projects in the 80's and 90's.

if the MAMEdevs' main concerns are NOT an unwillingness to allow arcade control support into the core MAME code, but simply a resistance to what they consider poor implementations of that support, then maybe we can make everybody happy by submitting modest, "squeaky clean" changes which, over time, bring in support for most of the devices we care about, while keeping mame clean and maintainable.

[Flinkly]

the problem with mamedevs is that they (seem to) care about documenting these old games and not making them playable on your computer.

while the argument stands that you should be able to use the original controls, most of us are plugging our controls into interfaces, then to the computer, so it's not like your pluging your controller straight to the computer where mame grabs that raw info and uses it to control the game. 

we are all sending interfaces our raw info, and they turn it into windows stuff(keypresses, mice, etc) and then windows passes it to mame who has to decode and then the game re-encodes it in your game.

[RobotronNut]

If you want to speak to mamedevs or get them to comment, IMHO, you need to go to mame.net forums or mamedev.org.

This is not the best place to speak to mamedev...

i will do that, thanks.

[Fuzi]

This is however, a good place to garner support.

You're unfortunately going to meet with the usual sarcastic replies from the voicebox (R.Belmont) and the tender know-it-all (Haze).

We may ultimately have to rely on talent from within BYOAC to recode drivers and distribute a new compile.

[RandyT]

the problem with mamedevs is that they (seem to) care about documenting these old games and not making them playable on your computer.

while the argument stands that you should be able to use the original controls, most of us are plugging our controls into interfaces, then to the computer, so it's not like your pluging your controller straight to the computer where mame grabs that raw info and uses it to control the game. 

we are all sending interfaces our raw info, and they turn it into windows stuff(keypresses, mice, etc) and then windows passes it to mame who has to decode and then the game re-encodes it in your game.

This is a good point, but I think you are missing something.  It is this way totally out of necessity. 

The interfaces used today would not be nearly the same if there was actually low level access to the input routines from the beginning.

RandyT

[Minwah]

the problem with mamedevs is that they (seem to) care about documenting these old games and not making them playable on your computer.

while the argument stands that you should be able to use the original controls, most of us are plugging our controls into interfaces, then to the computer, so it's not like your pluging your controller straight to the computer where mame grabs that raw info and uses it to control the game. 

we are all sending interfaces our raw info, and they turn it into windows stuff(keypresses, mice, etc) and then windows passes it to mame who has to decode and then the game re-encodes it in your game.

Thing is, as Randy said this is basically unavoidable.

My point is that it makes sense for MAME to accept inputs (albeit a bit indirectly) as close to how the arcade machine would as possible.  This is such a simple, logical idea that I don't know how anyone can disagree, or why anyone chose to complicate matters by actually inventing problems.

[Minwah]

We may ultimately have to rely on talent from within BYOAC to recode drivers and distribute a new compile.

If neccessary (it probably is), then this isn't the end of the world...in fact I think it would be good if we could get a bunch of people to help work on different things.

[MikeQ]

Well, I've been trying to hold off on these discussions until I had something to announce but the discussion seems to be begging me to say something.  I can't give out the URL right now because I'm waiting for Aaron Giles to approve the use of the MAME name on the site.  We have some minor issues to iron out.

I started this hobby late last year with the sole purpose of building an arcade machine.  As I've learned more and become more involved, I've seen a number of places where if the BYOAC community would pull together, we could make some nice enhancements to MAME.  I did some software work for RandyT and created a custom MAME to make use of the LED-WIZ.  Suddenly, I find my hobby is now software development to enhance MAME.  I'm not saying I dislike the new tangent my hobby has taken, but it isn't something that one person will be able to manage easily (although I will try if necessary).
I've setup up a website to distribute Power**** (replace **** with your favorite emulator starting with M).  The impetus for Power**** was to support LED-WIZ on my own personal cabinet.  With some urging from others, I decided to make Power**** available to the public.  This has now grown into a much large project which I would like all who are capable to take part in.

For this reason, I'm setting up a web bases source control system that all the BYOACers can work out of.  We will have a central repository for OUR version of MAME.   Every attempt will be made to pull all the nice features of the various MAME's into a single version.  I'm going to be running a software configuration management tool that will handle the integration of Power**** changes into the current version of the official release.    I've setup a bug reporting system and long term would like to setup regression servers to run automated testing on changes to the baseline.

Ideally, with positive dialog, we may be able to develop well integrated and well designed solutions that MAMEDevs may see as more legitimate.  I'm sure one reason they are reluctant to accept outside modifications is because it requires the devs to learn code that they didn't write and accept ownership for it in the future.  One goal that we should strive for is well documented designs for what we do.  Handing a bunch of C files to the devs is not very helpful.  A well documented design with the C code makes life for them much easier.

I have 20+ years experience in professional software development and currently work for ATI developing OpenGL drivers for the Radeon graphics products.

Now to address concerns:

I've been told that this has been tried before and failed.  I don't think someone elses failure should be a reason for me not to try.  I believe (correct me if I'm wrong) that the person who tried this before was a student at the time and this played a major role in the demise of his project.  I also believe he tried to support this himself.

I've been criticized for not starting with one of the already derivative versions floating around.  Most of these are not based on the current release.  I started with 0.102 and have made the move to 0.103.  I plan to make a release in conjunction with every major MAME release.

I've been told that people will lose interest, drop off the project and the whole thing will collapse eventually.  Yet another stupid reason not to try.  I plan to handle the brunt of what makes derivative versions difficult.  This is the source management and merges to release new versions.  Their will be times when architectural changes to MAME hose us and we will need to re-architect our own code.  This is inevitable.  If we can develop a positive relationship with the MAMEdevs, we may be better prepaired to handle these changes.

I'm sure, that people will lose interest but there will always be people who are and we should be able to handle attrition.  We should all make an attempt to embrace the MAME code and become intimate with its workings.  This will allow seasoned developers to teach the new ones.  This will also make it possible for a leaving developer to pass his work to someone else.

Regardless of what kind of support I get with this project, I intend to go forward.  If I end up doing it myself, I will just get features in slower than if we work as a team.

Thanks,

Mike

[mahuti]

Swell.

[MikeQ]

Is this a sarcastic "Swell" or a genuine "Swell"?

[thebrownshow]

I think this is a fantastic idea.  Kudos for getting the ball rolling on it.

[mahuti]

Sorry. Genuine swell. I'm just understated. And by swell, I mean, kick @$$!.

[MikeQ]

Cool.  You'd be surprised, most of what I've encountered so far has been negativity towards this idea.

[mahuti]

Yeah, well screw the haters.

Like I always say... If you want to accomplish something worthwhile, it's easier to ask for forgiveness than it is to ask for permission.

[Tiger-Heli]

Awesome news - I'm in for the documentation and web design (cough, ummn, throwing up a webpage) part of it, but I think you knew that already!!!  I'll also see that it get's linked from www.mameworld.net when we (you!) get ready.

I've been told that this has been tried before and failed.  I don't think someone elses failure should be a reason for me not to try.  I believe (correct me if I'm wrong) that the person who tried this before was a student at the time and this played a major role in the demise of his project.  I also believe he tried to support this himself.

Tried before and failed is a bit harsh.  I think you are referring to NoNameMAME by TheGatesOfBill.  He didn't fail, Real Life just got too busy for him to keep releasing his build (although from time to time he says it will return).  But the builds he did create worked flawlessly (for the most part) and are still some of the best builds for use in this hobby.  (Not that we can't do better - there is lots to add or fix!!!)

I'm sure, that people will lose interest but there will always be people who are and we should be able to handle attrition.  We should all make an attempt to embrace the MAME code and become intimate with its workings.  This will allow seasoned developers to teach the new ones.  This will also make it possible for a leaving developer to pass his work to someone else.

What you try to do is make it so that the project can continue, whether anyone stays or goes.  MAME has managed to do that, as has BYOAC.  And "None of us is as dangerous as all of us", or sth like that. . .

Anyway - Thanks again for all of your hard work on this and for taking the lead in pulling this together!!!!

[mahuti]

The arcade art library is a good example of something continuing on. I don't have a chance to contribute or administer it much, but it's still thriving without me. 

[MikeQ]

Thanks Tiger-Heli.  My wife and I threw toghether a site just to get something up.  It will probably need work and you can definetly have the documentation aspect of things!!  I've dedicated a page to it on the site.  I'll PM you a URL and you can poke around.  Give me some feedback/suggestion/ideas.

NoNameMAME:
"Failed" weren't my words.  It was one of the negative types that told my not to bother because NoNameMame had failed.  I'd love it if he came back and became a major contributor.

I'm sure we can make the project work if we get enough developers interested.  We can make the pain of supporting a custom MAME so much less painlful if we work as a group.

[Silver]

Outstanding idea. Good for you for going for it. There is already a bunch of tweaks/additions out there that people may wish to have added (author permitting of course).

One suggestion/though that I'm sure you already have covered - do you plan to set out a form of 'rules' or guidelines for what you do or don't want to include? such as will you just want to add 'extra' features like led-whiz support based around inputs or do you want any additions to mame?

[MikeQ]

I think we will look at all suggestions and the prioritize them based on feedback from the community.  It seems right now a hot topic is fixing broken controls so that will probably be where we start.  Something I'd also like to see get looked at is adding the "save state" stuff that Aaron wants.  He hinted that we will lose hiscores.dat at some point and if someone implements "save state", then this will give us a better and permanent solution.  But no, I don't think we will rule out any change.  I think the MAMEdevs goal should be to document and lay down the framework.  Our goal should be to make things more playable and more interesting.  We should also make it more product like.  For instance with the LED-WIZ stuff, the code will be their to support and LED-WIZ but if and LED-WIZ isn't found when Power**** is run, then it won't be used.  We won't expect the user to set something in a makefile and recompile.

[Tiger-Heli]

First, if official MAME loses hiscore.dat, we could still keep it in PowerMAME - but then you get into who is going to maintain the .dat file once official MAME abandons it.

Silver also has a valid point on coming up with guidelines for what will/won't be accepted.  One example I can think of is coin counters - I think Youki added it to Atomic.  Lots of people on here might like it in at least the MAME32 version - but the devs definitely don't like it, because it could be most likely used in a for-profit arcade cab environment.  And incorporating that MIGHT jeopardize the usage of PowerM*** in the name.  FWIW. . .

[MikeQ]

First, if official MAME loses hiscore.dat, we could still keep it in PowerMAME - but then you get into who is going to maintain the .dat file once official MAME abandons it.

Silver also has a valid point on coming up with guidelines for what will/won't be accepted.  One example I can think of is coin counters - I think Youki added it to Atomic.  Lots of people on here might like it in at least the MAME32 version - but the devs definitely don't like it, because it could be most likely used in a for-profit arcade cab environment.  And incorporating that MIGHT jeopardize the usage of PowerM*** in the name.  FWIW. . .

True about the coin counters.  I don't know that we need a bunch of guidelines but surely if it pisses of the MAMEdevs, it probably shouldn't be considered.  One of the goals of this little experiment is to try to build a better dialog with them anyway.  However if it seems like we are just banging our heads into a wall everytime we interface with them, we might have to rethink that goal.  We will just have to see.

[Crazy Cooter]

What I'd like to see (and hopefully be able to contribute... I have this burning desire to get deeper in the code  )
1) Easy compatibility with a FE.
2) Controls for playability with integrated CP viewer/Johnny/whatever stuff.
3) Bells & whistles - LED stuff.

I'd say the only rule would be to maintain the program well within the guidelines set by the mamedevs.  The three things I listed is enough to keep an army busy for quite some time, no need to push the interpretation of the EULA for MAME.  AFAIK, the controls project still needs info, and a FE still needs to integrate the pause/controls functions.  But I've been kind of asleep for a bit on another project, so maybe it's easier than I think.

[MikeQ]

Perhaps we should start a stick thread kinda as a sign up sheet for competent developers to show they are interested.

We can make a another thread for the incompetent ones   

FE integration was another area I thought would be nice.  If we can make a query mechanism for FE's so they don't need to rely on hand generated and maintained cfg files.  At a minimum, we could reduce how much these config files need to maintain.

I'd like to turn MAME32 into a nice looking FE too for the people that find some of the other FE's too hard to setup.

[RetroJames]

I despise the VIP's of "no."

Go for it. By the way, here is a "nice to have" feature request....


Stats. I would love a statistical reporting mechanism that you could turn on that would output things like:

Most Popular Game
Times / Dates of overall usage, specific game usage
How much "$" the cabinet has made to date (pretending each game was worth a quarter)
lots of others...


But the big one

Top scores. A csv file that is created that just listed the games and the say, 1,2,3 tip scores to date for each would be awesome.

That opens up the ability to write a script that will reap the game score list either by a selected list of games or even by cross refrencing the most popular games.

This could be used to gen an html page put up on the net ("My High Score List") or even on a screen in personal gamerooms.

Then you have the possibility of having a web interface that folks could sing up for in some way to upload the scores by batch job or whatever and really get some cool user stats from the community.

[Dav]

I despise the VIP's of "no."

Go for it. By the way, here is a "nice to have" feature request....


Stats. I would love a statistical reporting mechanism that you could turn on that would output things like:

Most Popular Game
Times / Dates of overall usage, specific game usage
How much "$" the cabinet has made to date (pretending each game was worth a quarter)
lots of others...


But the big one

Top scores. A csv file that is created that just listed the games and the say, 1,2,3 tip scores to date for each would be awesome.

That opens up the ability to write a script that will reap the game score list either by a selected list of games or even by cross refrencing the most popular games.

This could be used to gen an html page put up on the net ("My High Score List") or even on a screen in personal gamerooms.

Then you have the possibility of having a web interface that folks could sing up for in some way to upload the scores by batch job or whatever and really get some cool user stats from the community.

That's been suggested a lot.  Don't forget every games stores their scores differently, some Binary, some BCD, some ascii,  some non-ascii, some big endian etc etc etc.  You're talking about a ton of work.

[RetroJames]

That's been suggested a lot.  Don't forget every games stores their scores differently, some Binary, some BCD, some ascii,  some non-ascii, some big endian etc etc etc.  You're talking about a ton of work.

110 ... 260 ... whatever it takes   


Like I said, nice to have. Last thing I will say is it might be a nice feature for a limited group of games, for me that would just be the early to mid 80's era hits. Might be a whole seperate prject though and I am not trying to hijack here. back to your regualarly scheduled project kick-off. Move along.

[Kremmit]

Wow, I just asked for this yesterday.. Little did I know!

a "second best" approach would be to roll as many derivative builds as we can into one, so the on-going maintenance doesn't need to be duplicated by many different people.

I think that's more or less what TheGatesOfBill did with NoNameMAME.  I believe it got to be too much work, collecting all the different code variations every single time a new MAME version came out and then re-compiling them.

I'd love to see a BYOAC-MAME build, with all the controller inputs fixed- are Howard's input fixes available anywhere?  But who's going to do it?

I'm programming and web-design illiterate, unless you want your code in BASIC  , but I'd be happy to loan out specialty controllers, or do testing with them.

You rock!

[MikeQ]

Wow, I just asked for this yesterday.. Little did I know!

a "second best" approach would be to roll as many derivative builds as we can into one, so the on-going maintenance doesn't need to be duplicated by many different people.

I think that's more or less what TheGatesOfBill did with NoNameMAME.  I believe it got to be too much work, collecting all the different code variations every single time a new MAME version came out and then re-compiling them.

I'd love to see a BYOAC-MAME build, with all the controller inputs fixed- are Howard's input fixes available anywhere?  But who's going to do it?

I'm programming and web-design illiterate, unless you want your code in BASIC  , but I'd be happy to loan out specialty controllers, or do testing with them.

You rock!

Cool, hardware loaners and testing will be a big help.

[MikeQ]

I got approval from Aaron Giles tonight so I can tell you where to find the home of PowerMAME now. 

www.UnappliedBrainCells.com

The site is only partially finished an not a lot of info there.  If developers interested in contributing would do so, please use the "contact" link to email your information.  Please include your level of experience with C and programming in general.  If your not a programmer, put down any info on how you wish to contribute.

Thanks,

Mike

[AllisterFiend]

What I'd like to see (and hopefully be able to contribute... I have this burning desire to get deeper in the code  )
1) Easy compatibility with a FE.
2) Controls for playability with integrated CP viewer/Johnny/whatever stuff.
3) Bells & whistles - LED stuff.

I'd say the only rule would be to maintain the program well within the guidelines set by the mamedevs.  The three things I listed is enough to keep an army busy for quite some time, no need to push the interpretation of the EULA for MAME.  AFAIK, the controls project still needs info, and a FE still needs to integrate the pause/controls functions.  But I've been kind of asleep for a bit on another project, so maybe it's easier than I think.

I'd would also like to see these implemented.

Alas, I have nothing to offer but moral support , I do not know how to program and the hours at my job constantly change leaving little time to really get a schedule going and extra things done.

Allister Fiend


You can do it!!!

[Silver]

Outstanding!

And oooh! I got one! I got one!

Just verified an (easy) source change that lets you use Lethal Enforcers and Lethal Enforcers 2 with a light gun (previously they don't track gun properly). Does that count as "controls for playability"??! 

[Tiger-Heli]

We can make a another thread for the incompetent ones   

Put me down for that one.  I'll send you a mail about some other issues with this in a little bit.

[Tiger-Heli]

Stats. I would love a statistical reporting mechanism that you could turn on that would output things like:

Most Popular Game
Times / Dates of overall usage, specific game usage
How much "$" the cabinet has made to date (pretending each game was worth a quarter)
lots of others...

That's about the same as the coin counter idea, which I just said we might NOT want to incorporate.  One thing I DON"T want to do is turn this thread into a:

My idea is awesome, it needs to be in PowerMAME!

Your idea sucks, I'm quitting the project if it gets added!

Debate, but this does show why we need to decide early on how we will determine what gets added or not added (and ultimately, at this point it's MikeQ's baby, unless he decides to step down and hand it off to someone else, and I'm not recommending that either).

[JoyMonkey]

Ooh! ooh! I somehow missed this thread yesterday; this is awesome!

Though I don't think it'd be possible, it would be so great to have hiscores in an easily readable format like RetroJames suggested; it would be sweet to have hiscore data displayed from a frontend.

Stats could have it's uses; credit counting could never be a good thing, but 'most played' and 'most recently played' stats would be nice (although that's something that might be better applied to a frontend than within Mame itself).

[markrvp]

Just offering my support.  Like Kremmit, I have a lot of controls so I would be happy to test for you.  I can't program (at all), but I can play games.

[JoyMonkey]

Something I'd also like to see get looked at is adding the "save state" stuff that Aaron wants.  He hinted that we will lose hiscores.dat at some point and if someone implements "save state", then this will give us a better and permanent solution.

Ah, I wondered why Savestate Status for every game now shows up in listxml. A whopping 5593 out of 5942 games officially don't support savestate in 0.103, though I notice that others do seem to work even though it says it's not working when you save.

[Dav]

Something I'd also like to see get looked at is adding the "save state" stuff that Aaron wants.  He hinted that we will lose hiscores.dat at some point and if someone implements "save state", then this will give us a better and permanent solution.

Ah, I wondered why Savestate Status for every game now shows up in listxml. A whopping 5593 out of 5942 games officially don't support savestate in 0.103, though I notice that others do seem to work even though it says it's not working when you save.

Yes, hiscore.dat is a hack that causes a lot of problems and doesn't always work correctly.  The goal of the savestate plan is to emulate that the machine is always running instead of booting  every time you run it.  This has a number of possible advantages, hi scores automatically just work and  boot times for games should improve.