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.

[Tiger-Heli]

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.

Ah, I didn't realize this was what it meant -

So if I understand correctly, you set SaveState 1 on in mame.ini and the game starts where it was last running, without you having to F7 to save and Shift-F7 to load state (or however it works currently). . .

I like the idea!!!!

Kinda makes -skipstartupframes a little bit overkill, though!!!!

[SirPoonga]

http://free.hostdepartment.com/S/SirPoonga/hacks.html

most of these have been obsoleted.  though I could see some of the old ctrlr file hacks still being used by BYOACers, mainly the buttonx and playerx hacks.  The input system has since changed twice, hence why I haven't kept them up to date.  I think someone else did a better job at artwork_filledges too.  I know the artwork system has changed since too.  I spent quite abit of time figuring out the math behind that and it changed

[XtraSmiley]

MikeQ,

First let me say thanks, from me and the community.  Second, please include some type of GUI because many of us have a tough time without one.

Third, this is in no way not supporting you, but do we need another version of MAME out there?  Is there no way to get this stuff into regular MAME?  If not, by all means, lets do this, I'll help in any way I can (joystick, button, input device reviews, testing etc) but if there is a way to work this out with Aaron and get it in regular MAME, have we tried it?

Again, this is a post to totally, 100% support you, but just making sure the other avenue has been checked out.

Thanks again.

[quarterback]

Might it be time to change the name of this thread so it doesn't sound like an angry Pay-Per-View event?

[SirPoonga]

Third, this is in no way not supporting you, but do we need another version of MAME out there?  Is there no way to get this stuff into regular MAME?  If not, by all means, lets do this, I'll help in any way I can (joystick, button, input device reviews, testing etc) but if there is a way to work this out with Aaron and get it in regular MAME, have we tried it?

No, because some of hte stuff mamedevs won't care about or think shouldn't be in mame.
Some stuff that scomes out of this might make it into mame.  For example, I worked on the analog handling of 49way for arch rivals with urebel for analog mame.  That ended up in official mame.  But there are other things, such as something specific to windows, that they won't accept.

[Santoro]

Might it be time to change the name of this thread so it doesn't sound like an angry Pay-Per-View event?

I agree.  Makes it sound like we are somehow taunting them.

[MikeQ]

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.

This would be a valuable debugging tool too.  You save a game right at the point where a bug occurs so you don't have to play it for 3 hours just to find a bug.

[RayB]

How about a Save State that actually WORKS. I'm so glad I didn't include save/load admin buttons on my cab. Most games I saved progress on crap out and act all buggy when I then load.

I'm mostly interested in this version of MAME supporting the keyboard LEDs as player start indicators in ALL games, not just the Atari ones.

[MikeQ]

MikeQ,

First let me say thanks, from me and the community.  Second, please include some type of GUI because many of us have a tough time without one.

Third, this is in no way not supporting you, but do we need another version of MAME out there?  Is there no way to get this stuff into regular MAME?  If not, by all means, lets do this, I'll help in any way I can (joystick, button, input device reviews, testing etc) but if there is a way to work this out with Aaron and get it in regular MAME, have we tried it?

Again, this is a post to totally, 100% support you, but just making sure the other avenue has been checked out.

Thanks again.

This and a couple of other threads this week have been all about how the MAMEdevs don't want to support some of the ideas/changes we need in order to play games with real controls.  This is the reason for doing this.  It is also so that we can consolidate some of the versions of mame into one.

[Santoro]

Support for Serial LCDs would be cool, so that the FEs didn't have to code it separately. (simply dumping romname.lcd to the serial port before launching the game) 

[XtraSmiley]

MikeQ,

First let me say thanks, from me and the community.  Second, please include some type of GUI because many of us have a tough time without one.

Third, this is in no way not supporting you, but do we need another version of MAME out there?  Is there no way to get this stuff into regular MAME?  If not, by all means, lets do this, I'll help in any way I can (joystick, button, input device reviews, testing etc) but if there is a way to work this out with Aaron and get it in regular MAME, have we tried it?

Again, this is a post to totally, 100% support you, but just making sure the other avenue has been checked out.

Thanks again.

This and a couple of other threads this week have been all about how the MAMEdevs don't want to support some of the ideas/changes we need in order to play games with real controls.  This is the reason for doing this.  It is also so that we can consolidate some of the versions of mame into one.

Thats true and I've read a few, but there's been a lot of complaining, but has any of the programmers (you guys who know your 1's and 0's) actually talked with the MAME guys?  If it's been a long time, opinions change over time, maybe they would be more reseptive now?

Either way, if you are successful, I'm sure they will eventually adapt some of your settings into the official build.

[shags]

MikeQ,

Thanks... i would like to offer my time for anything you need ...  (except for programing) i can test and beat things up, your call...

Mike

[madmagician]

good stuff.  so the main goal is basically to make a version tha tis more specialty control and arcade cabinet gadget friendly?

[MikeQ]

MikeQ,

First let me say thanks, from me and the community.  Second, please include some type of GUI because many of us have a tough time without one.

Third, this is in no way not supporting you, but do we need another version of MAME out there?  Is there no way to get this stuff into regular MAME?  If not, by all means, lets do this, I'll help in any way I can (joystick, button, input device reviews, testing etc) but if there is a way to work this out with Aaron and get it in regular MAME, have we tried it?

Again, this is a post to totally, 100% support you, but just making sure the other avenue has been checked out.

Thanks again.

This and a couple of other threads this week have been all about how the MAMEdevs don't want to support some of the ideas/changes we need in order to play games with real controls.  This is the reason for doing this.  It is also so that we can consolidate some of the versions of mame into one.

Thats true and I've read a few, but there's been a lot of complaining, but has any of the programmers (you guys who know your 1's and 0's) actually talked with the MAME guys?  If it's been a long time, opinions change over time, maybe they would be more reseptive now?

Either way, if you are successful, I'm sure they will eventually adapt some of your settings into the official build.

I had a brief discussion with Aaron Giles about permission to distribute 3rd part .dll's without source.  Once PowerMAME is launched, I plan to open up a more serious dialog with him about what it would take to get some features into MAME.

[MikeQ]

MikeQ,

Thanks... i would like to offer my time for anything you need ...  (except for programing) i can test and beat things up, your call...

Mike

This goes for everyone too.

Send me an email at mikeq@unappliedbraincells.com.  Give me a list of your talents and how you would like to contribute.  I'm filing these away and when something comes up that needs to be done, I'll match it up with the person who can do it.

[MikeQ]

good stuff.  so the main goal is basically to make a version tha tis more specialty control and arcade cabinet gadget friendly?

That and anything else we can dream up.

How about MAME instant messaging so we can all chat while playing on our cabinets!!! 

[RobotronNut]

many thanks for taking on this task, which i'm sure will be of great service to this community.

another thing to put on your list - consistent support for both stay-in-place and return-to-center shifters for driving games.

[Silver]

another thing to put on your list - consistent support for both stay-in-place and return-to-center shifters for driving games.

Aha! Yes indeed. Get it to respond according to the input you set in the cfg file. So if you have a hi/low shifter the game will work with that. Some kind of consistency is required!

[Minwah]

Aha! Yes indeed. Get it to respond according to the input you set in the cfg file. So if you have a hi/low shifter the game will work with that. Some kind of consistency is required!

I agree the method for shifters should be standand...I think we only need one method tho, basically the one used in OutRun should work with all shifters (see the recent thread about this for more).

Also there are some driving games where the pedals are difficult to get going without the 'correct' pedal system (single/dual axis) - maybe we could work on something for this too.

I think some people may want the 720degrees controls changed back to dial which can be used with an original controller.

Gun game problems should maybe be looked at, where they are not fixed by the official mame.


These are the kindof things I would like to see done...I'm not really bothered about anything else.  Good Luck MikeQ, and if I can do anything to help I will...

[captainpotato]

For my part, I'd like to see that the AdvanceMAME mods are included as much as possible, as no other version that I've tried works so well in terms of screenmodes.

This, and another vote for working, accurate driving controls

[screaming]

don't forget about this one.

Almost time to create a PowerMAME thread?

[SirPoonga]

Almost time to create a PowerMAME thread?

Or support forum...

[Grasshopper]

It would be nice if PowerMAME could include lokki's mirrored screen hack so that simultaneous two player games can be played on a cocktail cabinet.

http://forum.arcadecontrols.com/index.php?topic=38312.0

[Fozzy The Bear]

Damnit!! I missed most of this thread up until now, because the start of it was a pop at the MameDevs and I just lost interest once I saw that...

This thread is way too important for it to get misssed because of its poor starting posts and title.

In fact I'd suggest that this needs more than just a post IMHO it needs a complete section of its own in the forum.

I'm all for this idea, because MameDevs priorities are sometimes a lot different from the priorities we have as hardware builders and understandably so.

Best Regards,
Julian (Fozzy The Bear)

[jelwell]

I've been told that this has been tried before and failed.

It's easy to be successful when you're handing out patches. It's much harder when you redesign MAME code to handle things that don't exist. Here's a suggestion on how to handle this:
Every time you make a code change:

• Submit it MAMEdev - maybe they'll simply pick it up
• Submit a stub API to Mamedev - so that when they refactor, your code will still work.

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.

The sad part is that you should be starting with a derivative - especially if it already contains features you plan on adding. At the very least, you should go through all the derivatives, old or new, and figure out if there are features you want. AdvanceMAME and AnalogMame+ both have support for some great BYOAC hardware. And AdvanceMAME isn't even very far behind MAME.

However there's a reason derivatives are lagged behind so much - and it's not so much because of lack of interest. The problem is that every MAME rewrite is likely to break your patch - often irreparably. That is why I think you should consider my bulleted list above. If you can get MAMEdev to, at the least, consider your stubs then they'll include them in any refactor. If you can't you'll end up having to refactor your codebase every time they do.

If we can develop a positive relationship with the MAMEdevs, we may be better prepaired to handle these changes.

