The NEW Build Your Own Arcade Controls

Main => Main Forum => Topic started by: u_rebelscum on August 15, 2004, 05:23:11 am

Title: Official Mame and remapping Mice
Post by: u_rebelscum on August 15, 2004, 05:23:11 am
Official Mame now can remap the mouse, just like the analog joystick.

So you don't need Analog+ if all you want to to do is (for example) use Mouse X axis for player 1 and Mouse Y axis for player 2 anymore.  It's best if you use 0.85u1 or later.


You can tab into the input UI, select mame's analog axis you want controlled by the mouse axis, press enter, and move the mouse in that axis a fair amount.  (It might take a couple times for mame to register the mouse movement, though; try moving it slower or farther.)


Don't worry, I am still working on MameAnalog+!  It will take a little while though, and I've seen a bunch of "you need Analog+ to remap mice" advice recently, which is not true anymore.  I don't want to leave those people hanging when they didn't need wait. :)
Title: Re:Official Mame and remapping Mice
Post by: Tiger-Heli on August 16, 2004, 05:00:02 pm
Just the individual axes on one mouse, or can official MAME do multiple (mouse 2 controls player 2) mice as well?
Title: Re:Official Mame and remapping Mice
Post by: u_rebelscum on August 17, 2004, 01:30:21 am
I've been testing this a little, and official Mame can do multiple USB in win98/ME, SORT OF.  I was going to test it more before saying anything, but you asked for it. ;D

Limits (well, those I ran into on my system, so far):

1) Win98 and WinME only!  NOT in win2k.  NOT in winXP.  (sound familiar to some of you, huh? ;) )

2) The UI detects the only the "system mouse" axes; i.e. the "all mice together, mouse pointer you see on the desktop" mouse.  Official Mame calles this "Mouse 1".

3) If you want to use multiple mice (or make it so only one physical mouse inputs to a player), you need to hand edit the cfg/cfg file, or better the ctrlr file.

4) Mame's default is for the Mouse "1" (system mouse) to coutrol player 1, mouse "2" (first individual USB mouse) to control player 2, mouse "3" (second individual USB mouse) to control player 3, ect.  So you need to remap [size=-2]cough..ctrlrfile..cough[/size], unless you don't mind playing players 2 & 3.  

5) I can't get my "mouse 4" to work individually, but mame is finding "four" mice, and that mouse does effect the system mouse, and the buttons are "mouse 4" buttons.  (This might be a driver or system issue on my end).  

This means, on my system with the mice I have tested, I can get only two mice at a time.  I would try testing more mice than the three USB I have, but my trackball CPs are "in the shop" ATM.

I suggest editting the ctrlr file, since mame will "correct" the cfg file if a mouse is not found (unplugged at mame start time).


Remember, this is a winME/98 only feature because MS removed (or never added) the directX directInput access to individual mice from win2k/XP.
Title: Re:Official Mame and remapping Mice
Post by: Howard_Casto on August 17, 2004, 02:01:43 am
hmm the question remains.... can you remap mice axis via ctrlr files now?  if you can then this is great news

I'll have some testing to do I see. ;)
Title: Re:Official Mame and remapping Mice
Post by: Howard_Casto on August 18, 2004, 08:06:51 am
My Findings:

ctrlr sequence is as follows

MOUSECODE_#_ANALOG_##

Where #= the mouse number and ## = the axis

However, it appears that this syntax isn't completely compatable with all control types.  

It works great for analog axis as mame knows to split the axis into two seperate directions.  On digital inputs, however it gets really confused and can't use them.  I tried it on pacman just for fun.  It appears that the  codes crash the input macro as when i went into the input settings in mame p1_joystick_left was shown to be mapped to "mouse 1 X" but the other 3 directions came up as "NONE".  

I believe there must be similar codes to the old-school "P1_JOYCODE_1_UP" flags used in mame to split an axis into two directions,  I just haven't found them yet.  


Rebel if you can help me figure out this mess it would be appreciated.  This is useful info for the controls.dat project.  :)
Title: Re:Official Mame and remapping Mice
Post by: u_rebelscum on August 19, 2004, 01:52:28 am
Quote from: Howard_Casto on August 18, 2004, 08:06:51 am
My Findings:

ctrlr sequence is as follows

MOUSECODE_#_ANALOG_##

Where #= the mouse number and ## = the axis

Yup.  The complete list of standard names is in src/input.h, lines 37-433 (397-420 the mouse axis codes).

Note that the axis can only be X or Y, ATM.  Aaron has hints in the source code that the mouse's Z axis (scroll wheel) will be added later.

