PowerMAME - New Derivative Build

[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.