This is of course, the easiest solution. I wish you luck in trying to work with MAMEdevs. Not because I think they're difficult, but because I think you'll have the best chance for survival that way.
Joseph Elwell.

[JoyMonkey]

Another thing that would be nice to see in PowerMAME...

A new clone of Asteroids that plays as if it's wired for cocktail mode.

Mentioned a dozen times before, but I don't think anyone's ever actually made it work. If they have, it's not in any official build.

[SirPoonga]

A new clone of Asteroids that plays as if it's wired for cocktail mode.

working on it.  I need help form someone who knows more about hte vector rendering part of mame.  I added code to the asteroids driver t deal with cocktail mode the same way the hardware does.  But when the screen flips it isn't centered vertically for some reason.  I verified all my math and resulting numbers were correct so it's something to do with mame's converting vector to raster.

[lustreking]

It would be nice if PowerMAME could include lokki's mirrored screen hack so that simultaneous two player games can be played on a cocktail cabinet.

Yes, this is very cool!

[Lilwolf]

<ignore>

[MikeQ]

PowerMAME and PowerMAME32 0.104 are available for download.

[JoyMonkey]

Sweet! I'll be sure to click on a Google Ad when I download.

[MikeQ]

Sweet! I'll be sure to click on a Google Ad when I download.

Awesome!!  That .000001 cent will help pay for my hosting fees!!   

Thanks,

JoyMonkey

Thanks for the Beta testing help too.

[Silver]

Is there any kind of "What curently in the build" page or info? I realise the LED stuff is there...

[MikeQ]

Is there any kind of "What curently in the build" page or info? I realise the LED stuff is there...

Not yet since the only thing in the build is the LED stuff.

With all the work to setup a website, do the publishing, put together source managment and a release environment as well as test the code on multiple platforms, I didn't have a lot of extra time.  Future releases will have more features and therefore more documentation with them.  I've got a documentation page setup but nothing on it right now.

[mahuti]

being that this is should be a community project... someone else should begin working on the documentation.

I'm not volunteering... I have a few other irons in the fire, but somebody else... hint, hint.

[SirPoonga]

actually, the person who added the feature should document it since that person knows about it

[mahuti]

Yeah, well, that's great in the fantasy world. you live in... in the real world it seems that documentation regularly falls by the wayside without the aid of others. I.E. the majority of front-ends, minor apps and control panel viewers have lousy documentation included. That is until somebody here, or a group of somebodies puts together a faq, walk-thru, examples, etc.

[mahuti]

A skeleton outline of how the feature works is of course, important. But useful, readable, sensical documentation does not necessarily have to spawn from the original programmer.

[MikeQ]

A skeleton outline of how the feature works is of course, important. But useful, readable, sensical documentation does not necessarily have to spawn from the original programmer.

On the download page under a menu selection "setup notes", there is a bunch of info on how to setup PowerMAME but I'm sure someone could do a far better job than I did.  Most everything I've done has been after 1:00am so I'm a little fuzzy when I do it.

[MikeQ]

don't forget about this one.

Almost time to create a PowerMAME thread?

I had a few minutes so I threw this one into PowerMAME.  It is config file configurable so you can personalize the message and also get rid of it alltogether.  PowerMAME32 has a GUI interface that allows you to enable/set the message.

[Silver]

Hey good work!

I was going to submit my fixes for correcting the use off lightguns in several games, but they've just been put into mame 0.104u1, so no point....

Maybe we should make a little to-do list, or wish list (perhaps things being worked on in todo, and things that someone thinks is good in a wish list?). We could add correcting pedal inputs to the list... 

[JoyMonkey]

don't forget about this one.

I had a few minutes so I threw this one into PowerMAME.  It is config file configurable so you can personalize the message and also get rid of it alltogether.  PowerMAME32 has a GUI interface that allows you to enable/set the message.

Is this "Game Paused" tweak included in the current build? I downloaded it again but couldn't see anything in the PowerMAME32 options about it.

[Santoro]

It would be really cool if you could display a custom Graphic over the game when paused.

Thanks for the hard work on this.

[mahuti]

I've begun officially learning C & C++ to contribute.

After all of these years I've spent learning OOP languages... what's a few more?

[MikeQ]

don't forget about this one.

I had a few minutes so I threw this one into PowerMAME.  It is config file configurable so you can personalize the message and also get rid of it alltogether.  PowerMAME32 has a GUI interface that allows you to enable/set the message.

Is this "Game Paused" tweak included in the current build? I downloaded it again but couldn't see anything in the PowerMAME32 options about it.

No.  If you go to release notes on the download page, you'll see what is in it and what is coming (done so far) in the next release.  Also, I changed it from being a file that is read to a command line option that is passed in.  This fits better with existing options and means that  the information gets saved in both mame.ini and mame32.ini.  It is also assignable per game.  This way you can have custom messages for each game or apply the default to all games.

I was planning on only doing a release with each official mame release but if I get enough stuff done in between, I'll release one if people are looking for features.   I'd like to keep this to a minimum as a release kills an entire evening.  I have to build all configurations and run some basic testing as well as baseline the release.

[MikeQ]

I've begun officially learning C & C++ to contribute.

After all of these years I've spent learning OOP languages... what's a few more?

Cool.  If you know java then C++ is easy.  If you know C++ you can learn C.  If you have any questions, you know where to find me.

[MYX]

Hey Mike,
I posted this on the LEDWiz section but got no reply yet. Do you know if Randy is working on a MultiLEDwiz version?

[MikeQ]

Hey Mike,
I posted this on the LEDWiz section but got no reply yet. Do you know if Randy is working on a MultiLEDwiz version?

I saw the post but was waiting for Randy to respond.  The short answer is, "I think so".

I'm sure it is on his list.  I've sent him at least one email about virtualizing the software so more LED-Wiz just appear as more LED's.   This way when creating sequences, the user doesn't need to worry about what device LED's are physically on.

He and I both have been meaning to look into using the LEDWiz.dll in Visual Basic.   I think he wants to switch to it for his program.

[MYX]

Cool, I will patiently wait. Wish I could help. I just don't know the first thing about VB.  Used to write basic on an apple IIc. Somehow I don't think that this will cut it.

10> Make MAME Work
20> If MAME don't work then Bang head on wall
30> Go to 10

[MYX]

I found this when I was on my quest for knowledge about 49 ways the other day.  Kinda of eerie.

well.. maybe RandyT will invent a cheap output board based on the KeyWiz that could be used for driving LEDs, Solonoids(Qbert, T2 recoil), lamps, relays.. etc.. of course you would need something inbetween to change the TTL signal to something with more current or whatever.. but you can find lamp driver board from pinballs and skeeball machine for cheap AFAIK.. in fact I probably have a few mixed with all my junk..   I'm no engineer but I bet Randy could make a USB device like the keywiz but with different firmware that would have all outputs instead of inputs.. of course writting drivers and incorporating it into mame would be a whole different story and perhaps parallel port might be easier.. I dunno.. just tossing out the idea...

Keep it up guys. 

[MikeQ]

I found this when I was on my quest for knowledge about 49 ways the other day.  Kinda of eerie.

well.. maybe RandyT will invent a cheap output board based on the KeyWiz that could be used for driving LEDs, Solonoids(Qbert, T2 recoil), lamps, relays.. etc.. of course you would need something inbetween to change the TTL signal to something with more current or whatever.. but you can find lamp driver board from pinballs and skeeball machine for cheap AFAIK.. in fact I probably have a few mixed with all my junk..   I'm no engineer but I bet Randy could make a USB device like the keywiz but with different firmware that would have all outputs instead of inputs.. of course writting drivers and incorporating it into mame would be a whole different story and perhaps parallel port might be easier.. I dunno.. just tossing out the idea...

Keep it up guys. 

I'd like to know who said that.  I think I need some lotto numbers from them.

[Ahigh]

.

[Ahigh]

.

[Farmboy90]

It would be really cool if you could display a custom Graphic over the game when paused.

Thanks for the hard work on this.

Santoro, you are thinking like me.     I am working on that actually.  I want to display an image (like my CP with the buttons marked as to what button is used for what) that will show directions on how to play.

I will let you guys know and then we can add that to the PowerMAME build as well as my other Game Paused change.

[MikeQ]

It would be really cool if you could display a custom Graphic over the game when paused.

Thanks for the hard work on this.

Santoro, you are thinking like me.     I am working on that actually.  I want to display an image (like my CP with the buttons marked as to what button is used for what) that will show directions on how to play.

I will let you guys know and then we can add that to the PowerMAME build as well as my other Game Paused change.

Cool.  Let me know when It is done and I'll integrate it into the code base. 

[Buddabing]

It would be really cool if you could display a custom Graphic over the game when paused.

[mahuti]

yeah, that's what I thought... but I was too lazy to post about it.

[Santoro]

Sorry guys, I am not familiar with every function of every MAME variant. 

All credit to those that have done this before.  It's a good idea

[kkingsto]

How about fixing some of the games that run slow?  I know Gorf is one of them...

But this is a cool idea...

[mahuti]

