[libretro] Mouse Acceleration Issue

[rtomasa]

This is for the libretro FBNeo version.

Not sure if it is an expected behaviour or not, but I've noticed that mouse motion is affected by the Analog Sensitivity. So for example, trying to play games like Missile Command or Arkanoid using default configuration makes the "pointer" going like crazy until you set the sensitivity to the lowest available value (25%). At this value, the mouse works almost perfectly fine but not fully 100%, so not sure if it should be fully disabled maybe by providing a 0% setting, or it is a bug, or it is expected...

Best Regards

[dinkc64]

I'll see if any adjustments can be made on my side, it might be a driver issue, beause I never tried the mouse with those games. If you can think of any other games that have this problem, please list them :)

best regards,

• dink

[rtomasa]

I've tested the following games using Mouse (full) (514):

• Arkanoid - Mouse is affected by Analog Speed. Since it moves only in the X axis, when acceleration is set to 25% it feels almost normal
• Arkanoid Returns - Mouse is affected by Analog Speed. Need to change DIP to sensor instead of Joy first
• Capcom Bowling - Mouse is affected by Analog Speed
• Millipede - Mouse is affected by Analog Speed
• Missile Command - Mouse is affected by Analog Speed
• SegaSonic The Hegehog - Mouse is affected by Analog Speed. This is probably causing also to stop the player every few seconds when running

Seems that all of them are affected the same no matter the driver. Let me know if you want me to test more games or configurations.

Kind Regards

[dinkc64]

Capcom Bowling, Millipede, Missile Command & SegaSonic all seem fine at 100% analog sensitivity here on the windows UI version of FBNeo. Hmmm, Let me consult barbudreadmon :)

@barbudreadmon can you try these games and see how they control on your side using the mouse? The BurnTrackball driver sets the mouse divider to 10 to get the mouse down to a reasonable speed, which is in intf/input/inp_interface.cpp line#314, could you verify that it's working properly on your side when using one of the games above?

note: arkanoid isn't using the trackball driver - I'll have to set this up

best regards,

• dink

[dinkc64]

I hooked up the trackball device to arkanoid, (fyi, it's a general purpose analog dial/spinner/trackball device, it's just named trackball device)

Also adjusted the default speeds for arkanoid 2, arkanoid returns, to work better with a mouse/spinner device with default settings, but, we'll have to see what's going on in the libretro side of things.

best regards,

• dink

[barbudreadmon]

@rtomasa Mouse motions are analog motions, so yeah they are gonna be affected by analog sensitivity. Do you have some sort of misunderstanding about that ? Are you maybe mistaking libretro's mouse device with libretro's pointer device ? The later is the one where in-game position is "injected" following the onscreen position of your pointer device (mouse, lightgun).

@dinkc64 It turns out i am not using the divider in the libretro port, yet it's quite playable without it on my side. Tbh it seems far less playable for me on millipede after testing the divider, i have to make large mouse motions to move only a bit, but i suppose that's fine since i can sort it out by increasing the analog sensitivity.

[rtomasa]

@barbudreadmon Both libretro mouse and pointer are the same except that the mouse movement is relative and pointer is absolute with some boundaries set. Mouse acceleration is a good feature for analog joysticks, but I would expect to have linear X/Y movement when using a mouse instead, otherwise the movement feels very erratic specially when default 100% sensitivity is set. You can compare the motion with other cores like MAME or ScummVM where the pointer moves with no issues. Another different thing would be a Mouse Speed Motion which could be very useful. Is there any technical reasons for only providing MIN 25% for the acceleration and not lower values to fully disable the same?

[barbudreadmon]

I would expect to have linear X/Y movement when using a mouse instead, otherwise the movement feels very erratic specially when default 100% sensitivity is set.

I don't understand what you mean, the movements are linear, analog sensitivity is simply a multiplicator of mouse motions. As its name suggest it does the same thing as retroarch's Settings > Input > Analog Sensitivity, except retroarch's one is indeed limited to analog stick.