Quote
It works great for analog axis as mame knows to split the axis into two seperate directions.  On digital inputs, however it gets really confused and can't use them.  I tried it on pacman just for fun.  It appears that the  codes crash the input macro as when i went into the input settings in mame p1_joystick_left was shown to be mapped to "mouse 1 X" but the other 3 directions came up as "NONE".  

I believe there must be similar codes to the old-school "P1_JOYCODE_1_UP" flags used in mame to split an axis into two directions,  I just haven't found them yet.  


Rebel if you can help me figure out this mess it would be appreciated.  This is useful info for the controls.dat project.  :)

Okay.  Lots of info at the top of src/inptport.c source file, but here's some basics:

Three OSD inputs (aka physical devices):
digital, absolute analog, & relative analog

Three game inputs (aka emulated inputs, aka mame input types):
digital, absolute analog, & relative analog

So nine OS --> game input combos:
OSD inputGame Input
digital -->digital :)
digital -->Absolute Analogsimulated, core
digital -->Relative Analogsimulated, core
Absolute Analog -->digitalsimulated (well in official mame), OS Dendent*
Absolute Analog -->Absolute Analog :)
Absolute Analog -->Relative Analognot directly supported**
Relative Analog -->digitalnot directly supported***
Relative Analog -->Absolute Analogsimulted well, core
Relative Analog -->Relative Analog :)

* Mame windows OS code sees a joystick's axis as three inputs: Analog, simulated digital (positive direction), simulated digital (negative direction).

**Official mame indirectly supports this, through Digital --> Relative analog.  The absolute analog input needs to be "converted" to digital in the OS code.

***This is what you're having problems with.  Mame isn't designed to do the conversion.  It might be possible to add this in couple different ways.


Note 1: From table above, Mame might be able to use OSD lightgun to Game digital input.  Looks like it's probably only in pulses, though, since that's how the lightgun works.

Note 2: Mame doesn't split a relative analog axis into two directions.  Absolute analog axes aren't split in two directions unless it's converted to digital inputs, which is done on the OS level.

Note 3: An analog axis doesn't have two directions when it's seen as analog.  It just has one value for the axis.  
Title: Re:Official Mame and remapping Mice
Post by: Howard_Casto on August 19, 2004, 08:37:52 pm
Inteesting.....

by chance you haven't played with the guncodes and newer analog joystick codes have you?

I'm sure they work, but I'm more interested in how they work.  For example, there are now 3 pedal joycodes.  Afaik directx doesn't label axis this way, or do they?  I don't use a lot of crazy directx controllers so i'm just asking.  

Also the guncodes, is there a way to tell an actlabs gun from a regular mouse?  If not then wouldn't the guncodes also effect mouse mappings? (Of course only if the lightgun is turned on, so maybe I answered my own question).  

Title: Re:Official Mame and remapping Mice
Post by: jerryjanis on August 19, 2004, 10:22:40 pm
Quote from: Howard_Casto on August 19, 2004, 08:37:52 pm
Is there a way to tell an actlabs gun from a regular mouse?

I don't know about DirectX, but when a rawmouse message is received, it reports whether the device uses relative (mouse) mode or absolute (lightgun/touchscreen) mode, so it was possible to tell an act labs gun from a regular mouse in that way.  The weird thing was that I had no way of knowing what kind of device it was until after it gave me some kind of feedback (either a mousebutton or mousemove).
Title: Re:Official Mame and remapping Mice
Post by: u_rebelscum on August 20, 2004, 07:33:46 pm
Quote from: Howard_Casto on August 19, 2004, 08:37:52 pm
Inteesting.....

by chance you haven't played with the guncodes and newer analog joystick codes have you?

I'm sure they work, but I'm more interested in how they work.  For example, there are now 3 pedal joycodes.  Afaik directx doesn't label axis this way, or do they?  I don't use a lot of crazy directx controllers so i'm just asking.  

You're mixing mame's internal names with directX directInput names.  

Mame has a internal generic names for button1, joyup, analog_Y, pedal1, lightgunY, ect  (JOYCODE_1_BUTTON1, JOYCODE_1_UP, JOYCODE_1_ANALOG_Y, JOYCODE_1_ANALOG_PEDAL1, GUNCODE_1_ANALOG_Y).  These are the "STANDARD_CODE_STRING" name.

It's the OSD code's job to assign input devices to these names.  AFAICT mame 0.85u2 does not assign anything to the generic JOYCODE_#_ANALOG_PEDAL# pedal names, but I can't test here at work.


DirectInput can name any input whatever it wants.  You see this mostly on "start" and "select" buttons.  They still have a number, but also have a function name.