most of us that might be able to make some modest contribution (and I'm not talking about MikeQ here) aren't good enough to enhance the emulation. But we can do what we can to make some enhancements to way MAME behaves on a cabinet.

[Farmboy90]

By the way, can we include the skip_startup_frame/fast_forward_frame stuff that is going on over here?

http://forum.arcadecontrols.com/index.php?topic=48674.0

I am not sure if this is planned to be incorporated or not.  I did search the thread briefly and didn't find anything, so hopefully I am not asking a question already answered.

At any rate, a feature like that is VERY useful and user friendly for cabs.  So I have been monitoring it and would like to see it in PowerMAME.

[MYX]

Interesting artical in retroblast about Aaron Giles. Kind of cool to get to hear a MAME Dev POV. Link  Between Mike Q, Sir P, Mr. Mahuti, I am seeing a whole different side to the computer world.

[MikeQ]

Interesting artical in retroblast about Aaron Giles. Kind of cool to get to hear a MAME Dev POV. Link  Between Mike Q, Sir P, Mr. Mahuti, I am seeing a whole different side to the computer world.

I read it.  James emailed me a link.  I was surprised to hear him talking about accelerating with D3D.

[Silver]

I found this when I was on my quest for knowledge about 49 ways the other day.  Kinda of eerie.

well.. maybe RandyT will invent a cheap output board based on the KeyWiz that could be used for driving LEDs, Solonoids(Qbert, T2 recoil), lamps, relays.. etc.. of course you would need something inbetween to change the TTL signal to something with more current or whatever.. but you can find lamp driver board from pinballs and skeeball machine for cheap AFAIK.. in fact I probably have a few mixed with all my junk..   I'm no engineer but I bet Randy could make a USB device like the keywiz but with different firmware that would have all outputs instead of inputs.. of course writting drivers and incorporating it into mame would be a whole different story and perhaps parallel port might be easier.. I dunno.. just tossing out the idea...

Keep it up guys. 

I'd like to know who said that.  I think I need some lotto numbers from them.

Is that "brandon" again? Crazy - with these new lightguns on the block, I was testing loads of lightgun games, but found several that worked great but the pointer was offset from where you were pointing. Anyway, I came across an old post by someone who had problems with the same games with an analogue joystick, with mame thinking the joy was not centered when it was. He solved the problem, and lo and behold 6 months later his fix turns out to be perfect solution for all the lightgun games with the issue (8/9 I think). I changed all the games with his fix, submitted it, and all the fixes just got incorportated into 0.104u1.

That someone was "brandon". Maybe we need to trawl through this guys old posts and see what else he's suggested..... 

[MikeQ]

By the way, can we include the skip_startup_frame/fast_forward_frame stuff that is going on over here?

http://forum.arcadecontrols.com/index.php?topic=48674.0

I am not sure if this is planned to be incorporated or not.  I did search the thread briefly and didn't find anything, so hopefully I am not asking a question already answered.

At any rate, a feature like that is VERY useful and user friendly for cabs.  So I have been monitoring it and would like to see it in PowerMAME.

Someone else asked me about this too.  I think there is a diff file that would make this easy to add.  The only thing I don't like is you have to have a config file per game.  What it basically does is skips rendering until a certain frame is hit.  This allows you to skip the "don't do drugs" messages and the boot sequences on some games.  I hate having to have a per game config file.  We can add it though if people want it.

[boykster]

I think the author of that mod is moving toward a unified ini file.....

gamename,framenumber

That makes a ton more sense IMHO.

Rich

[RandyT]

I found this when I was on my quest for knowledge about 49 ways the other day.  Kinda of eerie.

well.. maybe RandyT will invent a cheap output board based on the KeyWiz that could be used for driving LEDs, Solonoids(Qbert, T2 recoil), lamps, relays.. etc.. of course you would need something inbetween to change the TTL signal to something with more current or whatever.. but you can find lamp driver board from pinballs and skeeball machine for cheap AFAIK.. in fact I probably have a few mixed with all my junk..   I'm no engineer but I bet Randy could make a USB device like the keywiz but with different firmware that would have all outputs instead of inputs.. of course writting drivers and incorporating it into mame would be a whole different story and perhaps parallel port might be easier.. I dunno.. just tossing out the idea...

Not as eerie as reading something like that when it's sitting in front of you three quarters finished.  Makes me start looking around for hidden cameras

RE: Multiple units

There's still a little bit of head banging to do on this one.  From a high level standpoint, the inputs should be virtualized.  So hopefully, when talking to the devices directly via Mike's DLL, you would think about addressing output 15 on board 3 like so:

32 x ( [board number] -1) + [output number] = [virtual output number]

or in other words

(32 x (3-1)) + 15 = 79

The actual command language used for creating animations will need to have some additions.  Most likely, I will use the same commands currently in use, but will be deciding which board to send commands to, based on the first 3 letters of the command:  LWZ for the first device and LW1 through LWF for devices 2 through 16, using HEX for the 3rd character.

Hopefully, most of this is stuff only the programmers will need to worry about

RandyT

[MikeQ]

I found this when I was on my quest for knowledge about 49 ways the other day.  Kinda of eerie.

well.. maybe RandyT will invent a cheap output board based on the KeyWiz that could be used for driving LEDs, Solonoids(Qbert, T2 recoil), lamps, relays.. etc.. of course you would need something inbetween to change the TTL signal to something with more current or whatever.. but you can find lamp driver board from pinballs and skeeball machine for cheap AFAIK.. in fact I probably have a few mixed with all my junk..   I'm no engineer but I bet Randy could make a USB device like the keywiz but with different firmware that would have all outputs instead of inputs.. of course writting drivers and incorporating it into mame would be a whole different story and perhaps parallel port might be easier.. I dunno.. just tossing out the idea...

Not as eerie as reading something like that when it's sitting in front of you three quarters finished.  Makes me start looking around for hidden cameras

RE: Multiple units

There's still a little bit of head banging to do on this one.  From a high level standpoint, the inputs should be virtualized.  So hopefully, when talking to the devices directly via Mike's DLL, you would think about addressing output 15 on board 3 like so:

32 x ( [board number] -1) + [output number] = [virtual output number]

or in other words

(32 x (3-1)) + 15 = 79

The actual command language used for creating animations will need to have some additions.  Most likely, I will use the same commands currently in use, but will be deciding which board to send commands to, based on the first 3 letters of the command:  LWZ for the first device and LW1 through LWF for devices 2 through 16, using HEX for the 3rd character.

Hopefully, most of this is stuff only the programmers will need to worry about

RandyT

I think there are 2 aspects to this.  I think the users need a GUI that virtualizes.  In other words, if you have 2 LED-Wiz's hooked up, the interface shows a single group of 64 LED's number 1-64.  A drag and drop interface would be nice but that is another topic.

The user can create a sequence with all available LED's without knowledge of what device they reside on.  The instructions that get spit out in the LWA files will not be virtualized.  A single "frame" of lighting that spans multiple devices will generate an instruction for each device in the span. 

The .DLL will accept the instructions as it does now but convert the LW1, LW2... instructions back into LWZ instructions while also steering them to the appropriate device.


Modified:

Randy, If you can at least define the new language, I can update the .DLL and incorperate it into PowerMAME.  This will allow people to at least hand generate LWA files that support multiple devices.  If the GUI isn't going to be coming soon this will allow people to at least do it the brute force way.

[MYX]

Not as eerie as reading something like that when it's sitting in front of you three quarters finished.  Makes me start looking around for hidden cameras

Yes, we are using hidden cameras and you need to stop picking your nose. 

[MYX]

Randy,
If I am right, we loose one channel to gain another board. Is this right?

The GUI could tell the app what is being done. <-- Sorry, Talking out my butt as I have no idea how this stuff works. But, Click a radio button and another 32 LEDs appear in the interface or  they were already there and become ungreyed out.

[MikeQ]

You don't lose any outputs when a new board is added.  Every board adds 32 LEDs.

[XtraSmiley]

Yes, we are using hidden cameras and you need to stop picking your nose. 

Holy $hit, I started picking my nose just as I read this...

As for the individual game start up, can't we just have a generic option to start all games like 5 minutes into it?  I realize some games don't need a lot of time, but they would end up just repeating the attract screen right?  If 5 minutes isn't enough it could be any amount of time (or user set able).  Would that solve the problem?  If I'm ignorant of how this works, don't worry about explaining out why it won't, just say, no, that won't work Mo...  If you wasted time to explain it to me, it would just waste time! 

Keep up the good work.

[Farmboy90]

Hey MikeQ,

Are you housing all the source at this time?  I mean if I submitted something, you would do the integration etc?

How about an SVN server?  I could set one up at my house and provide access to approved developers.  We could do checkins/check outs etc.  If you have never used SVN before it is source control via the web. 

At any rate, it might be easier to co-ordinate amongst the developers.  I am not sure how much tinkering would be done on it, so it may not be worth it, but just a thought.

Never mind, I just read the first page of this thread.  LOL

Hey MikeQ, can you grant me access? 

[Cananas]

By the way, can we include the skip_startup_frame/fast_forward_frame stuff that is going on over here?

http://forum.arcadecontrols.com/index.php?topic=48674.0

I am not sure if this is planned to be incorporated or not.  I did search the thread briefly and didn't find anything, so hopefully I am not asking a question already answered.

At any rate, a feature like that is VERY useful and user friendly for cabs.  So I have been monitoring it and would like to see it in PowerMAME.

I think the author of that mod is moving toward a unified ini file.....

gamename,framenumber

That makes a ton more sense IMHO.

Rich

Yes, I think this new version is included in the BuddaMame 104 release. A great feature.

[MikeQ]

Hey MikeQ,

Are you housing all the source at this time?  I mean if I submitted something, you would do the integration etc?

How about an SVN server?  I could set one up at my house and provide access to approved developers.  We could do checkins/check outs etc.  If you have never used SVN before it is source control via the web. 

At any rate, it might be easier to co-ordinate amongst the developers.  I am not sure how much tinkering would be done on it, so it may not be worth it, but just a thought.

Never mind, I just read the first page of this thread.  LOL

Hey MikeQ, can you grant me access? 

I don't have a web based system setup yet.  I have some offers to setup one up for us.

Right now, the best way to do it is to download the PowerMAME source, code up your feature, Zip the source back up and email it to me.  I'll integrate it.   To make integration easier, keep your code out of MAME files.  Put it in your own files and just put function calls to your code in the mame code.

I'll take your code and clean it up (change the coding standards and naming conventions) and merge it in to the baseline.  I'm using Perforce for CMS so I do have a revision history.  I just don't have the web interface hooked up yet.  I'll get on this since people are wanting to contribute.

[SirPoonga]

Another thing to add.
http://forum.arcadecontrols.com/index.php?topic=50083.0

I did do a hack for an older mame to do this.  But then they changed the artwork system and I didn't want to learn the new system.  However it might be worth going back to now.

Also, adding a generic bezel.  That way on games that don't have artwork you can fill in with something that matches the design of your cabinet.

[Farmboy90]

Another thing to add.
http://forum.arcadecontrols.com/index.php?topic=50083.0

I did do a hack for an older mame to do this.  But then they changed the artwork system and I didn't want to learn the new system.  However it might be worth going back to now.

Also, adding a generic bezel.  That way on games that don't have artwork you can fill in with something that matches the design of your cabinet.

I must be misunderstanding what you want to do, because I am certain this already exists.  When I first set up my cab with v0102 I noticed I had artwork on the sides (1942 for example) and I hated it.  It was making me mental.   Turns out it was just a config file setting in the mame.ini, so I flipped the value, the artwork went away, and I had empty space on the sides again.

I can't remember which thing I need to set to get rid of them, but here is what the doc says (I think it was either the artwork flag or backdrop flag):

MAME core misc options
----------------------

-[no]artwork / -[no]art

   Enable or disable usage of additional artwork (backdrops, overlays,
   etc.). The default is ON (-artwork).

-[no]use_backdrops / -[no]backdrop

   Enables/disables the display of backdrops. The default is ON
   (-use_backdrops).

-[no]use_overlays / -[no]overlay

   Enables/disables the display of overlays. The default is ON
   (-use_overlays).

-[no]use_bezels / -[no]bezel

   Enables/disables the display of bezels. The default is ON
   (-use_bezels).

[divemaster127]

This looks like this is going to be a awesome derivative of mame, will we be able to donate to the cause
thanks
divemaster

[JoyMonkey]

I must be misunderstanding what you want to do, because I am certain this already exists.  When I first set up my cab with v0102 I noticed I had artwork on the sides (1942 for example) and I hated it.  It was making me mental.   Turns out it was just a config file setting in the mame.ini, so I flipped the value, the artwork went away, and I had empty space on the sides again.

AFAIK Sir.P's tweak cropped the artwork around the screen, so vertical games were still displayed at the full height of the screen, but with the bezel artwork partially showing either side.

[SirPoonga]

I must be misunderstanding what you want to do, because I am certain this already exists.  When I first set up my cab with v0102 I noticed I had artwork on the sides (1942 for example) and I hated it.  It was making me mental.   Turns out it was just a config file setting in the mame.ini, so I flipped the value, the artwork went away, and I had empty space on the sides again.

All those options are for enabling or disabling artwork.  What we are talking about is filling in the black edges with artwork, which means dropping the artwork so it with the game fit a 4:3 screen.

[Farmboy90]

Man I am confused I think.  I will go home tonight and try to figure out the setting and maybe take a picture or two.  Here is what I recall when I tried this with 1942.

With the default settings, 1942 loaded and filled my screen vertically.  Of course being a vertically rastered game it has letter boxing on the sides.  This area was filled in with some artwork of the game itself.

I flipped the setting and loaded the game again.  There appeared to be no difference in game size - it still filled the entire screen vertically.  The only difference was the letter boxing was black - ie, not filled with artwork.

[Havok]

This is looking great!

Is there an option to skip the default "OK" for each new game? I don't see an option to turn it off by default.

Also, can we skip the disclaimer screen that the game is not working 100% or screen flipping, etc. on some games?

[Farmboy90]

Yes.  If MikeQ has not already added it, I will add those flags back to the code.

** Edit **

Actually I posted that code somewhere already.  Let me try to find the link.

** EDIT #2 **

Here it is:

http://forum.arcadecontrols.com/index.php?topic=49097.0

MikeQ, feel free to add this as well if it isn't already.  It simply adds back into the code the support for the skip_disclaimer and skip_warnings flags like this in src\windows\config.c:

  { "skip_warnings", NULL, rc_bool, &options.skip_warnings, "0", 0, 0, NULL, "skip displaying the " GAMENOUN " warnings screen" },
  { "skip_disclaimer", NULL, rc_bool, &options.skip_disclaimer, "0", 0, 0, NULL, "skip displaying the " GAMENOUN " disclaimer screen" },

[SirPoonga]

I'd be weary about adding that if you want to keep the mame name.  The devs do not like that hack.

[MYX]

It may be drifting into some legal issues we don't wanna deal with.   

[Farmboy90]

I don't see why that would be the case.  Ever other derivative out there has mame in the name and they filter these things as well.

And this isn't taking them out, it is simply providing the options that were already put there by mameDEV anyway. 

At any rate, either way is fine with me, I have my own build anyway. 

[SirPoonga]

I don't see why that would be the case.  Ever other derivative out there has mame in the name and they filter these things as well.

I can not think of a derivative that include the disclaimers hack after the mame license change?  Just because someone else gets away with it doesn't mean we would.

And this isn't taking them out, it is simply providing the options that were already put there by mameDEV anyway. 

No, its not in there, that's why people would want it added.

[Havok]

I don't see why that would be the case.  Ever other derivative out there has mame in the name and they filter these things as well.

I can not think of a derivative that include the disclaimers hack after the mame license change?  Just because someone else gets away with it doesn't mean we would.

And this isn't taking them out, it is simply providing the options that were already put there by mameDEV anyway. 

No, its not in there, that's why people would want it added.

What's the big deal, anyways? Besides, this is considered open source, right? So as long as we adhere to open source licensing, it shouldn't be a problem - and I don't think that would be a violation.

You're going to make me learn how to compile my own build, aren't you?

[krick]

What's the big deal, anyways? Besides, this is considered open source, right? So as long as we adhere to open source licensing, it shouldn't be a problem - and I don't think that would be a violation.

Not all open source licenses are the same.  If you want to use the MAME source, you have to follow their rules...

http://mamedev.org/legalfaq.html

[MYX]

Not all open source licenses are the same.  If you want to use the MAME source, you have to follow their rules...
http://mamedev.org/legalfaq.html

And that's ok with me because MAME Rocks. There, I said it. 

Hey, Sorry, this may be a stupid question, but can the comand line PowerMAME be used in MAMEWah?

[Farmboy90]

I say just change the name from PowerMAME to something withou Mame in it, and lets get on with it. 

It isn't that big of a deal to call it something else.  The point of this project is to make the most user/cab friendly mame version around.  Enough of the religous debate stuff.

Let's focus on the goal.  And if renaming it helps people sleep at night, fine by me.  I just want to play games like most every other cab builder. 

[mahuti]

Whatever the outcome, feel free to compile your own build with the above code. With Mr. Do's instructions, it's about a 5 minute process to get everything set up and going.

[JoyMonkey]

Whatever the outcome, feel free to compile your own build with the above code. With Mr. Do's instructions, it's about a 5 minute process to get everything set up and going.

Agreed. Even someone as inept at coding as myself can easily adjust the source and compile a build without the OK screens.
There's no point in disrespecting the MAME Dev's by distributing an illegitimate binary against their wishes; if people don't want those screens it takes five minutes to set up a compile environment and adjust the code themselves.

[MikeQ]

I say just change the name from PowerMAME to something withou Mame in it, and lets get on with it. 

It isn't that big of a deal to call it something else.  The point of this project is to make the most user/cab friendly mame version around.  Enough of the religous debate stuff.

Let's focus on the goal.  And if renaming it helps people sleep at night, fine by me.  I just want to play games like most every other cab builder. 

I'd like at some to work with the MAMEdevs to see what features we can get pushed back into MAME.  When there is an opportunity to do something against their wishes, I'd rather not.  I got permission from Aaron Giles to use the MAME name.  He made special exception to the license for me since I'm distributing a .DLL that I don't provide source code for.  I appreciate what he did and would rather not thumb my nose at him.

[JoyMonkey]

To try and get the documentation ball rolling, I put together a quick PowerMAME Wiki here:
http://powermame.joymonkey.com

At the moment you don't need a password to edit, so if you'd like to add a description of a feature, or start a new page, please go right ahead.

[MikeQ]

Back on topic.

I finished up Auto setting of DRS modes when using a 49way joystick and GPWiz49.  I've tested it with sinistar, galaga, Donkey kong and a few other games.  It properly selects whether the 49way will act like a 49way, 2  way, 4 way or 8 way depending on the input ports and how you have your mappings setup.

For instance if you are playing sinistar (49way game) and you have the Analog inputs mapped to Axes, you get 49way.  If you map to the analog Inc/Dec inputs and don't map the main analog input you get 8 way.  A game such as Donkey Kong that doesn't have Analog inputs will get switched to 2h, 2v, 4 or 8 way depending on how many direction you map to and whether the game denotes the inputs specifically as 4 way.  You can even do weird things like map up/dn to one 49way and left/right to another 49 for a single joystick input and each 49way will get setup properly(one as 2v and one as 2h).  I doubt people will do this but I figured I'd make it robust.

This should be in 104.1.  I still need to add a menu item on the TAB input menu to allow the user to override the autodeteced mode with his own menu selected mode.

The one issue I have is with diagonal 4 way.  I have a hacky way to detect this but I'm wondering if Qbert is the only game that does this?  Are there others?

[MikeQ]

To try and get the documentation ball rolling, I put together a quick PowerMAME Wiki here:
http://powermame.joymonkey.com

At the moment you don't need a password to edit, so if you'd like to add a description of a feature, or start a new page, please go right ahead.

Cool!  I saw your PM but took of last night for my Anniversary/Valentines day.  Just took a look.  This is a great way to keep track of features people have been requesting.

Thanks JoyMonkey.

[JoyMonkey]

The one issue I have is with diagonal 4 way.  I have a hacky way to detect this but I'm wondering if Qbert is the only game that does this?  Are there others?

As far as I know, the only other diagonal games are Congo Bongo and Q*Berts Qubes.

[MikeQ]

The one issue I have is with diagonal 4 way.  I have a hacky way to detect this but I'm wondering if Qbert is the only game that does this?  Are there others?

As far as I know, the only other diagonal games are Congo Bongo and Q*Berts Qubes.

Ok,  I'll test them too.  Qbert was my only test game.

I just updated the Wiki.  I added a sidebar catagory for what is in progress.  I added what I'm working on and moved the Pause tweak to in progress.  It isn't in the current release.

[JoyMonkey]

Actually, according to controls.dat, "Faster, Harder, More Challenging Q*bert (prototype)" is also diagonal and not a clone of QBert; so thats another one to test out.

http://fe.donkeyfly.com/controls/gamesbycontrol.php#Diagonal%204-way%20Joystick

[MYX]

I think that Congo Bongo is diag too.

EDIT

As far as I know, the only other diagonal games are Congo Bongo and Q*Berts Qubes.

Doop! Sorry,

[Tiger-Heli]

Another thing to add.
http://forum.arcadecontrols.com/index.php?topic=50083.0

I did do a hack for an older mame to do this.  But then they changed the artwork system and I didn't want to learn the new system.  However it might be worth going back to now.

Also, adding a generic bezel.  That way on games that don't have artwork you can fill in with something that matches the design of your cabinet.

I would really like to see this included.

[Tiger-Heli]

I don't see why that would be the case.  Ever other derivative out there has mame in the name and they filter these things as well.

I can not think of a derivative that include the disclaimers hack after the mame license change?  Just because someone else gets away with it doesn't mean we would.

If I'm not mistaken, BuddaMAME enables it.  I like the feature and hope it can be included.  Personally, I would change the name to PowerM*ME to include it, but I also don't want to upset the devs . . .

[SirPoonga]

Actually, according to controls.dat, "Faster, Harder, More Challenging Q*bert (prototype)" is also diagonal and not a clone of QBert; so thats another one to test out.

http://fe.donkeyfly.com/controls/gamesbycontrol.php#Diagonal%204-way%20Joystick

Oh, commas in game names.  I need to recode the php on that site sometime.  I've learned alot more since.  Funny, the review page displays the name correctly but the page you linked doesn't.  Will have to look at what I did differently....

[Minwah]

Actually, according to controls.dat, "Faster, Harder, More Challenging Q*bert (prototype)" is also diagonal and not a clone of QBert; so thats another one to test out.

And 'Tylz'...

[boykster]

maybe an "overrides" ini file (ala set49mode) is in order for special cases?

Just a thought.

Rich

[Silver]

To try and get the documentation ball rolling, I put together a quick PowerMAME Wiki here:
http://powermame.joymonkey.com

At the moment you don't need a password to edit, so if you'd like to add a description of a feature, or start a new page, please go right ahead.

Hey nice Wiki. I just added something (gear inputs) as that was requested..... No real info on it yet, although I know there is some to link to around here (although the code for polepos may be in the driver)

[JoyMonkey]

Thanks for helping! Tiger-Heli has been writing up a storm in the Wiki; there's some form of explanation for almost everything there now.

[Tiger-Heli]

Thanks for helping! Tiger-Heli has been writing up a storm in the Wiki; there's some form of explanation for almost everything there now.

Thanks for hosting this.  If you want to see a feature added, but don't want to learn Wiki (although it's really easy to use), just put a note in Miscellaneous on the Wiki and either myself or JoyMonkey will try to talk about it . . .