Is there any technical reasons for only providing MIN 25% for the acceleration and not lower values to fully disable the same?

Yes, there are technical reasons : libretro has limitations about the number of different values for core options.

otherwise the movement feels very erratic specially when default 100% sensitivity is set.

Again, i'm not experiencing any playability problem with the default 100% value.

[barbudreadmon]

In case i wasn't clear about what i meant by "linear", let's use an example : If a mouse motion makes you move by 100px at 100%, the same motion will make you move by 200px if you set it at 200%.

(@dinkc64 correct me if i'm wrong, knowing that the only thing different about the libretro port was that i was previously not using the divider)

[rtomasa]

OK this afternoon/night once back from work, I'll be doing some more tests and provide examples and video for you to see the behaviour that I'm describing.

Maybe there are some differences when using different input drivers, but I need to check. I did not tell you that I'm using my own libretro frontend. In my case I'm using SDL2 and SDL_GetRelativeMouseState to provide the information to all cores and working fine in for example MAME and ScummVM.

I have another mate which is testing FBNeo in Retroarch in Windows and Linux + UDEV and is also facing the same results as me. I will be testing also older versions (we are testing with very recent compilations).

As a side note, I'm always using the libretro GIT repo https://github.com/libretro/FBNeo for compilation since it is the one containing the libretro.h implementation and burner. In this repo says to open the issues in the official on (this one). Let me know if I'm doing something wrong here.

I will let you know with the results today EOD hopefully.

[dinkc64]

@barbudreadmon, millipede / centipede with the mouse divider are pretty close to how it is when using a real trackball, it is correct to have to move the mouse almost the entire length of the mousepad to get from one end to the other of the playfield :)

@rtomasa, with the divider being implemented on the libretro side, thanks to barbudreadmon, the games you mentioned should be alright now - please give it a try with the latest code. The goal is to get all the games requiring mouse inputs to be fine @ the normal analog sensitivity settings, if you come across any other games that aren't right after the update, please let us know! :)

best regards,

• dink

[barbudreadmon]

@dinkc64 i was confirming what libretro's implementation of CinpMouseAxis does : it returns a value between -32768 and 32768 which corresponds to a position relative to the previous poll (meaning a 32768 value would mean you got from one border to the opposite border between 2 frames) Is standalone somehow returning something different ?

it is correct to have to move the mouse almost the entire length of the mousepad to get from one end to the other of the playfield :)

Hmmm ok, i'm used to not moving my wrist when moving my mouse, so this might explain the difference in perception.

[dinkc64]

I don't think its a position relative to previous poll, it's how much movement was made since the previous poll of the input device in an int16_t: a lot of movement -32768 no movement 0 a lot of movement 32767

It takes 59 frames to get from one side to the other in Millipede with Analog[0] = 32767 I added this hack to top of d_millipede's DrvFrame() to find out: extern int counter; if (counter) Analog[0] = 32767;

best regards,

• dink

[barbudreadmon]

a lot of movement -32768 no movement 0 a lot of movement 32767

CinpMouseAxis in the libretro port hardly ever returns a value outside of -1000 / 1000, and i'm already almost catapulting my mouse to reach those values, so i have a really bad feeling about dividing this value.

[dinkc64]

hmmmmm video time? bprintf(0, _T("%d, "), Analog[0]); at top of d_millipede's frame, grr, I can't make a video right now. well, some text: going slow, it's about 300-500 (plus or minus depending on direction) super fast, like, throwing the mouse, its 12000

[dinkc64]

Maybe try the win32/64 port on a pc somewhere and compare?

[barbudreadmon]

So CinpMouseAxis in standalone is basically 10 x the value in libretro, which would mean i wasn't wrong about inputs feeling fine without that divider.

[barbudreadmon]

Oh well, i'll leave things as they are, it doesn't seem that bad with that divider thingy : assuming CinpMouseAxis returns a value between -1280 and 1280, multiplying it by 0x100 (default nAnalogSpeed) then dividing it by 10 (nInputIntfMouseDivider), you end up with a 16-bits signed integer between -32768 and 32768. Increasing nAnalogSpeed is still possible anyway.

