Mouse support somehow broke?

[Endprodukt]

None of my mouse devices are recognized in the latest GM version. All devices (trackball and two spinners) DO work in windows. I had them configured but now they won't be recognized in the menue. I've activated mouse/multimouse and set everything to "mouse" for the devices as usual. Never had a problem.

Today I even deleted the mame.ini and default.cfg to start again. Worked once, not twice. So a spinner was recognized but not the next time I started a game. Strange...

[Calamity]

Download the binary again. This must be related to the .cfg problem that I fixed after the first days of the release.

[Endprodukt]

Ah okay, didn't know about that. Did you update the diff as well?

[Calamity]

Yep.

[Endprodukt]

Didn't work. Same problem. Lightguns DO work. Trackball and Spinners do not work.

[Endprodukt]

Ok: I can confirm that this is indeed related to the latest GM version. I installed an older version (I think it was 149) and everything works right away.

[Calamity]

Does normal MAME work fine?

I tested this yestarday with arkanoid changing the controls from the ui and things worked fine here. Can you suggest a test I can do to reproduce the issue here? Something that can be done with a mouse, I don't have spinners, sorry.

[Endprodukt]

I didn't test normal Mame. Only GM 151 and 149.

Seems like something messes up multimouse support. With 151 and multimouse disabled my spinners/trackball work but it's of course useless without multimouse on my system.


ps.

you may have a second mouse? try if it works over there with multimouse support.   

[Endprodukt]

Did some further testing.

I can confirm that my trackball/spinners are working with the normal Mame 151 release from Mame dev and GM 149 but not with GM 151!

[Calamity]

Oh sh*t, I really didn't want to hear that 

I assume you're testing *my* GM 151 build, the most recent one.

Please suggest an easy test with an specific game that I can reproduce here in the exact same way.

Also, try if setting 'monitor lcd' makes the issue disappear.

[Endprodukt]

Yes, I tried your latest version as well as my own compiled version of the 0151 gm diff.


Try this:

Connect two USB mices. In mame.ini set mouse 1, multimouse 1 and dial/trackball under devices to mouse.

You may use Arkanoid for testing. I used a fresh mame.ini for each version I tested.

Go to the UI and to the game specific controller settings. Go to Dial one, hit enter and move your mouse left or right. Usually it should set it to "mouse1" or "mouse2" etc depending on the ID.

Here, it does nothing and doesn't register the trackball or spinner, which are nothing else but mices to windows, so this should be the same for you with your mices.

In the end, it doesn't matter which game you use for testing, as it's not working in the default controls either! 

[Calamity]

Ok, this might have nothing to do with the .cfg files as I understood. You mean GM doesn't react to input while in the ui.

This might be related to the way the input is polled now for the new -frame_delay implementation, but it's so odd that this happens...

[Endprodukt]

Well, what's strange is that the lightguns work although these are working like a mouse (but are beeing recognized as "Gun1"/"Gun2" by Mame).

[Calamity]

Well, what's strange is that the lightguns work although these are working like a mouse (but are beeing recognized as "Gun1"/"Gun2" by Mame).

It's all very strange, because I haven't done anything special regarding to the inputs, just changing the moment these are polled, but this shouldn't affect and in fact doesn't affect the usual behaviour apart from what you're describing.

[Endprodukt]

I thought there is something with my setup. After testing the other versions without having any problems with hooking up the controls I'm pretty sure something strange (whatever it is) is going on in GM 151.

If I can help you any further in finding out what's going on... let me know how.

[Calamity]

Hi Endprodukt,

Well this is strange because it seems to be working here, I've tested arkanoid in GM 0.151 (32 bits) with 2 mouses, have entered the UI and selected mouse-1 and mouse-2 for dial-1 and dial-2, and they are detected instantly as I move each one... I've added both the log and the .cfg, in case you can see something different in your system that may give us a clue of what's going in.

[Endprodukt]

I'm using 64bits, don't know if this a difference.

[Endprodukt]

Still not working on 0.152. Using the exact same settings with 0.149 -> no problems. I don't think this is related to my system.

[Calamity]

Ok, as I can't reproduce this problem here, the only way to find the problem is testing some changes directly on your machine.

Can you build GM with this modification? In src\emu\video.c, function:

 void video_manager::frame_update(bool debug)
....

comment out this line:

   // get most recent input now
   //machine().osd().poll_input();

[Endprodukt]

Will try when I'm back home.

[Endprodukt]

I compiled Mame as you said and it works now. Does that help you with finding the problem?

[Calamity]

I compiled Mame as you said and it works now. Does that help you with finding the problem?