[MYX]

Please pardon the ignorance, but what exactly is Wiki.

[JoyMonkey]

Please pardon the ignorance, but what exactly is Wiki.

A Wiki is a website that can be edited by anybody. If you click on 'Edit' on any of the pages, it'll let you make whatever changes you'd like to it. The best example of a Wiki is Wikipedia; I'm constantly looking up info on everyhting there.

Edit:
If you want to test it out without worrying about screwing anything up (although any changes are always easily reversed anyway), try editing the SandBox page, thats what it's there for.

[mahuti]

wiki= (somewhat) anarchistic documentation tool. Great for allowing laizzes faire group interaction & documentation updates. Works fantastic until a spambot starts popping up. I've had one for the MacMAME documentation now for about 3 years, and we only recently had to start restricting access to non-anonymous users.

Nice thing about a wiki is that you can rollback to old edits if anyone writes something stupid/incorrect. 

[Tiger-Heli]

The best example of a Wiki is Wikipedia; I'm constantly looking up info on everyhting there.

Here's another interesting one for Trekkies: http://memory-alpha.org/en/wiki/Main_Page

[SirPoonga]

As stated Wiki is basically group documentation.  Which is perfect for open source program documentation as mroe than one person works on the program.

[Silver]

This may have been covered before, but I can I just repeat/suggest that:

