Mouse movement being bounded by box (trackball, etc)

[telengard]

I did some poking around and found someone who ran into something similar w/ SDL Mame.  They described it as "being blocked by walls".
The suggestion was to set the environment variable SDL_MOUSE_RELATIVE=1.  I've set it in ~/.bashrc and ~/.bash_profile and it seems to be having no effect.

Is any one successfully using a trackball or spinner w/ GroovyMame?

[Calamity]

Hi telengard,

Are you having this problem with all trackball or spinner games? Have you tested base line SDL MAME too?

[telengard]

Hi telengard,

Are you having this problem with all trackball or spinner games? Have you tested base line SDL MAME too?

Heya Calamity,

I've only tried it w/ Centipede, I'll try some other games.  I'll try a few spinner games also.  I'm using an Optipac interface.  I'll try out stock SDL Mame also.

thanks for the ideas, I'll report back after I've tested all this stuff...

~telengard

[telengard]

Just finished up testing a little bit ago.

- Other trackball games exhibit the same issue
- Spinner games also exhibit the issue
- stock sdl mame trackball works fine

~telengard

[telengard]

Is it worth testing without the custom video modes to see if that is the issue?  If so, any help on how to run without that would be helpful.

thanks!

[Calamity]

You should try launching centipede at the desktop's resolution. For instance if it is 648x480@60, then launch:

groovymame centipede -resolution 648x480@60

I believe the problem is that SDL is not aware of the resolution change for some reason... not sure.

[telengard]

You should try launching centipede at the desktop's resolution. For instance if it is 648x480@60, then launch:

groovymame centipede -resolution 648x480@60

I believe the problem is that SDL is not aware of the resolution change for some reason... not sure.

Hi Calamity,

Thanks for the info.  Even running it at 800x600 it is happening.  I'm confused about the desktop resolution though, what is it if AdvanceMenu is run straight out of boot (I'm running Linux and no desktop at all)?

[Calamity]

I'm confused about the desktop resolution though, what is it if AdvanceMenu is run straight out of boot (I'm running Linux and no desktop at all)?

I meant launching GM from a desktop manager like LXDE (included GA), opening a terminal in there and launching it from command line. The idea is to launch GM at same resolution used by the desktop so any resolution switch has no effect.

[telengard]

I'm confused about the desktop resolution though, what is it if AdvanceMenu is run straight out of boot (I'm running Linux and no desktop at all)?

I meant launching GM from a desktop manager like LXDE (included GA), opening a terminal in there and launching it from command line. The idea is to launch GM at same resolution used by the desktop so any resolution switch has no effect.

Ok, I got some time to try this out today.  Launched LXDE, the desktop was 640x480@60.  Launched centipede w/ groovymame using the same resolution and the issue is still there.

[telengard]

Calamity,

I started poking around the source code and found this in src/ods/sdl/window.c:

  //FIXME: SDL1.3: really broken: the whole SDL code
        //       will only work correct with relative mouse movements ...
        //SDL_SetRelativeMouseMode
        if (!window->fullscreen && !sdlinput_should_hide_mouse(machine))
        {
            SDL_ShowCursor(SDL_ENABLE);
            if (SDL_GetWindowGrab(window->sdl_window ))
                SDL_SetWindowGrab(window->sdl_window, SDL_FALSE);
        }

Is this a change made for GroovyMame.

Is anyone else seeing this behavior or am I the only one using a mouse on Linux?   

[Calamity]

Hi telengard,

That code belongs to main line MAME, but it could point to the roots of the problem.

I don't have a working Linux setup at the moment since I accidentally destroyed by pendrive install. I promise I'll be looking at this problem when I have the time.

[telengard]

Hi telengard,

That code belongs to main line MAME, but it could point to the roots of the problem.

I don't have a working Linux setup at the moment since I accidentally destroyed by pendrive install. I promise I'll be looking at this problem when I have the time.

Hi Calamity,

That makes sense, it sure seems to be related.  Sorry to hear about your pendrive install, I've hosed a couple myself by not umounting correctly before removing.

Thanks for looking into this issue, I appreciate it a lot!

[strontium]

Hi guys,

This problem has been around for quite some time now, in fact I originally posted about this in sept 2013 and have been quietly holding out for a fix since: http://forum.arcadecontrols.com/index.php?topic=134528.0

It's also mentioned in abother way on the project page here as a bug: https://code.google.com/p/groovyarcade/issues/detail?id=7

It's a real shame as groocyarcade is great, calamity is there any more news on if this can be fixed or even progressed.

I appreciate were not all developers and can't really help but it would be so cool to be able to use the mouse / trackball without having to go back to windows.

Thanks again

Strontium

[Calamity]

I'll be looking into this. In the meanwhile it would be good to check if the new builds based on sdl2 have this issue too.

[strontium]

Ok Calamity will do, just so I'm sure do you mean the beta version? Would you suggest the download from the hyperlink on the project page or a git pull?

Thanks again

Strontium

[Calamity]

Ok Calamity will do, just so I'm sure do you mean the beta version? Would you suggest the download from the hyperlink on the project page or a git pull?

