Main > Software Forum
MAME 104u5 out - adds multiple mice
Derrick Renaud:
--- Quote from: Howard_Casto on March 14, 2006, 06:49:26 pm ---But as a gesture of good faith, I would suggest looking at the cpnmouse api (probably not the best method for mame). And my personal favorite, hooking the wm_input data at a low level, which you can marry with the direct input function to do things exactly as I described... basically linking direct inputs mouse enumeration with the data functions so you can tell which device, not just with device number. For that matter you can do it just as easily if not easier with rawmouse, but it isn't being done because our dev has decided he knows what's best for us.
of the world.
--- End quote ---
You are truly serious. Wow. ::)
Your first answer cpnmouse, was correctly answered by yourself.
Your second answer, also answers what I have been saying about your comments all along. ??? Complete lack of knowledge on the subject. WM_INPUT is where I get the data. The only way you get individual mouse data in XP is from the RAW data supplied there.
You do realize that you are telling me that RAWMOUSE is not the best way to do it and your mysterious other way is to use RAWMOUSE?
You do know that there is no RAW support in Win98/ME? And that DX can NOT enumerate individual mice in XP. The whole point of this code.
You do know that we want multi-mouse support in Win98/ME and XP, and for it to function the same in all versions? That we want that support to be automatic without having to compile separate versions?
You do know that MAME used DX for Win98/ME to get access to individual mice. That I never changed that. That I added RAWMOUSE to XP if it is available, which is what you now state is the best way, even though you have said all along that it is not? (Is there a head blowing up emoticon?)
MAME currently stores mouse data in a DIMOUSESTATE structure. All MAME windows input code reads this structure to find out what the mouse is doing at the point when a game polls the input. RAWMOUSE sends data at a fixed rate. It is up to the programmer to keep track of it until needed. I convert it to the DIMOUSESTATE structure for 3 reasons.
1, because the button info is 100x easier to use in DX state then RAWMOUSE state.
2, because no MAME code will have to be changed to access it. Otherwise ton's of MAME code needs to be changed to handle the 2 separate cases. Which is bad coding practice. ;)
3, the reason I store it in the DI state is because, like I said before, it is up to the programmer to store it somewhere until needed. What better place then a structure that requires no other code changes?
I was not trying to get into a dick measuring contest with you. I could care less what anyone thinks of my coding skills. I do have a problem with people posting incorrect info as fact though. I tried over and over to clear up incorrect info you have supplied, all the way up to this post.
But it is time to get back to being productive. Feel free to correct MAME's mouse handling and send in a proper patch. I do not have any final binding say on submissions. If it is better then my code, there are plenty better programmers then me on the MAME team, that are always willing to accept better code.
And so everyone sees it here first, let me be the first to admit it...
I am NOT the world's greatest programmer.
I am the world's best Electronic Technician though. ;D
D.
Derrick Renaud:
--- Quote from: Lilwolf on March 14, 2006, 10:59:37 am ---I have 3 control panels that are hot swappable with mice on them. And will probably have a lot more in the future. I never do it ingame (because I switch my frontend to show the new control panel, it updates the games and the controls for the frontend... swap the control panel and go from there... ie, I can't select a game without first changing the control panel itself).
--- End quote ---
First let me tell you how I handle my controls. I'll answer your real question later.
I have 2 USB mice in the cabinet with the opto-couplers removed. Each opto-coupler has GND; 5V; IN1, IN2 per axis. So I re-route GND, 5V, IN1X, IN2X, IN1Y, IN2Y to my control panel. That way only the optical part is changed and the mouse is never removed from the system. I use The centronics printer interface connector on the control panel for easy removal. Actually I use a 50-pin SCSI type, but same diff.
As a side note, I have since determined that a hacked ball-type mouse is not the way to go. Something like an opti-pac is a better solution. The polling rate on 5 different usb mice I have tested is too low. I had some tests done on an opti-pac, and it does not suffer this problem. More info on this in a few weeks when I get around to making a page showing all the tests of different mouse interfaces.
--- Quote from: Lilwolf on March 14, 2006, 10:59:37 am ---I have a control panel that plugs in and now 2 trackballs make a connection. Will they always be recognized in the same order? I haven't tried but I'm guessing they wont be. But that might be based on the passive hub.
--- End quote ---
Further tests on a third machine show the reporting follows no repeatable pattern. That's MS's problem. Not MAME's. My tests on Win98 and XP show that the mice will always be listed in the order connected.
Install A, then B, then C. They show up as A,B,C. Remove B, the list is now A,C. Put it back in and we have A,B,C.
Well, actually RAWMOUSE reports C,B,A, but my current WIP fixes that.
I highly recommend using the ctrlr files. I set one up for every panel I have.
I will be adding -verbose support that will show the names of the mice used and what they are plugged into. But if you use all the same mice, then they will all show the same name.
eg:
Mouse 1: Logitech Cordless
Mouse 2: HID-compliant mouse
Mouse 3: HID-compliant mouse
Adding this support is a pain. RAWMOUSE has no provisions for this. I have to ferret out the info from the registry.
D.
Derrick Renaud:
I quick note about something I did not clear up.
When I added back in DX7 input support, I did not change anything from the pre 104u2 state.
The code always used it. But after the compile tools changed, the automatic definition of DX7 was removed. This change happened at 104u2. The fix applied by someone at the time was to define a base DX version of 5. They did not notice that in doing so, the current multi-mouse support was disabled for 104u2-104u4. I just changed it back to what it was before 104u2.
All that involves is telling the input system to try and use DX7 instead of trying DX5 for the base support. It will fall back to a lower version if DX7 not found. Just like always.
Doing this was not needed for my code change. But not doing it would leave multi-mouse support disabled on non-XP systems.
D.
SirPeale:
--- Quote from: Howard_Casto on March 14, 2006, 06:49:26 pm ---
You're a nana poopoo head. Bleah!
--- End quote ---
--- Quote from: Derrick Renaud on March 14, 2006, 06:55:58 pm ---
Nu-uh! You're a poopoo head!
--- End quote ---
Fixed.
btoddkelley:
D, my man, you are wasting your time with Howard. The most dangerous man is always one who does not know what he does not understand.
Thanks for the great work on dual mice support. I am also a fan of your analog sound work. And if you ever do find a "head blowing up emoticon" maybe it can become Howards avatar.
Todd
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version