1) Each change is available as a seperate source edit, available in seperate diffs (or controllable with 1 switch in the compile settings)

2) I think *every* change made should be controlled by an option in the ini. I'm thinking about the input changes here mainly - but if we are changing what inputs a game uses to better suit authentic hardware, then  I think it would be a good idea to keep changes optional for those with different hardware. eg "dial" input for rotary games - not authentic or right for real mechanical rotaries, but great if you have a spinner....

[MikeQ]

This may have been covered before, but I can I just repeat/suggest that:

1) Each change is available as a seperate source edit, available in seperate diffs (or controllable with 1 switch in the compile settings)

2) I think *every* change made should be controlled by an option in the ini. I'm thinking about the input changes here mainly - but if we are changing what inputs a game uses to better suit authentic hardware, then  I think it would be a good idea to keep changes optional for those with different hardware. eg "dial" input for rotary games - not authentic or right for real mechanical rotaries, but great if you have a spinner....

1)  Too much work for me to test all the permutations

2) No functionality is being lost only new features added and each feature is can be turned off or overridden.   Some don't even show up if hardware isn't available.
 
For instance, If a GPWiz49 or LEDwiz isn't found, those options are turned off.  With the GPWiz49, the menu options don't even appear.

[Tiger-Heli]

2) I think *every* change made should be controlled by an option in the ini. I'm thinking about the input changes here mainly - but if we are changing what inputs a game uses to better suit authentic hardware, then  I think it would be a good idea to keep changes optional for those with different hardware. eg "dial" input for rotary games - not authentic or right for real mechanical rotaries, but great if you have a spinner....

Agreed, that is how rotary games worked in MAME Analog Plus (you could use DIAL, keyboard, keyboard with one click per press, or sixteen inputs).  Of course that was before MAME reworked all the input handling.

[Buddabing]

This may have been covered before, but I can I just repeat/suggest that:

1) Each change is available as a seperate source edit, available in seperate diffs (or controllable with 1 switch in the compile settings)

2) I think *every* change made should be controlled by an option in the ini. I'm thinking about the input changes here mainly - but if we are changing what inputs a game uses to better suit authentic hardware, then  I think it would be a good idea to keep changes optional for those with different hardware. eg "dial" input for rotary games - not authentic or right for real mechanical rotaries, but great if you have a spinner....

I totally agree. The lack of this change control is what killed NoNameMAME.

[MikeQ]

This may have been covered before, but I can I just repeat/suggest that:

1) Each change is available as a seperate source edit, available in seperate diffs (or controllable with 1 switch in the compile settings)

2) I think *every* change made should be controlled by an option in the ini. I'm thinking about the input changes here mainly - but if we are changing what inputs a game uses to better suit authentic hardware, then  I think it would be a good idea to keep changes optional for those with different hardware. eg "dial" input for rotary games - not authentic or right for real mechanical rotaries, but great if you have a spinner....

I totally agree. The lack of this change control is what killed NoNameMAME.

Which lack of change control?  Not being able to compile each option or not being able to turn on/off each option via .ini?

[Buddabing]

This may have been covered before, but I can I just repeat/suggest that:

1) Each change is available as a seperate source edit, available in seperate diffs (or controllable with 1 switch in the compile settings)

2) I think *every* change made should be controlled by an option in the ini. I'm thinking about the input changes here mainly - but if we are changing what inputs a game uses to better suit authentic hardware, then  I think it would be a good idea to keep changes optional for those with different hardware. eg "dial" input for rotary games - not authentic or right for real mechanical rotaries, but great if you have a spinner....

I totally agree. The lack of this change control is what killed NoNameMAME.

Which lack of change control?  Not being able to compile each option or not being able to turn on/off each option via .ini?

Both. Ideally, there should be a process, similar to Linux configure, where the user checks off what options he wants, then the configure script builds the source changes and compiles it.

[MikeQ]

This may have been covered before, but I can I just repeat/suggest that:

1) Each change is available as a seperate source edit, available in seperate diffs (or controllable with 1 switch in the compile settings)

2) I think *every* change made should be controlled by an option in the ini. I'm thinking about the input changes here mainly - but if we are changing what inputs a game uses to better suit authentic hardware, then  I think it would be a good idea to keep changes optional for those with different hardware. eg "dial" input for rotary games - not authentic or right for real mechanical rotaries, but great if you have a spinner....

I totally agree. The lack of this change control is what killed NoNameMAME.

Which lack of change control?  Not being able to compile each option or not being able to turn on/off each option via .ini?

Both. Ideally, there should be a process, similar to Linux configure, where the user checks off what options he wants, then the configure script builds the source changes and compiles it.

I don't see adding build options.  It will mean for N features I will need to build 2^N configurations.  This would quickly get to be impossible.  If a feature is in PowerMAME and can be turned off via an .ini or menu selection in PowerMAME32, then it shouldn't matter to the user if the code exists in the binary.

BTW, Is your led controller available?  It's a parallel device, correct?  Does it require a kernel driver?  It would be nice to add support for it too.  At some point once I work through some of the controls stuff, I'd like to take a look at LSE too.

[RandyT]

Which lack of change control?  Not being able to compile each option or not being able to turn on/off each option via .ini?

Both. Ideally, there should be a process, similar to Linux configure, where the user checks off what options he wants, then the configure script builds the source changes and compiles it.

I'm going to venture a guess that the large majority of folks aren't going to be too concerned about the ability to perform a feature selective compile.

My opinion is that unless there is some compelling reason (like features being mutually exclusive) then being able to turn off features via an .ini would suffice for all but a few users.

RandyT

[Silver]

This may have been covered before, but I can I just repeat/suggest that:

1) Each change is available as a seperate source edit, available in seperate diffs (or controllable with 1 switch in the compile settings)