Mame also can read OS specific names.  When you have a 14 button gamepad, the buttons 11-14 must be called by the OS specific name, much like before.

Stuff that are assigned to a generic name can be called by either that or the OS specific name.  So in cfg and crlr files, mouse 1 Y axis can be "MOUSECODE_#_ANALOG_##" or (with my system) "Mouse_#_##".

Quote
Also the guncodes, is there a way to tell an actlabs gun from a regular mouse?  If not then wouldn't the guncodes also effect mouse mappings? (Of course only if the lightgun is turned on, so maybe I answered my own question).  

In Dinput 8.0 and later, yes, but depends on the driver.  I'll need to check dInput 7.0 (the one mame uses) when I get home.  AFAICT, mame doesn't figure out mouse vs gun inputs, but I don't think that's right. ???
Title: Re:Official Mame and remapping Mice
Post by: Howard_Casto on August 21, 2004, 01:39:37 am
No i'm not confused believe it or not.  I am aware that mame uses both directx "labels" as well as it's own labels that it gives to certain indentifiable axis and buttons.  

What I was getting at is I'm almost positive that directx controllers don't use said labels.  So then how is mame choosing which analog axis is a "pedal"  these constants are listed in the source so either they are useless (which means somebody needs to comment them out) or they are magical in that I don't have  aclue how they are working.  

I am concluding basically what you are with the mouse vs lightgun inputs.  My guess is analog Z and pedal 1 are one in the same, in which case we have some redundant constants which might be confusing in the future.  
Title: Re:Official Mame and remapping Mice
Post by: u_rebelscum on August 21, 2004, 02:25:00 am
Quote from: Howard_Casto on August 21, 2004, 01:39:37 am
What I was getting at is I'm almost positive that directx controllers don't use said labels.  So then how is mame choosing which analog axis is a "pedal"  these constants are listed in the source so either they are useless (which means somebody needs to comment them out) or they are magical in that I don't have  aclue how they are working.  

I am concluding basically what you are with the mouse vs lightgun inputs.  My guess is analog Z and pedal 1 are one in the same, in which case we have some redundant constants which might be confusing in the future.  

What directX calls it doesn't matter.  

The question is: Does OSD code assign anything to the pedal standard code?  
The answer is: No, not as of 0.85u2.  

To test, use the default inputs, have pedal_device set to joystick, and play a pedal game.  You'll see "N/A or J1 Y-AXIS" (or whatever your joystick driver tells dInput to call it).  The default is "JOYCODE_1_ANALOG_PEDAL1 OR JOYCODE_1_ANALOG_Y".  Core mame gets a null return for JOYCODE_1_ANALOG_PEDAL1.  It's the OSD code to assign something to that standard code, but it doesn't assign anything ATM.

The above shows there is NO conflict between the pedal standard codes and the Y axis standard codes, because the pedal gets "N/A" and the Y axis gets "J1 Y_Axis" or whatever your joystick driver tells dInput to call it (yes, the example is intentionally different).

Notice the seperations between the dInput, mame OSD, and mame core inputs.

Now, conflicts might occur if something was assigned to the pedal standard code.  This is on the OSD side; even if windows doesn't assign anything to it, the linux or dos ports might.  Removing it from the core is a Bad Idea.  And it's virtually removed from the windows version anyway.


FWIW, this might be one reason mame compile with dx 8.0 or up.  DInput 8 introduced "action mapping", which tries to let the programs know what type of input the device is, and what device objects that device has.  On paper, mame could assign physical pedals to the pedal standard codes and analog joysticks to the adstick standard codes.  In practice, it's not as good as MS hyped it to be, since it relies on the joystick drivers to correctly identify themselves, and especially not over-identify themselves (claim "I can do it all!").



Related subject: Identifing lightguns vs mice:

DirectInput 5-7 can partially tell the difference (again, if the driver is doing it's job): The 5 mouse subtypes are: TRADITIONAL, FINGERSTICK, TOUCHPAD,TRACKBALL, UNKNOWN.  Need to test which of the above the lightguns fall under; my guess is either touchpad or unknown.

DirectInput 8+ should be even better as it has more types: mouse and screenpointer.  The mouse subtypes are also explanded: ABSOLUTE, FINGERSTICK, TOUCHPAD, TRACKBALL, TRADITIONAL, and UNKNOWN.  While the screenpointer subtypes are: LIGHTGUN, LIGHTPEN, TOUCH, and UNKNOWN.  I bolded the one I hope the lightguns call themselves, and italiced the other possibilities.  Again, need to test.