Main > Software Forum
Aaron removes xml2info as of u12 (in other words, we are screwed)
<< < (11/16) > >>
krick:

--- Quote from: Howard_Casto on July 19, 2006, 03:45:42 pm ---I'm gonna need some examples, cause I haven't run across them.

--- End quote ---

Thanks to the magic of XSL...

housemnq:
   display  -  width:512  height:224
   display  -  width:480  height:64
   display  -  width:480  height:64
housemn2:
   display  -  width:512  height:224
   display  -  width:480  height:64
   display  -  width:480  height:64
livegal:
   display  -  width:512  height:224
   display  -  width:480  height:64
   display  -  width:480  height:64
bijokkoy:
   display  -  width:512  height:224
   display  -  width:480  height:64
   display  -  width:480  height:64
bijokkog:
   display  -  width:512  height:224
   display  -  width:480  height:64
   display  -  width:480  height:64
mt_beast:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_shar2:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_stbld:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_ggolf:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_gsocr:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_asyn:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_shnbi:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_aftrb:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_tfor2:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_astro:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_lastb:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_wcsoc:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_tetri:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_gng:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_shang:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_gaxe:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_mystd:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_revsh:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_parlg:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_tgolf:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_tlbba:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_cols:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_eswat:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_smgp:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_mwalk:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_crack:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_arrow:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_astrm:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_bbros:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_sonic:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_sonia:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_fshrk:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_gaxe2:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_stf:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_mlh:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_kcham:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_soni2:
   display  -  width:256  height:192
   display  -  width:320  height:224

...there may be more.  I just printed out the ones where the with on the first display isn't equal to the width on the second display.
Howard_Casto:
thanks... had the same idea though :)

yeah i just went through a filter myself and tried every single dual screen game (ugh)

The one's the use the lcds are japanese mahjong porn, so nobody really cares about those.  Also the extremely squased aspect would make it difficult to display on multiple monitors. 


The mega tech are a different res, but they are both stretched to the same aspect. Apparently the mt cab's selection display was smaller, and they didn't see the need to use hi-res output on it. 

One I did run into that seems really odd, even though mame reports it as bothscreens being the same is :

rocknms (Rockin' Mega Session)

 The top monitor appears to be horizontally oriented while the bottom is vertically oriented.  This isn't reflected in the output, probably because a custom layout had to be made to show both screens in the proper layout on a dual screen monitor. 


My point is the display stuff seems to be a tad inconsistant.  It's also rather hard to tell anything from the data.  So for now, until the fields are fleshed out a little more (such as display number or display position) it might be best to leave all but the first (which is always the primary display) out. 
u_rebelscum:
Coming in late again....


--- Quote ---Added multiple input controls in -listxml output for games with more
than one type. Added pedal control type. Added more info on analog
controls as defined in the driver: minimum, maximum, sensitivity,
keydelta, and reverse. This required the 'control' attribute in the
XML to be moved into an element. There can now be more than one
'control' element in the input section.
--- End quote ---

Do you guys have anything else that you want added to the listXML input controls data set? 

Things I'm considering of:
- Krick mentioned cases where the players have different controls. 
- The (v)2/4/8-way, (v)dial & (v)paddle types handle the single X, single Y, and both X & Y cases, but the rare cases where only one axis of the analog stick or trackball (DOT) is not. (Opps, the vertical dial and paddle types are not checked for, either.)
- Krick also suggested putting the buttons as another control type.  I'm thinking as it's own element, but only if it needs something extra like:

* Show if different players have a different number of buttons. (see examples)
* Show if the start button exists in the driver.  Most games have start buttons, others do not although sometimes mame fakes it by mapping a fake one to (another) the game's button 1.  But then there's the two player alternating games with more starts than players (DOT), hmm...
The players could have the controls item under them, or vice versa.  I'm thinking put the players sub the controls, with the default player to "All", leave the start buttons item out and add the axis item to replace the special "v---" types.  So I'm thinking, as examples:

For normal two player, one button & one 4-way per player:

--- Code: ---<input players="2" coins="2">
<buttons number="1"/>
<control type="joy4way"/>
</input>
--- End code ---

For two player, two buttons & ADstick for player 1 & four buttons for player 2, no start buttons:

--- Code: ---<input players="2" coins="2">
<buttons number="2" player="1" start="No"/>
<buttons number="4" player="2" start="No"/>
<control type="stick" sensitivity="100" keydelta="10" player="1"/>
</input>
--- End code ---

Basebal2 (IMO, the buttons should be emulated more like above example, but that's for another discussion):

--- Code: ---<input players="2" coins="2" tilt="yes">
<buttons number=6 player="1"/>
<control type="stick" sensitivity="100" keydelta="10"/>
</input>
--- End code ---

DOT:

--- Code: ---<input players="1" coins="2" tilt="yes">
<buttons number="4"/>
<control type="joy8way"/>
<control type="dial" sensitivity="50" keydelta="10" reverse="Yes"/>
<control type="trackball" sensitivity="100" keydelta="10" axis="Y"/>
</input>
--- End code ---


An alternative is putting the control sub to the player (Basebal2 example):

--- Code: ---<input players="2" coins="2" tilt="yes">
<player number="1"/>
<buttons number=6 player="1"/>
<control type="stick" sensitivity="100" keydelta="10"/>
</player>
<player number="2"/>
<control type="stick" sensitivity="100" keydelta="10"/>
</player>
</input>
--- End code ---

However, since most games have the same inputs and with the players number defaulting to "All", though, it would be not be nice IMO (DOT example):

--- Code: ---<input players="1" coins="2" tilt="yes">
<player>
<buttons number="4"/>
<control type="joy8way"/>
<control type="dial" sensitivity="50" keydelta="10" reverse="Yes"/>
<control type="trackball" sensitivity="100" keydelta="10" axis="Y"/>
</player>
</input>
--- End code ---
Somehow the players attribute in the input could be moved to inside the players element, but I don't know how to put "total number of players" vs "this player number" clearly.


Better suggestions?  Improvements?  Additions?
SirPoonga:
Heh, urebel, you know everything you mentioned is how controls.dat works :)  We assume controls are for all unless player2 or greater is specified.  So I would agree with your last two examples.

If you haven't looked at the controls.dat format take a peek, it might give ideas.
Howard_Casto:
Something that's key that is missing, is the status of play... if it's alternating or not.  This tells you if it's a two player game with one set of controls (like pacman) or a two player game with two sets of controls (like street fighter).  With that, the basic data is there. 


Also I don't think controls.dat specifically is written for this, but this is how I handle those rare instances like dotron you were mentioning in J5:

If all of the controls are used for a control type then the control type constant is used  (like trackball or joy8way) but if some aren't used then each individual input is treated as a control  (control p1_trackball_Y+ and controls p1_trackballY- or whatever)  of course this is a bad example as for analog controls you can just define the axis and up and down is assumed, but for a digital example you would give both directions. 

I really like the new way you've arranged it btw.  Any chance of you fixing the missing elements in the ctrlr files?  Like allowing you to reverse the axis, set the sensitivity or define a bit offset for those odd-ball inputs?
Navigation
Message Index
Next page
Previous page

Go to full version