2) I think *every* change made should be controlled by an option in the ini. I'm thinking about the input changes here mainly - but if we are changing what inputs a game uses to better suit authentic hardware, then  I think it would be a good idea to keep changes optional for those with different hardware. eg "dial" input for rotary games - not authentic or right for real mechanical rotaries, but great if you have a spinner....

(Weird quoting myself!)

I should have added underneath, that correctly implimenting number 2 would make number 1 (almost) redundant, or at least not worth the (large amount of) extra work. i.e. say every addition you make defaults to off, then running your mame without tweaking the ini should essentially behave exactly like normal mame. All I'm really saying is remove nothing, only add. This may sound obvious, but its more geared towards 'correcting' or changing inputs to games, where even if we make a game more accurate control wise, leave the option to have controlled as it was.

I was thinking at the time of the post that if you make every addition an on/off option, then it would be easy to make it on/offable at compile time using a switch in the make file or whatever. However, my experience here is rather limited.

As for seperate diffs - I realise that is probably a huge amount of work, and as mentioned, probably not used by many.

I think the NoName issue was that loads and loads of changes were piled into one build, then mame completely rewrote some of its internal systems one update, and I think (guessing here really) that it was a huge task to attempt to work through and find out what was breaking where or how to re-impliment them, and there was no way of looking at one group of changes at a time, it was all or nothing.

Anyway, I'm really chuffed about this build no matter how its implimented....

[mahuti]

One thing I might mention, re: lighting function of PowerMAME.

While working on the setledwiz app, I thought quite a bit about how to handle the difference between single color LEDs and RGB leds. With the setledwiz app I eventually decided to handle the LED lighting with 2 sets of configs. One CFG deals with which terminal the LED is connected to; i.e.

1 COIN1
3 KEYCODE_X

OK. So that powers on LED 1&3. If you are using an RGB LED it's set up to use
1 COIN1
2 COIN1
3 COIN1
4 KEYCODE_X
5 KEYCODE_X
6 KEYCODE_X

Basically that CFG is the same as LedWiz.cfg is with PowerMAME. Beyond that however, I wanted to control the colors more than just ON/OFF. My solution was to add another CFG file for the colors with intensities corresponding to the LedWiz app. This makes for a nice compromise between automation and custom.

1 48
2 0
3 0
(this would be solid red)
4 48
5 38
6 5
(this would be yellow)
7 35
8 48
9 48
(this would be white)
10 129
11 0
12 0
(this would be pulsing red)

This would be a nice feature to continue to have in PowerMAME. The SetLedWiz currently has this, but it's much nicer to pursue the all-in-one solution. I haven't had time to look at the source yet of PowerMAME. I'll look tomorrow and see what's goin on.

[Tiger-Heli]

Yes, we are using hidden cameras and you need to stop picking your nose. 

Holy $hit, I started picking my nose just as I read this...

As for the individual game start up, can't we just have a generic option to start all games like 5 minutes into it?  I realize some games don't need a lot of time, but they would end up just repeating the attract screen right?  If 5 minutes isn't enough it could be any amount of time (or user set able).  Would that solve the problem?  If I'm ignorant of how this works, don't worry about explaining out why it won't, just say, no, that won't work Mo...  If you wasted time to explain it to me, it would just waste time! 

Keep up the good work.

Here I go wasting time explaining it to you!!! 

You can sortof do what you want, but -ssf does not start the game a certain number of frames into the game, it just doesn't write X number of frames to video, so you see a black screen for a few seconds instead of the initial startup routines.

If you wanted a common value (say skip the first 500 frames), you can just add -ssf 500 to your C:\mame\mame.ini file and remove it from your C:\mame\ini\gamename.ini files.

The problem is what do you set the value at.  If you choose 500, PacMan probably works fine, but crusnusa will blank about 1/4 of the startup sequence and then display the rest of it.  If you choose 5000, crusnusa will work ok (after the 10 second black screen), but PacMan will look like it is doing nothing and then come on in the middle of the attract sequence after 10 seconds.

HTH . . .

[JoyMonkey]

Did the Pause Tweak make it into 104.0.1?
I notice it's mentioned on the release notes page, but I can't seem to find it in PowerMAME32.

[Tiger-Heli]

Did the Pause Tweak make it into 104.0.1?
I notice it's mentioned on the release notes page, but I can't seem to find it in PowerMAME32.

Also - may as well mention this now - I will do my part, but PLEASE - let's try to document on the WIKI what builds added and disabled a feature.

For example - FTR 1 skips gamewarnings in regular MAME from 0.6x-something - 0.9x something, but I want something definite for PowerMAME saying "Feature added in Version 104.1, removed in Version 106.2, and re-added to version 108.5", etc.

[JoyMonkey]

Also - may as well mention this now - I will do my part, but PLEASE - let's try to document on the WIKI what builds added and disabled a feature.

For example - FTR 1 skips gamewarnings in regular MAME from 0.6x-something - 0.9x something, but I want something definite for PowerMAME saying "Feature added in Version 104.1, removed in Version 106.2, and re-added to version 108.5", etc.

Something like this version history table? Or maybe add the added/removed info to the features page? I guess both would be a good idea.

[Tiger-Heli]

Something like this version history table? Or maybe add the added/removed info to the features page? I guess both would be a good idea.

Exactly - Glad we're on the same page (sorry about the pun) with this!!!

[MikeQ]

Did the Pause Tweak make it into 104.0.1?
I notice it's mentioned on the release notes page, but I can't seem to find it in PowerMAME32.

A major revision will have new features.  So 104.1.0 will have all the new features.

A minor revision 104.0.1 will be bug fixes to 104.0.0. 

Each time I release, I branch the baseline.  The change I made last night was to the release branch not to the staging branch that I work out of on a daily basis.  The fix also went into the staging branch as well so any fix in 104.0.X will show up in the next major revision.

[MikeQ]

One thing I might mention, re: lighting function of PowerMAME.

While working on the setledwiz app, I thought quite a bit about how to handle the difference between single color LEDs and RGB leds. With the setledwiz app I eventually decided to handle the LED lighting with 2 sets of configs. One CFG deals with which terminal the LED is connected to; i.e.

1 COIN1
3 KEYCODE_X

OK. So that powers on LED 1&3. If you are using an RGB LED it's set up to use
1 COIN1
2 COIN1
3 COIN1
4 KEYCODE_X
5 KEYCODE_X
6 KEYCODE_X

Basically that CFG is the same as LedWiz.cfg is with PowerMAME. Beyond that however, I wanted to control the colors more than just ON/OFF. My solution was to add another CFG file for the colors with intensities corresponding to the LedWiz app. This makes for a nice compromise between automation and custom.

1 48
2 0
3 0
(this would be solid red)
4 48
5 38
6 5
(this would be yellow)
7 35
8 48
9 48
(this would be white)
10 129
11 0
12 0
(this would be pulsing red)

This would be a nice feature to continue to have in PowerMAME. The SetLedWiz currently has this, but it's much nicer to pursue the all-in-one solution. I haven't had time to look at the source yet of PowerMAME. I'll look tomorrow and see what's goin on.

I need to get a better grasp of what people want to do with the RGB lighting.  If people want every game to have the ability to light any control, any color, this will get complicated.

If people want certain controls to always be the same color, this will be easy.

Can people comment on how they intend to use the RGB stuff?  My panel is monochromatic so I haven't put much thought into the RGB stuff.

[Tiger-Heli]

I need to get a better grasp of what people want to do with the RGB lighting.  If people want every game to have the ability to light any control, any color, this will get complicated.

If people want certain controls to always be the same color, this will be easy.

Can people comment on how they intend to use the RGB stuff?  My panel is monochromatic so I haven't put much thought into the RGB stuff.

I don't have a personal opinion, but it's probably best to prepare for the most complicated option.

[MikeQ]

I need to get a better grasp of what people want to do with the RGB lighting.  If people want every game to have the ability to light any control, any color, this will get complicated.

If people want certain controls to always be the same color, this will be easy.

Can people comment on how they intend to use the RGB stuff?  My panel is monochromatic so I haven't put much thought into the RGB stuff.

I don't have a personal opinion, but it's probably best to prepare for the most complicated option.

That is a given.    Things should never be easy.   I'm looking for ideas that I hadn't though of that will complicate things further.

[Tiger-Heli]

I'm looking for ideas that I hadn't though of that will complicate things further.

Check your E-mail then.

[mahuti]

During my thinking process... this is the decision that I came to.

A good automated coloring scheme picks a users highest priority color and pairs it with the highest priority input. I.e, favorite color one goes with mames input1, favorite color 2 goes with mame's input2. For more complex color requests, there is the option of using romname.lwa files, which I think you already support (am I wrong on that?) From a user interface perspective, that provides some context for the button's functionality. Many games (somewhat) have a primary & secondary, tertiary button priorities, and Mame's cfg is written somewhat like that. Not a major rationalle for this method, but better than a shot in the dark.

For the SetLedWiz, I used the LED cfg to explain where the LEDS were. Then I used the color CFG to set the color priority. Input 1 will always use "red" Input 2 will always use "blue" regardless of the KEYCODE assigned to Input 1.

It gets more complex when you assume that a user will always want KEYCODE_X button to always be a certain color. I haven't provided for that eventuality yet, but I will... basically the option to choose between color priority, and color position, would seem to me to be the basic differences between user color choice for button highlighting. Any deeper scheme would be more on a Case by case basis, a la the LWA files.

To sum up, with RGB lighting, to me there would seem to be the following color cases;
1. Contextual lighting
2. Positional lighting
3. Per Game custom lighting.

[MikeQ]

I'm looking for ideas that I hadn't though of that will complicate things further.

Check your E-mail then.

Which one.  I didn't get anything.  Don't use the cfl.rr one anymore, use the mikeq@unappliedbraincells.com.

A list of what critiria to use for setting colors would be good.  I suspect this might be an area where controls.dat would be useful.  Any button labeled "fire" would be color X and so on.

