Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up Try the site in https mode Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: Change discussion  (Read 9575 times)

0 Members and 1 Guest are viewing this topic.

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Change discussion
« on: March 21, 2011, 06:11:22 pm »
Howard, I am pulling this out out our PMs because it is easier to keep track of what is going on here.

First assault.  I think something is hosed with the dual 4way.  If you notice the XML output is
  <label name="P1_JOYSTICK_LEFT" value="Left" />
  <label name="P1_JOYSTICK_DOWN" value="Down" />
  <label name="P1_JOYSTICK_UP" value="Up" />
  <label name="P1_JOYSTICK_RIGHT" value="Right" />

Should that be something like P1_JOYSTICKLEFT_LEFT, etc?  I am going to assume that for the made up example below

I don't have the time right now to read the entire PM, but skimming through it I get the general idea.  We might completely redesign the XML since we plan on getting rid of the INI.  Part of the design of the XML was governed by the fact I wanted to generate the xml and ini quickly at the same time in one function.

Maybe we need to rethink the labels.
Right now it is
<labels>
  <label name="P1_BUTTON1" value="Attack" />
</labels>

Maybe a change to
<labels>
  <label name="FORWARD">
    <input name="P1_JOYSTICKLEFT_UP"/>
    <input name="P1_JOYSTICKRIGHT_UP"/>
  </label>
</labels>

Along with that change we could be a little more complete in the XML.  For example.  You know how in the current XML for player 1 we have the controls node like this denoting a button is on a control.  But we :
<controls>
  <control name="8-way Joystick">
    <constant name="joy8way" />
    <button name="P1_BUTTON1" />
  </control>
</controls>

And the looking at the labels node we have this:
<labels>
  <label name="P1_BUTTON1" value="Attack" />
  <label name="P1_BUTTON2" value="Jump" />
  <label name="P1_JOYSTICK_LEFT" value="Left" />
  <label name="P1_JOYSTICK_DOWN" value="Down" />
  <label name="P1_JOYSTICK_UP" value="Up" />
  <label name="P1_JOYSTICK_RIGHT" value="Right" />
</labels>

It isn't exactly obvious where the inputs come from without the FE DEV support files.  However, getting rid of the INI format means we don't need those support files if we put the data into the XML.

I am thinking we could be a bit more thorough.  Maybe something like
<game>
...
  <player number="1">
    <controls>
      <button ID="1">
        <input name="P1_BUTTON1"/>
      </button>
      <button ID="2">
        <input name="P1_BUTTON2"/>
      </button>
      <control name="Dual 4-way Triggersticks">
        <constant name="doublejoy4way" />
        <links>
          <button ID="1">
            <location value="LEFT"/>   <---- dual triggerstick specific otherwise no node
          </button>
          <button ID="2">
            <location value="RIGHT"/>
          </button>
        </links>
        <input name="P1_JOYSTICKLEFT_LEFT"/>
        <input name="P1_JOYSTICKLEFT_DOWN"/>
        <input name="P1_JOYSTICKLEFT_UP"/>
        <input name="P1_JOYSTICKLEFT_RIGHT"/>
        <input name="P2_JOYSTICKLEFT_LEFT"/>
        <input name="P2_JOYSTICKLEFT_DOWN"/>
        <input name="P2_JOYSTICKLEFT_UP"/>
        <input name="P2_JOYSTICKLEFT_RIGHT"/>
      </control>
    </controls>
    <labels>
      <label value="Fire">
        <input name="P1_BUTTON1"/>
      </label>
      <label value="Bomb">
        <input name="P1_BUTTON2"/>
      </label>
      <label value="Forward">
        <input name="P1_JOYSTICKLEFT_UP"/>
        <input name="P1_JOYSTICKRIGHT_UP"/>
      </label>
...
      <label value="Wheelie">
        <input name="P1_JOYSTICKLEFT_LEFT"/>
        <input name="P1_JOYSTICKRIGHT_RIGHT"/>
      </label>
    </labels>
  </player>
</game>

Typing this out already I think there is a better way to organize the controls to handle triggersticks but I have to think it through.  But this should give you an idea of what I am thinking.
Immediately I am thinking
<controls>
      <control name="Dual 4-way Triggersticks" constant="doublejoy4way">
        <hardware>
          <control name="JOYSTICKLEFT">       
            <input name="P1_JOYSTICKLEFT_LEFT"/>
            <input name="P1_JOYSTICKLEFT_DOWN"/>
            <input name="P1_JOYSTICKLEFT_UP"/>
            <input name="P1_JOYSTICKLEFT_RIGHT"/>
            <control name="BUTTON1">   
              <input name="P1_BUTTON1"/>
            </control>   
          </control>
        </hardware>
      <constant="doublejoy4way" />
