CP Button Colors for use with LEDWiz RGB LED's (colors.ini)

[headkaze]

I was wondering if anyone is interested in helping create a buttons.ini file that has the RGB values for CP button colours to use with LEDWiz with RGB LED's. This file can then be used by FE's to set the colours of buttons to match the real life CP colours.

It would be a pretty big job, so I designed a program to help automate the process. Post here if you are interested in helping out.

What is required...

- Downloading the full set of cpanel png's from Mr. Do's site here
- Extracting all the png's into the cpanel folder of ButtonsIni Maker

The program works by allowing you to browse through each CP showing any available controls.ini info on what the buttons are. You can either click on the actual buttons in the CP's photo and it will read the button colour. Or you can use one of the colour swatches, or colour selector. This is about the fastest way I could think of doing this.

[loadman]

Nice idea...
    Very sexy

I can help you right now (I've taken on too much already (not just here))

....  But maybe in a month   

[edge]

Count me in... right after the holidays... 

Nice little app!

[headkaze]

Yeah it is very busy over the holiday season.

Okay I'll bump this thread next month.

[screaming]

headkaze:

 Good idea! Not only for those who have RGB button lights but for doing fancy stuff with johnny5 or whatever.

  I wonder if there's a better way to go about it though, rather than making - yet another - ini file?  Maybe the folks who own the controls.dat project, for example, would be interested in integrating button colors?

  The app is a good start too and will make organizing the information so much easier. It's a little buggy though.. do you plan on improving it?

[headkaze]

Howard has already said they have no plan on adding Colour info to ControlsDat. It would also increase the file size substancially. It wouldn't be hard to integrate the data into ControlsDat, I just don't think it's worth doing considering the use of colour info would only be for a few applications.

It probably does have a few bugs, and I am certainly open to ideas on how to improve it, so please post any bugs,  problems or ideas here. I forgot to say that in the first post.

[screaming]

Man, I wonder how hard it would be to put all these ini files into one monsterous ini file?  It would be a chore to keep updated, but it might be worth it for the newbs, I think.

Anyway, I saw a couple problems in the first 10 seconds of using your program:

- The button.ini didnt get saved with the new color info (in fact, I think it zero'ed out) when I was using the color selector to select the color (you know, the crosshairs on the image). It wasn't until I selected th color by using the array of color buttons that my button.ini got saved.  It may have been a coincidence, but there is SOME case where the button.ini isn't getting saved because it definitely wasn't at first.

- When you click on a romname on the bottom left and if you've changed some colors with the previous rom, it should either save automatically or let you know that you haven't saved it yet. If I'm going down 1000 ROMs, I don't want to have to click Save every time.  Maybe a configurable option?

[headkaze]

Man, I wonder how hard it would be to put all these ini files into one monsterous ini file?  It would be a chore to keep updated, but it might be worth it for the newbs, I think.

Anyway, I saw a couple problems in the first 10 seconds of using your program:

- The button.ini didnt get saved with the new color info (in fact, I think it zero'ed out) when I was using the color selector to select the color (you know, the crosshairs on the image). It wasn't until I selected th color by using the array of color buttons that my button.ini got saved.  It may have been a coincidence, but there is SOME case where the button.ini isn't getting saved because it definitely wasn't at first.

- When you click on a romname on the bottom left and if you've changed some colors with the previous rom, it should either save automatically or let you know that you haven't saved it yet. If I'm going down 1000 ROMs, I don't want to have to click Save every time.  Maybe a configurable option?

There are practical issues to having one big file, for example, the larger the file obviously the longer it takes to search, read and write things to it. Less files or one big file isn't aways better IMHO.

Thanks for your feedback. I'm not sure if what your saying is a bug because the only time info is saved to the ini file is when you click the save button. I think an auto-save option would be helpful though.

[screaming]

How many FEs out there don't load the files in their entirety into memory and "search" the file when they need info from it?  It would be hella slow if they did, even with the relatively small size of the files now.

It won't save the FE anything, or even make it worse for them. It woul djust make it easier for people to stay current, and the newbs would have an easier time understanding what it all does.

The first one is definitely a bug. Even clicking the Save button didn't save the colors.

[headkaze]

Thats a good point I suppose, but either way it won't be hard to combine buttons.ini with controls.ini if we decide to, the important thing is we get the colours in buttons.ini first.

I don't understand this bug of it not saving, I can't seem to replicate it.

[rockin_rick]

I think that this is an excellent project.

I see a few different methods and potential issues with this that perhaps can be discussed before a lot of work collecting data has been done.  Let's make sure that the best method is used and the most accurate data is collected and retained.

You can either click on the actual buttons in the CP's photo and it will read the button colour. Or you can use one of the colour swatches, or colour selector.

Is your app converting all sampled (eyedroppered) data into normalized colors (as if you'd picked the nearest swatch), or is it saving the raw RGB (or whatever) 16M shades of data?  Reading your post, I got the impression that it is saving raw 16M shades if sampled, and saving the raw 16M shades of the swatch if the swatch is selected, no?

I think that if (reasonably) accurate samples of all button colors of all games' control panels could be obtained, then the actual data should be recorded.  However, not every games' control panel will have a reasonably accurate picture of the color, so there will have to be approximation sometimes (either sampled data that is not quite right, or a user selected swatch).  Since this is the case, perhaps a set (say 16-32) different colors should be 'standardized' and ALL recorded color data should be of one of these 16-32 colors.  This would make the action of the eyedropper sample the color, then convert it to the nearest swatch (with user verification), then save the data of the swatch. 

Adding to the argument of not saving actual sampled color data, what is the chance that even if the color of the photograph was accurate, that the LED-Wiz can accurately reproduce it? 

Personally, on my own cab, I'd want ALL button colors normalized.  Especially since I have no idea of the accuracy of the reproduction of the sampled data or the accuracy of the sampled data itself. 

Rick

[rockin_rick]

Another issue/potential for error is with games that use different colored buttons and how to decide which buttons on the CP to assign to what button numbers.  I assume that the best/only method is matching the buttons to the default MAME button assignments.  Is there an easy way to ensure that the correct button in the CP pic is saved in the right slot?  Take Defender, for example.  Unless you are familiar with the game, it's hard to know just which button is 1, which is 2, etc.  OK that may be an easy game to figure out for some people, but there are lots of less popular games that would be harder.  How do we ensure that button 1's color isn't transposed with button 2's color?  The only way seems to be have the person recording the data, start the game, and determine the default button assignments, and then exit the game and record the data.  Seems tedious, and likely to deter those willing to collect data, or at the least, really slow the progress...


Rick

[headkaze]

rockin_rick: You raise some excellent points, many of the ideas you've presented I've actually thought about, and agree with most of them.

1. Where can I get a set of colours for all the colours of buttons? The swatches are colours ripped from XP's Paint program which is obviously not the best set of colours. If I can find the most accurate representation of most colours of buttons I can make the swatches match them.

2. Normalizing the colours picked from the eyedropper can then be matched with a colour from the swatch. Not sure how an algorithm like that would work, but this is definately the way to go.

3. With the above two ideas implemented we could then have colour names rather than R,G,B colour values. But without point 1 and 2 in place this will be difficult to do.

Currently I have a saturation slider that brings out the colours in the image more. But like you say many of the images are bad quality and don't help. This is why I am asking for ideas and help on this project. If anyone can help with points 1 and 2, I will put them into the program and then we can either find someone to collect the data or split up the work between a bunch of people, doing a cpanel pack each or something.

Also, like you, I have no idea which button matches what colour on the CP (I was hoping someone on here would), and you may notice that many CP's don't have matching data in controls.ini. Perhaps I need to read in Mame's xml data to check for the parent ROM in controls.ini too. The problem is I do not have much knowledge about these things. Also like you say, who knows how the buttons are matched in Mame, and who knows how Mame and controls.ini decides which is button 1, button 2 etc. Is it from simply a matter of reading the buttons from top left along each row to bottom right? These things we need to find out.

It would be great if Howard would help with this project, but he has not been around here for a while. I'm betting he could answer most of these questions.

[Howard_Casto]

I have a buttons.ini format that is included in the last j5 beta.  It doesn't have any "real" entries but it is definately a starting point.  Basically it is exactly the same as a controls entry, just with color data rather than labels.  So to make an entry for a game you find it in controls.ini copy the entry and turn the labels into color data. 


Right now it's on a 48 degree scale (the amount of degrees of color the ledwiz can do) but it could be converted to 255 easily.  Also j5 has a built in "black converter" since black is an impossible color you can reroute any buttons that show up as black to the color of your choice. 

[Howard_Casto]

In case you are wondering, yes that is an overly complicated format just for colors.  But I do it that way for a reason..... your cp viewer app is probably going to be the app that lights your panels as well.  By linking the two files it makes it real easy to set the color and caption.  In the case of j5, that means buttons that have moved around will still be lighted properly. 

[headkaze]

I've just been reading about what you've already been doing with buttons.ini/colors.ini. Just found the ControlsDat forum for the first time also.

I'm not sure if there is enough motivation to get all this work done. I don't even own a LEDWiz, but I've written a plugin for GameEx to support it. It's currently got some interesting Attract Modes for it including Audio (Dancing to music) and Plasma modes as well as standard lwa support. I've managed to get this far without owning one, but I don't really see myself spending the hours to create the buttons.ini file.

If someone wants to volunteer to do it, I can finalise the program to suit their needs. Although there seems to be enough interest, I don't know if there is anyone that is actually willing to go through and create all the colours for the file.

BTW Howard, once this file is made, we can decide exactly what format to go with and write a little program to convert it. (Eg. If we want to go with 48 degree scale, then we can convert the colours to that etc.)

[Howard_Casto]

Actually this isn't true hk. If you want the colors to be linked to the controls.ini it HAS to use those input constants right now or else you'd have to completely re-do the entire thing manually when it came time to convert. Yes the degree of color can easily be changed but the rest can't.

Why in the world did you start this thread if you aren't willing to make it?  I'm sure not going to, I made that pretty clear, I just wrote the format that should be used (and the only one j5 is gonna ever support because it is the only thing that'll work). 

The controls.ini itself is in dire need of an update so I simply can't tackle another project of it's scope.

[headkaze]

If you can post a few examples of the format, it would help. I've looked at the J5 source (latest beta from ControlsDat forum), and can't find any examples of how it works.

Why in the world did I start this thread? Because I am writing a software tool that will help creating buttons.ini/colors.ini much easier (my guess by hours to days of work). But I have no motivation to create the actual data file because I don't own a LEDWiz and have no interest in buying one. But I have written a LEDWiz plugin for GameEx as I mentioned, which will make use of the dat file if someone creates it. GameEx has a built in CP viewer, so I have not personal interest in J5 per say, but I do think we should keep a standard, and since you already work with controls.ini I'm happy to go with your format.

I have enough on my plate too, and this is the sort of thing that takes time to create not coding skills or anything like that. So pretty much anyone with some time and dedication could contribute to the scene by working on creating this dat file. If noone wants to put up thier hand I'm quite happy to forget I even mentioned the idea, but there seems to be alot of interest in making it happen, it's just noone wants to put up their hand to do it yet. What is the saying 20% of the people do 80% of the work?

[Popcorrin]

Why would the buttons.ini need a 48 degree color scale?  How many different colors of buttons were ever produced and how would a person get accurate information of the exact color of red that was originally installed on a particular game. 
   I was thinking that 3 intensities of each color would be sufficient; for instance, light red, red, dark red. 
   Then the end user would have a setting they could adjust for each color so that what shows up on their control panel is consistent to what is called for.  Because differences in leds and transluscent buttons will produce different colors.

Just a few thoughts I had.

[Buddabing]

Not very different colors were produced, but there's no way to match the color without a higher number of bits per color than just two or three.

Matching the color scale to the number of outputs of the LEDWiz is a bad idea because you throw out most of the color space. Plus, LEDs vary from batch to batch and manufacturer to manufacturer. So one person's red may not be another person's red.

The proper way to do the buttons.ini is to have a 24-bit color space and to somehow calibrate the actual color of the button to the RGB color space, not to any LEDWiz output. At that point, a developer wanting to light up buttons can then map the RGB space onto the controller. Due to the variations between LEDs, there should be tweaks available to the end user to adjust colors. I can see calibration being an issue, as well.

If there are computer screens capable of more than 24 bits per pixel, I don't know of any. So 48 bits per pixel is probably unnecessary.

[Howard_Casto]

Well it isn't implemented, but j5 and the colors.ini will also support "keywords" because I thought of that. 

Much like the black replacement, there would be color names instead of actual rgb vaues that will also be supported.  So in-theory, most of the time an entry would have "red" "green" and "blue" instead of 255,0,0  0,255,0 and 0,0,255.  Then it would be up to the individual app to have some sort of calibration configuration file that stranslates it into values that releate to that individual user. Straight rgb values would only have to be used in extreme circumstances.  But color values are easy to manipulate because there are only like 10-15 "standardized" colors of buttons available and 90% of the time it'll be r,g,b or white. 

Actually I'll go ahead and list as many as I can think of I have actually seen.

Red
Green
Blue
White
Black
Yellow
Orange
Light Blue
Light Green
Purple
Light Purple
Brown?
Pink?

Except for odd-ball colors like translucent buttons I think that covers it.  They are all the same color as there were really only two button manufacturers so it'd be real easy to cross-convert.

I don't think pixel perfect color-matching is really an issue because any output method we have to displaying the colors (including the monitor you are reading this on) is gonna be a little off.

[headkaze]

Ok, I've added color matching for the Color Picker from a palette of swatches. It now saves using the Color name (ie. Red instead of 255,0,0 etc.) but it will also support saving in R,G,B if necessary.

Okay I have some questions for Howard before I finalise the software.

1. The current colors for the palette are as follows:

Black
White
Red
Yellow
Orange
Lime
Green
Cyan
Blue
Purple
Violet
Magenta
Brown

Basically the colors you defined Howard, but better system color matches for Windows. Are these okay, do I need to change any (you can view the swatches in the attached screenshot)? Do you think we need more colors?

2. Currently I write buttons.ini as follows:

Code: [Select]

[1942]
P1_COIN=White
P1_START=White
P1_BUTTON1=Red
P1_BUTTON2=Red
P1_JOYSTICK=Red
P2_COIN=White
P2_START=White
P2_BUTTON1=Red
P2_BUTTON2=Red
P2_JOYSTICK=Red
You say this is incorrect. What is the correct format then? I find controls.ini quite a complex beast so forgive my ignorance. A detailed explaination would be great so I don't mess up the format you've designed.

3. What should we call it, buttons.ini or colors.ini? I was undecided myself, but when I found your posts about this I noticed you went from buttons.ini to colors.ini.

4. Do you think we should have a calibration file standard that goes along with buttons.ini/colors.ini?

Eg.

Code: [Select]

Red=48,0,0
Green=0,48,0

Or should we just leave that up to the application coder?

5. I have the CP collection from Mr Do's site, but I assume they are not all parent ROMs. Does that mean I will need to read in Mame.xml to get the parent ROM name to match in controls.ini so I can display control names for all CP's?

6. Using controls.ini will help match the actions to the buttons on the CP so the colors are right. I noticed that P1_BUTTON1, P1_BUTTON2 etc don't necessarily go from left to right on the CP, and some CP's don't clearly show the action. In this case, how will you know which color goes to what button?

Here is a screenshot in it's current form with the auto color matching for the swatches. Once we finalize the format I can finish up the program.

[Howard_Casto]

You are over-thinking it hk.... you don't have to know the format at all. 

All you have to do is have a app that reads the controls.ini.  When you wanna make a color entry it literally copies the entire entry, blanking out the label portion, allowing the user to fill in colors for all of them.  Just as an example, you aren't putting in the joystick entries... joysticks (and the cpo labels on joysticks) aren't all the same color you know, so that data has to be included as well.  And yes I know it's a little redundant to have four color entries for a joystick, but what this does for us is makes a physical link to each label, so a viewer can write the text in that color, for example.

Wanna do a game that isn't in the controls.dat project?  Well you can't, which is a good thing, because if you have a pic to know the colors, then it needs an entry filled out. 


I've called mine colors.ini because it is more accurate as it'll also store the color of the joystick, flightstick, trackball, ect....


Button_1 and Button_2 are arbiturary names that have no influence on the buttons position on the user's control panel.... what does is what real world key they've binded that function to, which is why it needs linked to the controls.ini  And if by "not clearly show the action" you mean the description can't be read then that game doesn't have a controls.ini entry and therefore we don't want it in colors.ini anyway until enough data is found. 

Start and Coin buttons aren't supported in controls.ini, but I don't see any reason why you can't add them for your purposes.  They don't move around much on a user's cp so a static position can be used. 


About your color constants......  Having an art background myself I don't mind precise color names, but the one's you've given are what I call "paint store" color names and have no real reflection on the actual color.  For example purple and violet are the same color, purple is just another word for violet.  Now on certain color wheels they'll be in different positions but they are the same color.  You can describe a base color by mixing it with another color (blue green) or by describing the tint or shade (light blue).  Also people tend to get cyan and magenta mixed up (why I don't know) so those words can be interchangeable.  Sorry about being picky on that it's just one persons lime is another person's avacado. 

Honestly, I don't think calibrated color swatches are even necessary.  Mind you they are nice, but if you get the labels right I think people will figure it out as long as it's close enough.  Just gotta use "stupid" terms for the colors.  I will say this though... system colors are generally blends and our "off" colors are gonna be tints, such as light blue.... it is the same color is blue, just lighter.  The light blue looking color in the system pallette actually has more green in it.  The best way to do the color swatches is manually.... we want our blue to be 0,0,255 just to make things easier and to get our light blue we can just up the other two values equally until it looks about right.  The extended pallete has tints and shades (and some blends closer to the base colors we need) though so that'll work, but the 16 base colors windows has probably won't. 


I think a simple calibration standard thrown in the docs somewhere is a good idea, just because what I mentioned above and this will give developers an idea of what the color is actually supposed to be.  It needs to be a 255 base though and custom colors need to be a 255 base.  This can easily be down converted for ledwiz ect, but it'd be good to get as much detail as possible for graphical applications. 


Hope that helps and don't think I'm getting snippy, I just want to get it done right before you begin.  Nobody talks about the two months sirp and I bickered back and forth until we decided upon the controls format. 

[headkaze]

For now rather than place the colours into a copy of controls.ini I've made a separate file called colors.ini with just the color info. I've kept my color names just so I can get the data done, you can always find/replace them to whatever you want. For now this suits my needs and if you process my colors.ini to the format you want (you may only want parent ROMs for example), so you could make your own modified version and release it for others to use.

Why would you want your J5 viewer to display text labels in the color? Why not have the button in the right color? All you have to do is use Photoshop's hue rotation to make a button for each color.

I've used BUTTON_1 and BUTTON_2 etc., but I've matched them with controls.ini. I've also used data from the ListInfo.xml such as romof, players and buttons so some colors are guessed that way. I've tried to do the colors for all CP's from Mr Do's collection including ones missing from controls.ini. Some are guessed, some are obvious etc. But these can all be fixed in the future.

The color names are not really important, since they will be calibrated to the LEDWiz to mean anything, so you could in fact change Red to be Blue if you really wanted to. Using Windows color names just makes the software easier to write.

Now to the nitty gritty, I've spent a number of pain staking hours (my mouse hand is sore as hell and my back is aching as you could imagine). I've done the colors for a bunch of ROMs but I am going to go through them all and double check them and maybe add a few more that I may have missed. But in general I've done 99% of the ones that I could. Some have labels too hard to read. Another problem was light blue and dark blue / orange and yellow etc. are sometimes very hard to distinguish between - some are just guessed. But anyways, it's not really something that has to be perfectly right.

Now that most of it is done, you can batch process it, search/replace color names etc. or combine it into a controls.ini type file or whatever you want. The important thing though is that the hard part is done. The software I wrote has saved me alot of time too. I added Copy and Paste, and sorting features etc. All helped make the process a bit quicker.

Perhaps you'd like to go through and check the colors with the software? Otherwise once I've gone through and checked them all again, I'll post colors.ini here soon.

colors.ini stats:

- 1210 ROM colors defined
- Uses color names from a set palette of 13 colors
- Size 248 KB

[Popcorrin]

What do you think of adding the joystick colors since you can currently get color adjustable joysticks?  Even trackballs for that matter?

[Howard_Casto]

What do you think of adding the joystick colors since you can currently get color adjustable joysticks?  Even trackballs for that matter?

I mentioned that and hk seems to have ignored it. 


Btw hk color names ARE important.  Why?  Because you are making a app to let other people make entries and thus they have to know what color the names represent.  I can argue that getting the color names correct is the most important thing in the whole project. 

The text labels were just an example.  J5 will make the buttons the corect color, but the exact same formatting is needed to do so. 


I'm not sure what you meant by putting the color data in the controls.ini either, I never suggested that.  I said rather than worrying about the formatting you read the controls.ini to get the control name constants to the game.  Of course you would save that data to a seperate file or else it'd interfere with the label data. 


It looks like you have went to a ton of trouble to do the entires yourself.  We all appreciate it, but since it sounds like you didn't fill out all the data (joystick color, color of the trigger buttons on the flight stick, trackball color, ect) then it's just going to have to be re-done all over again. 

I had over 400 entries done on the original controls.ini before sirp got the database up, we decided to change some things, and it ended up being worthless.  The formatting is by no means trivial and that kind of thing needs to be finalized before the first entry is made.  If figured by just telling you to use our format it'd save yourself and everyone else the headache or repeating my error but as usual nobody listens to me. 

[headkaze]

I didn't ignore it, the colors I've defined are for:

Px_COIN
Px_START
Px_BUTTONx
Px_JOYSTICK
Px_TRACKBALL
Px_DIAL
Px_PADDLE
Px_STICK
Px_LIGHTGUN

So it does include trackballs and joysticks.

Color names arn't important, because you can change "Lime" to "LightGreen" by doing a search and replace on the colors.ini file. That's what I mean by them not being important. The hard part is out of the way, and that was to go through and do all the colors. Now we can write a script to change the color names, remove clones or whatever.

I have listened to you Howard, perhaps you need to see the file first before you write it off as useless. I've tried to put everything you mentioned into it. The only thing I missed was changing the names back to your suggestions, but that's because my program uses the Window's names in the code. Like I said a simple search and replace can fix that.

Feel free to check out the program with colors.ini attached below. You will need to point it to your Mame Exe to get some of the clone info or from CP's missing from controls.ini. Also, it only saves when you click Next and Back buttons.

[Popcorrin]

Wow headkaze, great job!   I need to get my butt in gear and finish up wiring my control panel so I can test this out.

[headkaze]

I hope you have RGB LED's.. there is much to test then

[Howard_Casto]

I didn't ignore it, the colors I've defined are for:

Px_COIN
Px_START
Px_BUTTONx
Px_JOYSTICK
Px_TRACKBALL
Px_DIAL
Px_PADDLE
Px_STICK
Px_LIGHTGUN

So it does include trackballs and joysticks.

Color names arn't important, because you can change "Lime" to "LightGreen" by doing a search and replace on the colors.ini file. That's what I mean by them not being important. The hard part is out of the way, and that was to go through and do all the colors. Now we can write a script to change the color names, remove clones or whatever.

I have listened to you Howard, perhaps you need to see the file first before you write it off as useless. I've tried to put everything you mentioned into it. The only thing I missed was changing the names back to your suggestions, but that's because my program uses the Window's names in the code. Like I said a simple search and replace can fix that.

Feel free to check out the program with colors.ini attached below. You will need to point it to your Mame Exe to get some of the clone info or from CP's missing from controls.ini. Also, it only saves when you click Next and Back buttons.

I looked at it and it needs redone before you go any further because, right now at least, it can be fixed with a conversion macro, but later it can't be. 

You haven't defined a exact mirror of the labels on the controls.ini and this is absolutely required even though it's a bit redundant. 

let me give you an example:

Right now you have an entry with p1_joystick=black.  That works great for the "normal" entries, but not the oddball ones.  Some games use the up/down for one joystick and the left/right for another and define them input-wise as a single joystick.  So lets say one of em is red and the other green... with your setup you can't define em.  Also you come to the problem of users doing crazy things when they re-map.  A user might have their panel setup that way, in which case we have no clue what to color.

Basically you want to have that redundancy for two reasons... it makes things simpler for the programmer (they can use the exact same search routine for colors they did for controls and if they found controls they don't even have to parse control data in colors because they know exactly what to look for, which adds speed) and it allows room for really wierd stuff going on, like I mentioned above.  Also you haven't defined a control type, which makes it impossible to search colors.ini in the event a programmer would want the color data but not the control data (why I dunno, but hey, it could happen). 

The color part is debateable, I really don't like your choices but it isn't the end of the world if we disagree on it. 

What I'm saying is, right now it looks great and it'll work, but these things I've mentioned are gonna come up eventually and it'd be better to just go ahead and fix em now before the thing gets complicated and it becomes impossible to back-track. 

If I've sounded mean I'm sorry... caught a bit of a bug and it's made me crankly lately.  I still mean what I've been saying though, I just probably could have said it in a better way.   

[loadman]

I still mean what I've been saying though, I just probably could have said it in a better way.

Howard's Catch Phrase? 

I kill me

Seriously, hope you feel better soon 

[headkaze]

I looked at it and it needs redone before you go any further because, right now at least, it can be fixed with a conversion macro, but later it can't be. 

You haven't defined a exact mirror of the labels on the controls.ini and this is absolutely required even though it's a bit redundant. 

let me give you an example:

Right now you have an entry with p1_joystick=black.  That works great for the "normal" entries, but not the oddball ones.  Some games use the up/down for one joystick and the left/right for another and define them input-wise as a single joystick.  So lets say one of em is red and the other green... with your setup you can't define em.  Also you come to the problem of users doing crazy things when they re-map.  A user might have their panel setup that way, in which case we have no clue what to color.

This is what happens when someone who know's nothing about CP's does this. You could have given me a proper example when I asked for one in the first place. Would have saved any redoing what has to be redone. Right now it's perfect for my needs which is in the plugin I'm writing. In fact I'm not even sure if your example warrents a change. How many people do you think will have an RGB LED setup for JOYSTICK_UP, JOYSTICK_DOWN, JOYSTICK_LEFT or JOYSTICK_RIGHT? That's 12 outputs for just one joystick. Most people will have one RGB LED for each joystick, meaning JOYSTICK should be enough right? In fact both GameEx and Mala plugins only allow you to define one RGB LED for one JOYSTICK.

I don't take into account wierd key mappings in the plugin, that is where my understanding of controls.ini fails. The way I see it, if they change the controls in Mame, they can always remap their LEDWiz outputs to match. Either way, I would have no idea how to change around mappings if they did remap.

Basically you want to have that redundancy for two reasons... it makes things simpler for the programmer (they can use the exact same search routine for colors they did for controls and if they found controls they don't even have to parse control data in colors because they know exactly what to look for, which adds speed) and it allows room for really wierd stuff going on, like I mentioned above.  Also you haven't defined a control type, which makes it impossible to search colors.ini in the event a programmer would want the color data but not the control data (why I dunno, but hey, it could happen). 

I always thought of colors.ini as defining color data only. If you need to know the control type look up controls.ini instead. Again though you can write a program to read in controls.ini and write out the control type into colors.ini if you want. Currently colors.ini suits my needs (and probably Mala's plugin aswell), but if you want to make colors.ini into a standard then your welcome to do that. It's not difficult to do.

The color part is debateable, I really don't like your choices but it isn't the end of the world if we disagree on it. 

What I'm saying is, right now it looks great and it'll work, but these things I've mentioned are gonna come up eventually and it'd be better to just go ahead and fix em now before the thing gets complicated and it becomes impossible to back-track. 

Again, I'm not sure how many times I've said this, the color names can be searched and replaced to anything you like. It would take a few seconds in Notepad to do that. Remember your creating the standard, I've created colors.ini for my plugin. So you can batch convert it to any way you want. Once you give me a _detailed_ list of changes, I can change the software to suit those changes. Then we should only need to add new CP's as they arrive. But I really think you should change my colors.ini to the way you think it should be, rather than have me trying to guess the way you want it. Unless you give me a _detailed_ list of every entry type there should be, I'm still having to guess exactly what you think should be in there. So it's best you modify it to suit your taste.

Don't get me wrong, I think your version should be the "standard" and the one released to public, and the one and only one that gets updated. So I'm willing to help make the changes you want.

If I've sounded mean I'm sorry... caught a bit of a bug and it's made me crankly lately.  I still mean what I've been saying though, I just probably could have said it in a better way.   

You don't seem any more candid than usual. There's no need to sugar coat anything with me anyway.

[Howard_Casto]

Again Man, you are over-thinking it.....

The app should read the controls.ini manually first (there isn't any other easy way to do it), line by line and copy every single solitary line for that entry into the colors.ini except leave the values blank.  The values should now be color values that your application fills in, replacing what were captions.  You don't need to know the format at all, I can teach it to you but it isn't necessary.  If the lines match pefectly then you can even ditch the "control type, number of players, ect..." lines in the entry assuming you are requiring the addition of the controls.ini to read the data. 

If you want it to be stand-alone they have to be included because:

The control type data tells the viewer which "p1_up, ect" lines to query. 

The # of buttons tells the viewer how many buttons to query

Simultanious play and mirroredcontrols tells the viewer if there are controls for each player and if so if they are the same controls or are different. 

All mala does is print out the data without any bnding to physical objects, but viewer applications (and applications that light panels based on your mame settings) are going to have to "build" a "virtual panel" to figure out what to light because the controls.ini format isn't literal to save space and your current format doesn't have any lines that tell the viewers what is in the entry, meaning they have to manually parse each line via "line input" which is slow. 


I don't see anything wrong with keeping the two dependant upon each other as long as you make it clear that they are constructed that way.  They can be merged programatically if someone ever has the need and it does waste some space.  However the key/value relationship still has to be identical.  In other words you can't make up your own constants, you need to use ours.  None of this "P1_Joystick" stuff, it needs to be "P1_JOYSTICK_UP", down ect.   At the very least it needs to be "joy8way" or "joy4way" as those are constants the file uses and joystick isn't a constant.  I wouldn't reccomend that though because some games like tetris only use three directions and a user might be using the data to light directional arrows on their cp rather than the actual joystick, or something to that degree. 

Making them identical also just eliminates errors.  A lot of people don't understand how we fill the panel based on # of players, if the game is alternating and if the controls are mirrored.  But if you copy it you don't need to know how it works, just that it works. 


One key you probably need to add is "samecolor" or something like that to denote if the different players share the color value.  Games like tmnt only have a player 1 entry in controls.ini because all the captions are the same, but the colors are different, so a viewer is gonna try to only read the first player and fill all the colors out with it otherwise. 

p.s. i'm already seeng some errors in your file.  tmnt for instance has start buttons defined for each player when there are none and all the coin slots defined as white, when they are actually the color of the joystick or red, depending upon the model.  Actually it looks like all the entries have white start and coin buttons tacked on.

[arzoo]

headkaze,
I've been working on my own MaLa plugin for the LEDWiz - originally I intended to use J5 or loadman's plugin, but for various reasons, I decided to roll my own. Anyway, I have to agree with Howard on the colors.ini format - it really should match controls.ini. Here's another example - let's say someone puts 8 LEDs around a digitally restricted joystick. With the controls.ini format, the software could lite the correct LEDs to indicate which axis are active. True, there may not be any cp with this feature, but I recall a thread some time back discussing doing this. My plugin uses the controls.ini and I would love to use your colors.ini also. Any chance you'll reconsider the format?

[Howard_Casto]

headkaze,
I've been working on my own MaLa plugin for the LEDWiz - originally I intended to use J5 or loadman's plugin, but for various reasons, I decided to roll my own. Anyway, I have to agree with Howard on the colors.ini format - it really should match controls.ini. Here's another example - let's say someone puts 8 LEDs around a digitally restricted joystick. With the controls.ini format, the software could lite the correct LEDs to indicate which axis are active. True, there may not be any cp with this feature, but I recall a thread some time back discussing doing this. My plugin uses the controls.ini and I would love to use your colors.ini also. Any chance you'll reconsider the format?

I know of at least one.   I intend on etching arrows on the underside of my plexi and lighting them via leds.  Also lighted joysticks might be nice.  I'd never force a format on somebody that's worked so hard as to make an entire file, but it would be nice if it matched up, for parsing reasons alone.

[arzoo]

Now that I think about it, I'm not sure that the controls.ini format will work for the buttons colors. Take for example a multiplayer, non-alternating game - controls.ini would only define P1 buttons because all player controls are the same. But that may not be the case for the button colors  . Am I missing something here?

I guess what we need is for the controls.ini and colors.ini to use the same control codes. For example: 3stooges

Controls.ini (partial)
numPlayers=3
alternating=0
P1NumButtons=1
P1_BUTTON1=Slap / Throw
P1_JOYSTICK_UP=Up
P1_JOYSTICK_DOWN=Down
P1_JOYSTICK_LEFT=Left
P1_JOYSTICK_RIGHT=Right

Colors.ini
P1_COIN=White
P1_START=White
P1_BUTTON1=White
P1_JOYSTICK_UP=Black
P1_JOYSTICK_DOWN=Black
P1_JOYSTICK_LEFT=Black
P1_JOYSTICK_RIGHT=Black
P2_COIN=Blue
P2_START=Blue
P2_BUTTON1=Blue
P2_JOYSTICK_UP=Black
P2_JOYSTICK_DOWN=Black
P2_JOYSTICK_LEFT=Black
P2_JOYSTICK_RIGHT=Black
P3_COIN=Green
P3_START=Green
P3_BUTTON1=Green
P3_JOYSTICK_UP=Black
P3_JOYSTICK_DOWN=Black
P3_JOYSTICK_LEFT=Black
P3_JOYSTICK_RIGHT=Black

[Howard_Casto]

No you aren't missing anything.  The format would be the same, only the mirrored controls flag would sometimes be diferent, allowing developers to know that each player has seperate entries and thus you'd have to have entries for each player.  Basically, the developer already knows what types of controls to search for, so it'd still be quick to parse, they'd just have to re-check the mirrored flag.

[headkaze]

Yeah I probably will do an update to colors.ini and add all the joystick directions. Also will probably add mirrored controls. It's just a matter of getting time to do it, I have heaps of stuff in the pipeline at the moment and it's not a huge priority right now. The way I see it, if you have LED's for the directions then use the code in controls.ini to light the right buttons for 4way, 8way etc. The problem with relying on colors.ini is that most of the time there is no color info for lighting these LED's on the CP. So you would end up having to guess most of the time. When I went through the entire lot of CP's I remember a handful having colors for the directions and most of the time it was the same color as the joystick. So why not just get the joystick color from colors.ini and light the right LED's for JOYSTICK_UP, JOYSTICK_DOWN etc. using joystick type from controls.ini.

[arzoo]

So why not just get the joystick color from colors.ini and light the right LED's for JOYSTICK_UP, JOYSTICK_DOWN etc. using joystick type from controls.ini.

That's exactly what I'm going to do. If there's no colors defined for a game, I'll use the defaults (as defined in my plugin). When and if you get the time to make the changes to the format, then I'll update my plugin. Speaking of the format, do you have plans to add the Trackball color? With the GGG EI Trackballs, this could be useful.

By the way headkaze, thanks for all your effort on this! 

[headkaze]

Have you checked out the file? It does have colour info for trackballs.

BTW May I ask why your creating a new LEDWiz plugin for Mala? What is wrong with the current one? It's also being updated to version 2, which I expect will include support for colors.ini and MameInterop.