[Tiger-Heli]

Which one.  I didn't get anything.  Don't use the cfl.rr one anymore, use the mikeq@unappliedbraincells.com.

I just resent it, but I used the second E-mail both times.

[SirPoonga]

To sum up, with RGB lighting, to me there would seem to be the following color cases;
1. Contextual lighting
2. Positional lighting
3. Per Game custom lighting.

And from what people tell me #3 would be the popular reason.  People are constantly asking me to put button color info into controls.dat.  Some games had specific colors for buttons and in game play used those colors.  However, I think this only covers about 5-10% of what controls.dat supports.

[mahuti]

That's exactly what "romname.lwa files can support.

Currently SetLedWiz supports both 1 & 3 and will support 2. I haven't been able to think up any other realistic automated regular processes... unless it's something like...  you ALWAYS want an input listed in Controls.dat labeled "thrust" to be red. So #4 case might be controls.dat keyword matching, but that's pretty specialized, and could be handled by romname.lwa or drivername.lwa (which might be useful for NeoGeo) Driver level stuff support for SetLedWiz is also coming... that's kind of a case 5.

[SirPoonga]

I was wondering, would it be wise to put a forum on your website?

Otherwise saint might create a support forum here.

[MikeQ]

It would be nice but I don't have the time nor the bandwidth nor the desire to maintain it.  I'd rather have a forum here.  This is where everyone is anyway.

[JoyMonkey]

I could host the forum, but you're right I think it would be better off as a support forum here. Put in a REQ in the Board Discussion forum and I'm sure someone will take care of it.

[MYX]

Can people comment on how they intend to use the RGB stuff?  My panel is monochromatic so I haven't put much thought into the RGB stuff.

Personally, I want to light the main P2 and P2 buttons (14 in all) with full RGB. I want to be able to have a game come up (say defender) and have the color of the buttons match what the real buttons are in the game. Missle comand would get 3 red buttons. (what would be cool is if a base got blown up if a LED could go out). But if I wanted to make all the buttons teal if it hits me funny, great I have that option. Mouse Trap could have real lit colored buttons just like the real thing. This is the whole reason I was wanting mullti LEDWiz support. It will take 2 LEDWiz's to be able to go full color. Leave it up to the user on how to make different colors. Experimentation is part of the learning curve.

I also want all the color options for... eh hem... sorry. Really cool looks. I know it has nothing to do with game play but when I am walking through the room, I want that sucker to taunt me to play. I spend alot of time in post makng videos pop with color and effect. I want to do the same with my CP. Making the LWA animations with full color for that many buttons is going to be a long laborious process. But I have seen your videos (Mahuti, MikeQ) and I want frakin crazy lights. I think that calling up a LWA per game would be the best. If you want a solid set of buttons then it would be a single frame LWA. I have the shell of my cab done and I will be staring the CP this weekend. If I can hold off from buying anything from the arcade auction next weekend (28th) I will be able to start ordering Ice and  LEDWizzes. 

[MikeQ]

That's exactly what "romname.lwa files can support.

Currently SetLedWiz supports both 1 & 3 and will support 2. I haven't been able to think up any other realistic automated regular processes... unless it's something like...  you ALWAYS want an input listed in Controls.dat labeled "thrust" to be red. So #4 case might be controls.dat keyword matching, but that's pretty specialized, and could be handled by romname.lwa or drivername.lwa (which might be useful for NeoGeo) Driver level stuff support for SetLedWiz is also coming... that's kind of a case 5.

In 104.1.0 if a gamename.lsq exists, it will be used over the automated lighting.  Something that might make more sense is to generate an lsq for every game that is played if one doesn't already exist.  Then, if you want to modify it, you have one to start with.

[MikeQ]

Just an announcement that I'm going to be ending PowerMAME development......   for about 1 week.  I've got some stuff I need to do and will be putting the project away for a bit.  I'll probably be away from the forums and email too.  I might pop in here or there but not as much as usual.  Just wanted to let people know so they don't think I died or something.

[Tiger-Heli]

Missle comand would get 3 red buttons. (what would be cool is if a base got blown up if a LED could go out).

Yep - I thought someone should set this up in the driver with the keyboard LED's.  As is, you will probably be able to add support for this once Light Signal Engine gets added to PowerMAME, but I'm not developing that.

[MYX]

Just an announcement that I'm going to be ending PowerMAME development......   

Starting when? MMMMMMMmmmmmmyeah, I don't believe you put in for time off with the proper paperwork. I do not see any aw1 and 3w5 request for time off forms on my desk. Get back to work. Now!!!


Do what you need to do man. We'll be here when you get back. 

[MikeQ]

Before I take off, I wanted to thank all you for your input.  Tiger-Heli, thanks for the email.  I've read through and need to put some though into the things you've mentioned.  I've had my head down trying to get some features in and have been trying to follow the forums when I have time.  I don't get to read through a lot of the threads thouroghly as it cuts into my development time.  Please everyone stick with me.  Once things settle down a bit I can step back and start looking at all the features you guys have documents and start thinking about how to approach them.

JoyMonkey, thanks for the WIKI.  That really will help when I have a chance to start participating more on the discussions.  I'm going to rely on you guys to help iron a the design for a lot of these features.   The WIKI will be a great place to get it all documented.

I'm going to really need to enlist some development help at some point.  Because of PowerMAME's visibility, I'm getting approached to take on some paying software jobs and if I do, they may cut into my time.  We'll have to see how I can balance these things.  Add on top of all that, an ill parent and my time is beginning to become very limited.  So don't get discourage if things seem to slow down at times.  I'm going to try like hell to keep this project going.

Later,

MikeQ

Also wanted to pass this along:

Take a look at the bottom menu item.  If no GPWiz 49 axes are mapped then the menu item doesn't appear.  As soon as one is mapped, PowerMAME figures out based on the inputs what the best setting should be and selects it.  That is the (AUTO) enum.  If you don't like what PowerMAME has chosen, you can select from the menu item a different mode.

[Kremmit]

That is a given.    Things should never be easy.   I'm looking for ideas that I hadn't though of that will complicate things further.

Oooh, let me help with that:

I can remember a discussion or two about button lighting that had somebody talking about changing the button illumination whenever the button is pressed.  At the time, it was just about making the button light up when pressed, but with todays lighting options, you'd probably be ready for going on, off, lighter, darker or a color change.

[MikeQ]

That is a given.    Things should never be easy.   I'm looking for ideas that I hadn't though of that will complicate things further.

Oooh, let me help with that:

I can remember a discussion or two about button lighting that had somebody talking about changing the button illumination whenever the button is pressed.  At the time, it was just about making the button light up when pressed, but with todays lighting options, you'd probably be ready for going on, off, lighter, darker or a color change.

You know what I thought would be cool is if you could record lighting sequences right on your control panel.   When you push a button or move a control, it lights up.  You could also adjust the color when you have a button lit "selected".  All the time your doing this, the sequence is being recorded.  When you done, you hit some admin button and you end the recording.  This becomes a sequence you can assign to something.

[MYX]

That would be great if it is not real time recording. Perhaps frame by frame recording. This would be an awsome way to input, not to mention a heck of a lot easier.

If you a joystick to the function you could use it to modify color or intensity based on X & Y direction.
I was planning to make a color list when I get my stuff. So if I wanted a certain color I would know it was r = 23, g = 12, b = 2.

It would be cool if Randy could make a custom version of drivers for people that wanted to do full RGB. Then you could select (press?) a button, select the color you wanted from a drop down menu of pre programmed colors (even user created colors). Then the software would assign the 3 outputs the appropriate values. For this to happen the user would have to tell the Lumaura control  that outputs 1,2,&3 = button # 1 and so on.

Here's a goofy extra (as if most of my ideas wern't)
What about a way to triger sounds. So as you are selecting a game and you press enter to start that game you get a baiter sound from defender or "kill the humanoid" from berzerk.

[Tiger-Heli]

Here's a goofy extra (as if most of my ideas wern't)
What about a way to triger sounds. So as you are selecting a game and you press enter to start that game you get a baiter sound from defender or "kill the humanoid" from berzerk.

EmuLoader (Front-End) can currently do this, but when the game is selected in the menu, not when it is launched.

[MYX]

Yeah in the menu. It would be distracting during game play.

[Kremmit]

Geez, there are just too freaking many good ideas for neat stuff PowerMAME could do.  Is anybody making a master list somewhere?

[Tiger-Heli]

http://powermame.joymonkey.com/pmwiki.php?n=Main.HomePage (Proposed Features).

[Kremmit]

That's what I'm talking about. 

[Kremmit]

Added a page to the Wiki for the Z-Axis fix. 

[Silver]

NB On the wiki - Skip Warnings/Disclaimer options appear to ve a request for the same thing. Perhaps we can merge them....

[Tiger-Heli]

NB On the wiki - Skip Warnings/Disclaimer options appear to ve a request for the same thing. Perhaps we can merge them....

Agreed - Same requested change - I'll let JoyMonkey decide which one stays and which one gets assimilated, though!!!

[screaming]

Maybe this has been beat to death but I still feel like I needed to add my two cents. Flame on if you don't like it 

Why not build and distribute a bunch of diffs that anyone can apply to the main MAME trunk?  It would be very easy, and resource-light to build a PHP script that can zip a bunch off selected diffs and provide that for download instead of the entire source and/or compiled versions with every option.

It a well known experience that the older MAME is the slower it gets running games.  Will any of your code effect the gameplay even if the option is turned off?  If so, I don't think people will want that code in there if they're not using it and it would be worth providing diffs for people to selectively compile in the code to avoid different compiled versions.

This is similar to how gentoo ebuilds work. The simplicity of it is what keeps it running so smoothly.

You could provide both a fully compiled build and a complete zip (and a batch file/shell script that will apply them selectively)/PHP interface of all the diffs and then even save on some bandwith.

[MikeQ]

Maybe this has been beat to death but I still feel like I needed to add my two cents. Flame on if you don't like it 