</controls>

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re: Change discussion
« Reply #1 on: March 21, 2011, 06:13:07 pm »
Basically, maybe we just need to forget about the current XML format and start from scratch, see what we come up with.  I am busy for the next 3 to 4 weeks moving to St Paul.  I'll try to give it some thought during that time.

In case someone reads this I am going to clarify something.  We plan on dumping the ini file format.  When controls.dat was started many many years ago xml wasn't new but fast parsing of xml was difficult.  So we provided the ini format since Windows has built in ini functions that are fast.  That isn't so much of an issue now and the ini file format is very limiting.
« Last Edit: March 21, 2011, 06:27:06 pm by SirPoonga »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19399
  • Last login:March 16, 2024, 05:59:16 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Change discussion
« Reply #2 on: March 22, 2011, 02:22:29 am »
Ok we'll hash it out here then... I would rather have a public record incase any viewer devs want to chime in.  ;)

About the dropping the ini thing.  I think this is the way to go BUT XML parsing is still waaay slower.  It has nothing to do with parsers and everything to do with the size of the files.  I ran a test on parsing a full mame list.xml yesterday using both sax and dom.  Sax took around 30 secs, not slow but definatley a noticable wait.  Dom took over 2 minutes.  That's just unacceptable.  I think the obvious solution is to make individual files for each game.  A small file doesn't take any time to read.  We can either do this on the server end or I can write an application.  I want it optional of course, but I think for slower systems it's a good compromise for dropping the ini. 

Ok getting down to business:

First of assault needs re-done anyway.  It used to have a 4 way (hack) as well as dual trigger sticks.  That's been removed from mame.  We need to ensure that the dual 4way constant is using joystickleft and joystickright though as those are the proper constants.

As for the new format, I thought we could save ourselves and other programmers the headache of learning two structures and just loosely base the new format on mame's ctrlr files.  Not exactly mind you, but close enough.

Rather than explain it, how about an example.  A game with 4-way, black, trigger-stick with a red fire button and a yellow bomb button on the cp.

<game romname="ggame" gamename="Generic Game" numPlayers="2" alternating="1" mirrored="1" usesService="0" tilt="0" cocktail="1">
   <Control name="4 Way Joystick">
      <Constant name="joy4way" color="black">
         <input name="P1_Joystick_UP">Up</input>
         <input name="P1_Joystick_DOWN>Down</input>
         <input name="P1_Joystick_LEFT>Left</input>
         <input name="P1_Joystick_RIGHT>Right</input>
      </Constant>
      <input name="P1_BUTTON1" color="red">Fire</input>
   </Control>

   <input name="P1_Button2" color="yellow">Bomb!</input>

   <MiscDetails>
   This game is really cool!
   Note the use of multi-line!
   </MiscDetails>

</game>

Basically I'm going back to the original discussion we had about the dat all those years ago.  We break down controls first by their real world name, then the mame control constant(s) that they are made of, then the individual inputs.  For inputs like buttons and the unbinded labels, where they are ungrouped, we don't bother with the control/constant grouping as there isn't any.  For the advanced parser, the location of the label immediately lets them know the relationship of the individual inputs and for the lazy parser, you just have to read the game entries atts and then pull the values off of any node labeled "input".  I'm not sure about the color btw.... I'm confident that it needs to be attribute as we are using a pre-determined set of constants and it has to be linked to an input anyway, but I'm unsure if allowing the option of just coloring the whole constant, like I did in my example, is a good idea.  Actually it's probably best to just do each input (I was trying to save space.)

As for special unbinded inputs they should look something like this:

<input name="P1_JOYSTICK_UP/_LEFT" color="yellow" type="unbinded">Jump Back</input> 

It doesn't really matter to me if we group them with the real inputs or put them in a special place, they just need a att telling parsers that it's NOT a real input but just a label.  I thought we would still call them an "input" though just to make it easier for parsers to look for them.

Btw I see what you are saying with your examples, but you are linking a label to inputs.  We need to link inputs to labels so that we can "build" the control groups and constants in the entry and show their physical relationship. Or at least that's what I think, considering we have to parse MAME's ctrlr/cfg files and link up inputs to labels.  With my structure each input gets a unique name  att anyway, so in theory at least, we shouldn't have the overlap problem we had before.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19399
  • Last login:March 16, 2024, 05:59:16 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Change discussion
« Reply #3 on: March 22, 2011, 02:33:14 am »
Oh one more thing....

In addition to the "color" attribute, we might want to consider adding "text_color".  Color refers to the color of the controls, but we could have text_color to refer to the color of the writing on the cpo.  But then again it would probably be useless in viewers as people would have their own background images.