Sorry from my late answer. Yes, I meant the beta and it can only be downloaded from the link.

[Calamity]

Ok so Ves has been checking this and finally we found the culprit for the mouse misbehaviour. It turns out its XInput what causes the issue. By default we were enabling it to provide support for wiimotes, etc. But this seems to interact with the mouse. So in the most recent GM patch (0.159 Switchres 0.015f) I've disabled Xinput by default (leaving it as official MAME is), so just compile it using the new patch and the mouse should work fine. Groovy Arcade builds will keep supporting wiimotes however.

[telengard]

Ok so Ves has been checking this and finally we found the culprit for the mouse misbehaviour. It turns out its XInput what causes the issue. By default we were enabling it to provide support for wiimotes, etc. But this seems to interact with the mouse. So in the most recent GM patch (0.159 Switchres 0.015f) I've disabled Xinput by default (leaving it as official MAME is), so just compile it using the new patch and the mouse should work fine. Groovy Arcade builds will keep supporting wiimotes however.

Hi Calamity,

Thanks so much for getting to the bottom of this!  So, it seems I just need to follow the process here

http://forum.arcadecontrols.com/index.php/topic,135823.0.html

just for Linux, all default compile options, etc?

~telengard

[telengard]

Ugh, I'm running Ubuntu 12.04 LTS and no libsdl2 for it.  I guess if anyone gets this compiled if they could share it, I would be very grateful.

[Calamity]

Hi telengard,

There are some updated 0.159 no-xinput binaries here:

https://drive.google.com/drive/#folders/0B0NB2HYUHHktSUJiRDRKWWFCV1k/0B5iMjDor3P__aEFpcVNkVW5jbEE/0B5iMjDor3P__fjNkU2MwMUNaSEY4V2NGLWQwN2dYVHh2Zy03am5GSTlsVGJMWkNIbWZMQXM

[Doozer]

Ugh, I'm running Ubuntu 12.04 LTS and no libsdl2 for it.  I guess if anyone gets this compiled if they could share it, I would be very grateful.

Have you look here already (using xbmc ppa) ? http://www.ubuntuupdates.org/libsdl2-dev

Release:    precise (12.04)
Name:    libsdl2-dev
Latest version:    2.0.3+z4~20140315-8621-1ppa1precise1

[telengard]

Ok, finally got all of the upgrades done on my GroovyArcade install (circa 2013) to run these new binaries.  For those interested, I had to upgrade or install the following:

pacman (arch's package manager) this also required removing some stuff to get the dependencies working
change SigLevel since I could not get the pacman security keys working
qt4gui
sdl_ttf
sdl2
libpng
updated romset (Centipede, etc seemed to have some files renamed), since the romset I got uses .7z I upgraded everything replacing my .zip

Dropped the new binary in and unfortunately I get no trackball at all now.   
Doesn't register for non gameplay usage too, like in the tab menu for assigning keys, etc.

It does work in advmenu as it has in the past
I have trackball_device set to mouse as it was before

Anyone else having this kind of issue with these new builds?  Or have any ideas on how to debug this?

~telengard

[Calamity]

Hi telengard,

Ask Ves directly, I know there has been a problem with SDL2 and input devices, different to the one that we were discussing. I know he solved it recently but I'd say it's in one of the beta distros. Also, check if it works inside X.

[telengard]

Hi telengard,

Ask Ves directly, I know there has been a problem with SDL2 and input devices, different to the one that we were discussing. I know he solved it recently but I'd say it's in one of the beta distros. Also, check if it works inside X.

Hi Calamity, thanks for the info.

It does seem to work in X assuming that AdvMenu is an X application.

I will contact Ves about this, thanks what is the best way to reach him?  His email on the google code page has an ellipsis (...).

~telengard

[Calamity]

It does seem to work in X assuming that AdvMenu is an X application.

I didn't mean that. I meant when you run GroovyMAME from command line inside the windows manager (LXDE).

You can just pm Ves from this forum.

[telengard]

It does seem to work in X assuming that AdvMenu is an X application.

I didn't mean that. I meant when you run GroovyMAME from command line inside the windows manager (LXDE).

You can just pm Ves from this forum.

Ah, OK I will try that tonight, thanks!

~telengard

[ves]

Hello,
telengard remember configure the trackball in mame/ume.ini

mouse                     1
trackball_device          mouse
mouse_device             mouse

[telengard]

Hello,
telengard remember configure the trackball in mame/ume.ini

mouse                     1
trackball_device          mouse
mouse_device             mouse

Hi Ves,

I do have those settings, but I have them in /home/arcade/mame.ini.  Is that the wrong ini file?  That's the one I've always been using.  I'm also using the groovymame binary, which if I understand right will use mame.ini, not ume.ini?

[telengard]

It does seem to work in X assuming that AdvMenu is an X application.

I didn't mean that. I meant when you run GroovyMAME from command line inside the windows manager (LXDE).

You can just pm Ves from this forum.

Hi Calamity,

I tried that out (launching groovymame from the command line inside the window manager), exact same behavior.  No movement at all.  The mouse also doesn't register in the menu system.

Do you recall what the input issue was w/ SDL2?

~telengard

[Calamity]

I do have those settings, but I have them in /home/arcade/mame.ini.  Is that the wrong ini file?  That's the one I've always been using.  I'm also using the groovymame binary, which if I understand right will use mame.ini, not ume.ini?

Beware of this. In recent version of GroovyArcade you really need to edit ume.ini even if you're using GroovyMAME. Editing mame.ini has no effect because the GroovyMAME executable is indeed a symbolic link to the GroovyUME one. Confusing, I know.

[telengard]

I do have those settings, but I have them in /home/arcade/mame.ini.  Is that the wrong ini file?  That's the one I've always been using.  I'm also using the groovymame binary, which if I understand right will use mame.ini, not ume.ini?

Beware of this. In recent version of GroovyArcade you really need to edit ume.ini even if you're using GroovyMAME. Editing mame.ini has no effect because the GroovyMAME executable is indeed a symbolic link to the GroovyUME one. Confusing, I know.

Yup, had gotten bitten by that before.  In this case I dropped in the 2 different binaries groovyume and groovymame (the ones built with no xinput).  I'm pretty sure my config is being used since it picks up my roms etc.

I still have no mouse input at all, but just in groovymame.  It's working in X, advmenu, etc.

Do you know what Ves had hit as far as SDL2 input issues?

[nexuscab]

Did anyone ever figure this out? I'm having the same problem where sdlmame has no problems with the trackball, but with the noxinput build of 159 Calamity posted, I get no movement at all. With the regular builds of groovymame/groovyume I get movement but have the issue of the bounding box described above.

I have:
mouse 1
mouse_device mouse
trackball_device mouse

I am calling the noxinput build directly from the command line so it isn't an issue of the wrong binary running.

I should note that I'm running on the most recent GroovyArcade beta ISO in case that makes a difference with libraries, etc.

I'm a huge groovymame fan. I have it running on one windows machine with an HD4350, but this machine has an HD5650, plus I much prefer linux in general. I just can't live without Centipede and Tempest! :-)