Why not build and distribute a bunch of diffs that anyone can apply to the main MAME trunk?  It would be very easy, and resource-light to build a PHP script that can zip a bunch off selected diffs and provide that for download instead of the entire source and/or compiled versions with every option.

It a well known experience that the older MAME is the slower it gets running games.  Will any of your code effect the gameplay even if the option is turned off?  If so, I don't think people will want that code in there if they're not using it and it would be worth providing diffs for people to selectively compile in the code to avoid different compiled versions.

This is similar to how gentoo ebuilds work. The simplicity of it is what keeps it running so smoothly.

You could provide both a fully compiled build and a complete zip (and a batch file/shell script that will apply them selectively)/PHP interface of all the diffs and then even save on some bandwith.

Not gonna happen, ever.  I'd end the project if this is what people wanted.  Someone else could deal with the hassle.  It will be too much work to independently test all the permutations that this will produce.  Also, many of the modifications won't be compatible with older builds.  Additionally, most people don't compile their own version they just take the executable.  This would cater to a very small percentage of the MAME users.

Also, having each feature be coded so it could be a standalone feature would require more code than coding them to cohabitate.  If someone wanted all the features, likely it would be bigger than what we have now.

Mame getting slower has little to do with the quantity of code too.  It is because the architecture has changed.  Mame has been redesigned to make it easier to add new games.  This means compartmentalizing code and making things more modular.  The very thing that has made MAME slower is what you are proposing.

[Tiger-Heli]

Mame getting slower has little to do with the quantity of code too.  It is because the architecture has changed.  Mame has been redesigned to make it easier to add new games.  This means compartmentalizing code and making things more modular.  The very thing that has made MAME slower is what you are proposing.

They are also moving the "Sweet Spot" to faster games. http://www.mame.net/mamefaq.html#m14

[Popcorrin]

I have a question that might have already been covered but I didn't see it mentioned anywhere.    If a game is set to cocktail mode does powermame instruct the ledwiz to light both the player 1 and player 2 buttons? 

This was kind of a side thought.
I thought I would be kind of cool if it only lit the buttons of the player that was currently active but I think that would be something more apt to be controlled by glitter's LSE which I don't think is being worked on.

[MikeQ]

I have a question that might have already been covered but I didn't see it mentioned anywhere.    If a game is set to cocktail mode does powermame instruct the ledwiz to light both the player 1 and player 2 buttons? 

This was kind of a side thought.
I thought I would be kind of cool if it only lit the buttons of the player that was currently active but I think that would be something more apt to be controlled by glitter's LSE which I don't think is being worked on.

The current version does not but the next version does.  I just ran into this when implementing the 49way stuff.  If the dip setting for cocktail is NOT set, a 49way menu selection only appears for 1 player if you set the dip to cocktail, then all the 49way menu selectors appear.  I realized when I did this that I needed to do the same for the lighting code to.  It has been implemented and is ready to go.  I'm probably going to do a minor revision release shortly (week or 2).

[screaming]

Eh well it was just an idea. Great work regardless!

[MikeQ]

Eh well it was just an idea. Great work regardless!

Thanks for taking it so well.  I expected  a flame war.   It is a nice concept but very difficult to maintain and test for the developer.  Looking at the downloads of PowerMAME too, I can tell you most people are just taking the .exe.

[screaming]

Eh well it was just an idea. Great work regardless!

Thanks for taking it so well.  I expected  a flame war.   It is a nice concept but very difficult to maintain and test for the developer.  Looking at the downloads of PowerMAME too, I can tell you most people are just taking the .exe.

  haha!  Well if I didn't wait the 2 days to reply then it probably would have been   PowerMAME is your baby and I respect your decision. If the gentoo-style diff files was worth looking into then I figured it would benefit the project more if you started thinking about it now rather than later!

  So how will you manage the modifications through the constant changing versions of MAME?  You're going to have to keep track of your changes somehow.  I figured you'd be using a diff repository anyway so why not make it public (in a sense)?  At least, that's how I initially came up with the idea.

  Rock out man. I support your project (as long as it doesn't slow things down )!

[Buddabing]

  So how will you manage the changing versions? 

CVS maybe?

[AllisterFiend]

  So how will you manage the changing versions? 

CVS maybe?

I've also noticed some people moving over to Subversion, they like it better then CVS, I have no clue which is better, but here is a link to read up on it if interested.

http://subversion.tigris.org/


Allister Fiend

[screaming]

  So how will you manage the changing versions? 

CVS maybe?

  I amended my original question to hopefully clarify what I meant.

[MikeQ]

  So how will you manage the changing versions? 

CVS maybe?

  I amended my original question to hopefully clarify what I meant.

Perforce.  I baseline each mame drop.  Make my changes.  Check each change in.  New version of Mame comes out, baseline it.  Merge .

I started this project on .102 and have merged 3 times since with little problem.  If a drastic rewrite of some component occurs, I'll have to do a drastic rewrite too.

I've got another developer that works with me coming on the project so we are going to be setting up a server so we are both working out of the same development tree.  Merging with his changes won't be any different than merging with the next rev of mame.   Although his and my changes will affect less of the overall source.

[RetroBorg]

I've only just come across this thread and haven't read everyone yet but has anyone suggested support for playing against other people on the net? e.g. Kaillera

[Popcorrin]

Then there is always force feedback and network linking for the games that supported it.

[Popcorrin]

MikeQ,  I thought I read a post awhile back that you were working on 3d support for mame.  Is that something you were still planning on or did you put that on the back burner?

[MikeQ]

MikeQ,  I thought I read a post awhile back that you were working on 3d support for mame.  Is that something you were still planning on or did you put that on the back burner?

Something I still want to do.  Need to get all the core features in that we want and then start working on it.

[Tiger-Heli]

MikeQ,  I thought I read a post awhile back that you were working on 3d support for mame.  Is that something you were still planning on or did you put that on the back burner?

Something I still want to do.  Need to get all the core features in that we want and then start working on it.

http://powermame.joymonkey.com/pmwiki.php?n=Features.ModernVidCard

But as Mike said, it's still kinda backburner

[arcadegeezer]

Hi All,

Just come across this thread, tonight and I am excited in what I read. Unfortunately the Homepage for Powermame shows site being updated so I cannot see all of the features that are currently planned or available.

Reading through the threads, am I right in thinking that this will also be a frontend ? or just a super version of MAME for use in a frontend ?

I am thinking about building a new USA style cocktail table and was wondering if a configurable frontend could be designed to rotate to the side of the controls that the user touches ?

i.e. specify how many sides/orientation the controls are fitted to on the Cocktail Table.

For instance:- 3 sided controls, vertical Orientation @ ends for verical games (screen flipping), horzontal orientation for horizontal games (2 players on same side.

Also the menu Choices could change or flip depending on the controls that were touched.

Show horizontal games when horizontal controls moved, etc.

Thanks 

Mark

[Tiger-Heli]

Hi All,
Just come across this thread, tonight and I am excited in what I read. Unfortunately the Homepage for Powermame shows site being updated so I cannot see all of the features that are currently planned or available.

http://powermame.joymonkey.com/pmwiki.php?n=Main.HomePage

Reading through the threads, am I right in thinking that this will also be a frontend ? or just a super version of MAME for use in a frontend ?

Yes!    The command line version is super for use in a frontend - the MAME32 version basically includes a frontend - just like regular MAME.

I am thinking about building a new USA style cocktail table and was wondering if a configurable frontend could be designed to rotate to the side of the controls that the user touches ?
i.e. specify how many sides/orientation the controls are fitted to on the Cocktail Table.
For instance:- 3 sided controls, vertical Orientation @ ends for verical games (screen flipping), horzontal orientation for horizontal games (2 players on same side.

That can pretty easily be done now with standard MAME.  See this thread: http://forum.arcadecontrols.com/index.php?topic=45609.0

Although I suppose it could be added to PowerMAME - hardest thing would be deciding whether it should rotate right or left for Player 1 on the Vertical games.

It would be up to MikeQ to decide whether or not to implement this, and I don't think it would be top priority for him.

IMHO - since it can be done with most any MAME build, I think a better solution would be for you (or Com[Plex] or SpyStyle or . . .) to come up with a small program that would ask:
1.  Input your MAME directory:
2.  Do you want the front-end to rotate also, or just the games?
3.  If #2 was Front-end also - are you using I-rotate, or Pivot Pro, or just the graphics HotKeys and input the keys you use.
4.  Should MAME start with a vertical game orientation or a horizontal orientation?
5.  Should MAME rotate CW or CCW for single player vertical games (if horizontal default) or horizontal games (if vertical default)?

Then once all this was inputted, the program would parse MAME and generate -ror or -rol entries for the vertical or horizontal games.

The good thing would be you could run this program with any version of MAME and it would set things up for you.  It should be pretty simple to code, although I couldn't figure out how to do it.   

Also the menu Choices could change or flip depending on the controls that were touched.
Show horizontal games when horizontal controls moved, etc.

That's a new idea that I hadn't heard before.  Tougher to implement, though!

[swindus]

I am thinking about building a new USA style cocktail table and was wondering if a configurable frontend could be designed to rotate to the side of the controls that the user touches ?

i.e. specify how many sides/orientation the controls are fitted to on the Cocktail Table.

For instance:- 3 sided controls, vertical Orientation @ ends for verical games (screen flipping), horzontal orientation for horizontal games (2 players on same side.

Also the menu Choices could change or flip depending on the controls that were touched.

Show horizontal games when horizontal controls moved, etc.

Thanks 

Mark

MaLa can rotate itself (and MAME if you want) and load a game list depending on the controls that were touched.
http://mala.arcadezentrum.com/controllerdetection.html

[Tiger-Heli]

MaLa can rotate itself (and MAME if you want) and load a game list depending on the controls that were touched.
http://mala.arcadezentrum.com/controllerdetection.html

Wow - that's pretty cool! 

[mr.Curmudgeon]

Wow. Hadn't seen MaLa before....(not that I've been trolling the software forum much lately)

Looking good.



mrC