But that's why I think making the Label text the Node's text and putting the color as a mere attribute is a good idea.  The label is always going to be there and anything we add is going to probably be constant based.  In terms of expansion down the line, adding a ATT would be far easier than re-organizing the structure.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19399
  • Last login:March 16, 2024, 05:59:16 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Change discussion
« Reply #4 on: March 29, 2011, 03:54:33 am »
Well we have something new to worry about.  The "driver configuration" menu. 

I was going through the dat to clean up some entries when I took a look at how they handled 720 degrees.  It's very slick, but it sure does complicate our job even further. 

You have a new menu item called "driver configuration" in which you can select between joystick, generic spinner, or real 720 spinner controls.  Changing this setting turns on and off the various inputs.  Here is a sample 720 cfg file (I added an input or two from each selection so we could see what was going on.)

Code: [Select]
<system name="720">
        <video>
            <target index="0" rotate="90" />
        </video>
        <counters>
            <coins index="1" number="44" />
        </counters>
        <input>
            <port tag="LETA0" type="P1_DIAL_V" mask="255" defvalue="0">
                <newseq type="increment">
                    KEYCODE_Q
                </newseq>
            </port>
            <port tag="LETA1" type="P1_DIAL" mask="255" defvalue="0">
                <newseq type="increment">
                    KEYCODE_W
                </newseq>
            </port>
            <port tag="FAKE_JOY_X" type="P1_AD_STICK_X" mask="255" defvalue="128">
                <newseq type="increment">
                    KEYCODE_L
                </newseq>
            </port>
            <port tag="FAKE_SPINNER" type="P1_DIAL" mask="65535" defvalue="0">
                <newseq type="increment">
                    KEYCODE_E
                </newseq>
            </port>
            <port tag="SELECT" type="CONFIG" mask="3" defvalue="2" value="1" />
        </input>
    </system>

The very last port, the one with the tag "SELECT," tells us which inputs are active.  Also there is the issue of overlapping inputs.  Both the 720 configuration and the generic spinner configuration have a "dial" entry.  The only way to tell the different is the tag property, which we currently don't deal with. 
So in the wizard we might need to add a "has dirver configuration" box and make multiple control groupings inside <Config> nodes with a value flag.  In those rare cases we need to allow the user to add tag names or mask values.

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re: Change discussion
« Reply #5 on: March 31, 2011, 01:32:45 pm »
Interesting.  But do we need to worry about it?  What's the goal of controls.dat?  To create a description of the physical control panel and map it to the mame inputs.  However, should we worry about FAKE_X inputs that are hacks?  The game is a dial game.  Why should controls.dat also link to joystick or spinner?

In a controls viewer if all you have a joystick and 6 buttons on your control panel what you do is overlab the dial, spinner, and joystick labels.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19399
  • Last login:March 16, 2024, 05:59:16 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Change discussion
« Reply #6 on: March 31, 2011, 05:00:38 pm »
Well that's the thing.... if we are going by the book we would only list the real 720 spinner, which is an akward  2 dial system that makes the game completely unplayable. I also tried the method of just putting all the controls in the entry..... look at the hot mess that is the current 720 entry and you'll see what I mean. 

The thing about mapping the inputs is the killer.  See we can't map the inputs unless with deal with the flags at least because, like I said... two dials in 720's config with two different mapping ports, but they are both player 1 dial. 

I think we are going to eventually have to deal with it anyway.  There are drivers in mame besides this that already have a driver configuration setting, but they are incomplete drivers we don't have to worry about yet.  The option is intended to switch on/off inputs for those games that allowed multiple control types to be hooked up (trackball or joystick... ect). 

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re: Change discussion
« Reply #7 on: March 31, 2011, 05:53:09 pm »
Well that's the thing.... if we are going by the book we would only list the real 720 spinner, which is an akward  2 dial system that makes the game completely unplayable. I also tried the method of just putting all the controls in the entry..... look at the hot mess that is the current 720 entry and you'll see what I mean. 
Oh right, 720 has the regular encoder disc and the one with a single notch to calibrate it.  I don't see the issue with only mapping 720 to P1_DIAL and P1_DIAL_V.  Both have labels associated with them.  In a control viewer you may not put the P1_DIAL_V labels in.  In this case the labels are going to be blank anyways - other cases they may not, but...

There will be an issue for someone that has a control panel witha  joystick and spinner on it.  The convtrol viewer will probably put the labels on the spinner though the person may actually just use the joystick instead.

I wish the mame cfg file was organizes to the aliases are under the input they simulate. 

For controls.dat we could ass an aliases node that maps out the aliased controls.  It would be up to the control viewer and user to add that they want to show the joystick alias instead of the dial.