Thanks everyone.

[pakoman]

I found this issue also.

I'm using Groovyarcade 32bit (don't really remember which version of groovymame is in there).

I've noticed something interesting about this: if you activate de mouse for UI navigation, the UI cursor works perfectly, but the in-game mouse/trackball/lightgun input doesn't. And if you move fast the mouse in-game the "bounding box" will move to another place of the screen.

In lxde, advancemenu, etc. works fine.

[telengard]

Odd, I don't get the bounding box anymore, I just don't get movement at all.   However if I move the trackball a LOT, I see it move a pixel or two.  I'm running 64 bit here.  Seems like it is also happening with the latest distribution, so I'm holding out hope for a fix where I can continue to keep my cabinet as is.

[Calamity]

Hi telengard,

I don't have a working Linux installation these days and I'm focused on the windows side, sorry. If you want to help me fixing this, and you have some experience compiling, please try this.

In src\osd\sdl\window.c, find this:

Code: [Select]

// Some configurations require events to be polled in the worker thread
//sdlinput_process_events_buf();

and change it by this:

Code: [Select]

// Some configurations require events to be polled in the worker thread
sdlinput_process_events_buf();

No idea if it could have something to do with the issue but definitely is related input and it's something we change in GM.

[telengard]

Hi telengard,

I don't have a working Linux installation these days and I'm focused on the windows side, sorry. If you want to help me fixing this, and you have some experience compiling, please try this.

In src\osd\sdl\window.c, find this:

Code: [Select]

// Some configurations require events to be polled in the worker thread
//sdlinput_process_events_buf();

and change it by this:

Code: [Select]

// Some configurations require events to be polled in the worker thread
sdlinput_process_events_buf();

No idea if it could have something to do with the issue but definitely is related input and it's something we change in GM.

Hi Calamity,

No problem at all, I'd be happy to help.  Should I apply this change to the 0.159 no-xinput sources?

~telengard

[Calamity]

If those are the sources you have, yes. Any version since that one should do.

[telengard]

Hi Calamity,

I was finally able to get it built for 64 bit using a VM (I only have a 32 bit Linux desktop and it is old, so some libraries weren't available). 
So, unfortunately with that change the same behavior (no mouse movement at all).

However, I was fiddling with arguments to mame by editing .xinitrc and noticed that if I ran at a resolution of 800x600 the mouse worked fine!
So, something with the correct resolution or  related is the issue?  In my case I am always testing out centipede which I believe is 240x256.

Also, it might not be clear from my previous posts, but I'm no longer getting the bounding box.  That went away w/ the no-xinput build.  Instead it is no movement at all (for certain resolutions).

Hopefully that is useful information!

[telengard]

Just wondering if anyone has any ideas of what to try next?

[Calamity]

Hi telengard,

Sorry for my late answer.

Do you mean it works when MAME runs at 800x600 or when the desktop is at 800x600? What I'd do is to get two logs, one when it works, one when it doesn't, so we can compare.