Yeah it helps. It turns out that polling the input at that point, which is required to minimize input lag, for some reason is preventing the ui to get the input events normally, although afaik there's no issue with input while in game.

I'll need to look into this when I have some time. The good thing at least is that you found this problem and now we know where it's located.

[sean_sk]

I just wanted to mention something in this regard and I'm not sure how relevant or how helpful this is since it seems you have found the problem.

I have two trackballs and a mouse hooked up to my cab which is running GM 0.152 on Windows 7. When going into game specific options and configuring the mouse and trackball controls, the mouse is instantly detected if I move it, whereas the trackballs aren't if I move them at the same normal speed as the mouse. But if I spin the trackball REALLY fast, and I mean damn fast, it gets detected. Once they're detected they work as per normal in game. It's how I've been working around the problem for games that require trackball input. Hopefully I won't have to continue to do that when configuring other games cause I'm sure it's not good for the trackballs.

Using 2 X U-Trak's on an Optipac.

[Calamity]

I just wanted to mention something in this regard and I'm not sure how relevant or how helpful this is since it seems you have found the problem.

I'm almost certain you're describing the same issue, thanks.

[sean_sk]

afaik there's no issue with input while in game.

Unfortunately I have found a game in which there seems to be an issue in-game, and that's both Arkanoid and Arkanoid 2.

Calamity you mentioned that you tried mouse input with Arkanoid and it seemed OK. Unfortunately it isn't with me. When I spin the trackball the bat only seems to move in small increments, even if I crank sensitivity right up to 255. I don't have a spinner so using trackball instead. Works fine in normal Mame. Games like Marble Madness and Centipede seem to be fine once I've managed to actually get GM to detect the trackball input in the UI.

As mentioned previously, I have a mouse and two trackballs connected to system.

[Calamity]

Hi sean_skroht,

That's too bad...  Can you check if enabling -mt makes it any better? Anyway, I'll need to look into this.

[sean_sk]

Can you check if enabling -mt makes it any better? Anyway, I'll need to look into this.

This is doing my head in as I can't get the problem to be consistent.

I have two systems in which I did the mouse tests:

First system: Arcade cab with CRT monitor, ArcadeVGA 3000, 2 X U-Traks and 1 X mouse, Optipac, GM 0.152 and Windows 7.

Had issues with trackballs and Arkanoid as stated in previous post. I deleted mame.ini and created a new one and changed the following settings:

mouse                              1
monitor                             arcade_15
lock_system_modes         0
refresh_dont_care           1
frame_delay                     7
multithreading                  1

All other settings were at default. These were the exact same settings as last time but now the problem has gone away and all seems fine.
One thing to note: I tried frame_delay initially at 1 and it was fine. Then i set it to 7 and noticed that mouse speed slowed down so I increased "Dial Sensitivity" to 125 which compensated for the reduced speed.

Second system:: Windows 7 PC, LCD Monitor at 1920x1080, nVidia GTX 590, 2 X mice and GM 0.152.

Generated mame.ini and changed the following setings:

mouse                              1
monitor                             lcd
frame_delay                     1
multithreading                  1

Mouse seemed to be fine with these settings, but if I changed frame_delay to 7 then the problem reappeared.

Unfortunately results seem to vary from system to system.

As a side question I was using frame_delay 7 as a result of a post I read from Dr.Venom. Is there an advantage to setting it to 7 as opposed to 1?

If you need any further info please let me know.

[Calamity]

Hi sean_skroht,

Do you have experience compiling MAME so I can suggest you some changes?

[sean_sk]

Hi sean_skroht,

Do you have experience compiling MAME so I can suggest you some changes?

Yup I sure do. What you got in mind?

[Calamity]

In src\osd\windows\video.c, find this function: void windows_osd_interface::update(bool skip_redraw)

Then comment out these lines:

Code: [Select]

// poll the joystick values here
// winwindow_process_events(machine(), TRUE, FALSE);
// wininput_poll(machine());
// check_osd_inputs(machine());


[sean_sk]

Hi Calamity,

I made the changes you suggested and things seemed fine for all trackballs and mice on both of my systems.

[Calamity]

Hi Calamity,

I made the changes you suggested and things seemed fine for all trackballs and mice on both of my systems.

That's great. Thanks for testing. It turns out the problem is polling the devices twice per frame. This happened when I added a second poll at the last possible moment, but without removing the other one (the original). The good thing is I can keep the new poll in its place and just remove the old one, so -frame_delay still serves its purpose. I'll fix this for next version.

[sean_sk]

Terrific! Thank you for having a look at that Calamity!