[rtomasa]

@dinkc64 @barbudreadmon it seems that there are some undefined references in current Main branch, so I could not compile it yet for testing:

...
/usr/bin/ld: ../../burn/burn.o:(.data.rel.ro+0x29f8): undefined reference to `BurnDrvsms_baraburu'
/usr/bin/ld: ../../burn/burn.o:(.data.rel.ro+0x99c0): undefined reference to `BurnSpecDucktalesru'
/usr/bin/ld: ../../burn/burn.o:(.data.rel.ro+0x107d8): undefined reference to `BurnDrvKaratblu'
/usr/bin/ld: ../../burn/burn.o:(.data.rel.ro+0x107e8): undefined reference to `BurnDrvKaratbla'
/usr/bin/ld: ../../burn/burn.o:(.data.rel.ro+0x107f0): undefined reference to `BurnDrvKaratblt'
/usr/bin/ld: ../../burn/burn.o:(.data.rel.ro+0x13c20): undefined reference to `BurnDrvmslugyq'
/usr/bin/ld: ../../burn/burn.o:(.data.rel.ro+0x1c328): undefined reference to `BurnDrvSonicfgtu'
/usr/bin/ld: ../../burn/burn.o:(.data.rel.ro+0x1e4a8): undefined reference to `BurnDrvSpinlbrj'
/usr/bin/ld: ../../burn/burn.o:(.data.rel.ro+0x1e4b0): undefined reference to `BurnDrvSpinlbru'
/usr/bin/ld: ../../burn/burn.o:(.data.rel.ro+0x1e4b8): undefined reference to `BurnDrvSpinlbrup'
/usr/bin/ld: ../../burn/burn.o:(.data.rel.ro+0x1f7c8): undefined reference to `BurnDrvCpsSfz3mix22f'
/usr/bin/ld: ../../burn/burn.o:(.data.rel.ro+0x23648): undefined reference to `BurnDrvKaratblj'
/usr/bin/ld: ../../burn/burn.o:(.data.rel.ro+0x23bb8): undefined reference to `BurnDrvTurbofrcua'
collect2: error: ld returned 1 exit status
make: *** [Makefile:750: fbneo_libretro.so] Error 1

[barbudreadmon]

it seems that there are some undefined references in current Main branch

No there isn't, it's just an issue on your side.

(build from a clean copy and you'll be fine)

[rtomasa]

OK I've cloned the repo again make clean compilation and worked fine.

So now I was testing all games with both my frontend using SDL2 and Retroarch using UDEV and it is worse than before for some games like millipede or missile command because lowering the sensitivity now makes the X movement very slow, and at default 100% it is very difficult to control the mouse movement because the Y axis goes up and down very fast with any subtle Y movement. Speed/acceleration is totally different between X and Y.

Both Arkanoid games now work well out of the box with mouse, probably because there is no Y movement involved.

[dinkc64]

make sure the axis are right, 0 is X 1 is Y 2 is Z (wheel) aka make sure the divider is only being applied to X and Y :)

from inp_interface:

            case GIT_MOUSEAXIS: {                   // Mouse axis
                INT32 nMouse = CinpMouseAxis(pgi->Input.MouseAxis.nMouse, pgi->Input.MouseAxis.nAxis) * nAnalogSpeed;

                if (pgi->Input.MouseAxis.nAxis != 2) { // X/Y axis only, exclude wheel
                    nMouse /= nInputIntfMouseDivider;
                }

[dinkc64]

oops, it should be in src/burner/libretro/retro_input.cpp (inp_interface is on the windows ui)

best regards,

• dink

[rtomasa]

Well the new code is already in retro_input.cpp, so it is what I have in my current compilation:

case GIT_MOUSEAXIS: {                   // Mouse axis
        INT32 nMouse = CinpMouseAxis(pgi->Input.MouseAxis.nMouse, pgi->Input.MouseAxis.nAxis) * nAnalogSpeed;

        if (pgi->Input.MouseAxis.nAxis != 2) { // X/Y axis only, exclude wheel
            nMouse /= nInputIntfMouseDivider;
        }

        // Clip axis to 16 bits (signed)
        if (nMouse < -32768) {
            nMouse = -32768;
        }
        if (nMouse >  32767) {
            nMouse =  32767;
        }
        pgi->Input.nVal = (UINT16)nMouse;
        *(pgi->Input.pShortVal) = pgi->Input.nVal;
        break;

[dinkc64]

What I'm saying is: if one axis is not being divided, there might be an issue with your axis numbering..maybe? Throw in some printf's to verify?

[rtomasa]

You mean from the frontend side? Well from the front end you don't even manage the axis by number. You listen to RETRO_DEVICE_ID_MOUSE_X and RETRO_DEVICE_ID_MOUSE_Y events and return the X/Y values that are provided directly by SDL_GetRelativeMouseState in my case. But do note that the same issue is happening to me in Retroarch using UDEV input driver.

I'll play around with retro_input.cpp this afternoon doing some tests and adding some printfs to see the current behaviour and let you know.

[dinkc64]

I'm not familiar at all with libretro and how it functions, all I can do is give ideas :)

@barbudreadmon, do the axises seem balanced on your side? (in missile command, millipede w/mouse)

[rtomasa]

@dinkc64 WoW did you make any additional change in the last hours? I've pulled and compiled again and now it works perfectly fine with default values.

[barbudreadmon]

WoW did you make any additional change in the last hours?

Sorry for the late answer, i just came back from work.

I made a hotfix this morning to apply the divider on every mouse axises (we never use the wheel anyway, i'm not even sure it's a thing with the libretro api) : https://github.com/libretro/FBNeo/commit/d48f1485e7052b97962594c18714de762214ae2b

I'm still concerned about the CinpMouseAxis discrepancies though. Could you confirm whether our nightly builds from https://github.com/finalburnneo/FBNeo/releases/tag/latest are more sensible or not ?

[rtomasa]

@barbudreadmon I confirm that the new compilation that I've tested already contains those changes and worked way better than before, actually I would say it works perfectly fine since I saw no more issues with the movement in any of the games I've tested.

BTW, looking at the libretro API, it supports all mouse events including wheel, middle button, and more, but I don't think they are useful for any arcade or console from the 90's. In my frontend I've only implemented X/Y, and buttons 1 and 2 and could not find any game requiring the wheel.

[dinkc64]

I use the wheel to play tempest on the Windows FBNeo :)

[rtomasa]

Arrrgggg! :-D but good to know some example

[barbudreadmon]

@rtomasa Could you please confirm whether our nightly builds from https://github.com/finalburnneo/FBNeo/releases/tag/latest seems more sensible (erratic ?) or not to you ? Tbh, if standalone's CinpMouseAxis returns values that are 10 times greater, i'd rather be in sync with it, since my goal with the libretro port remains to stay a 1:1 port as much as possible.

[rtomasa]

@barbudreadmon I'll try it this afternoon after coming back from work and let you know.

[rtomasa]

@barbudreadmon I've tested the Windows.x64.zip and works well. Played Missile Command and Millipede and all good. Also set it to 150% to speedup the pointer and also good. Let me know if you want me to test something else.

[barbudreadmon]

@rtomasa could you test whether adding a * 10 at https://github.com/libretro/FBNeo/blob/master/src/burner/libretro/retro_input.cpp#L466 gives you seemingly the same motion behavior as standalone ?

Oh well, don't bother, i looked into retroarch's dinput input driver and they are using pretty much the same code as our standalone builds. The discrepancies in the results are most likely due to the different input drivers. I'll be closing if this issue is considered fixed ?

[rtomasa]

From my side, I see no more issues after testing both windows + dinput, and linux + udev and sdl. You can close it and in case that I find any other issue in the future we can reopen this one or open a new one.