upbge icon indicating copy to clipboard operation
upbge copied to clipboard

Mouse wheel input events get ignored when V-sync is enabled

Open mysticfall opened this issue 3 years ago • 11 comments

I found that mouse wheel related input events get ignored when the framerate is low. e04bff5 seems to fix the problem when the Use Frame Rate option is not enabled. However, it still shows the same symptom when it's checked and it gets worse as I add more objects to the scene.

mysticfall avatar Nov 23 '20 17:11 mysticfall

Increasing logic steps in scene properties improves the events detection?

youle31 avatar Nov 23 '20 20:11 youle31

Increasing logic steps in scene properties improves the events detection?

I just tested it again with 20 and 100 steps and it doesn't seem to affect the symptom.

mysticfall avatar Nov 23 '20 21:11 mysticfall

I detected that ConvertMoveEvent and ConvertWheelEvent process correctly the events but while the mouse position is processed correctly by SCA_PythonMouse, the wheel not. I used this little patch https://gist.github.com/lordloki/dc0a82bd7607b1bb781f7ab1eb21dea6 and this blend test_mouse_wheel_0.3_upbge.blend.zip to detect the event processed by one and another.

In the screenshot you can see that several events are processed by ConvertWheelEvent but not by SCA_PythonMouse. image

With the mouse position is done correctly image

lordloki avatar Nov 23 '20 22:11 lordloki

There are many topics about vsync and mouse on the net (I just typed: "vsync mouse issues opengl") and there are many topics talking about swapinterval, synchronisation, input lag...

I think you already found the solution to your issue: disabling vsync when you can't get a framerate equal to your monitor refresh rate. Some topics are talking about introducing a quick sleep time just before processEvent (LA_Launcher.cpp) but if disabling vsync solve the issue, i'd keep it as a valid solution to the problem.

youle31 avatar Nov 30 '20 04:11 youle31

There are many topics about vsync and mouse on the net (I just typed: "vsync mouse issues opengl") and there are many topics talking about swapinterval, synchronisation, input lag...

I think you already found the solution to your issue: disabling vsync when you can't get a framerate equal to your monitor refresh rate. Some topics are talking about introducing a quick sleep time just before processEvent (LA_Launcher.cpp) but if disabling vsync solve the issue, i'd keep it as a valid solution to the problem.

While it's true that disabling vsync serves well for my current project, I regard it as a workaround rather than a proper solution.

I can understand if mouse input feels jerky when the framerate is low. But only mousewheel events mostly get ignored while all the other mouse events work fine feels to be a too severe a symptom to think of it as something expected.

mysticfall avatar Nov 30 '20 05:11 mysticfall

I think the system is setup to skip events and 'catch up' if it's behind

'missing events' is a symptom of draw / input / logic being tightly coupled I think

On Sun, Nov 29, 2020 at 9:07 PM Xavier Cho [email protected] wrote:

There are many topics about vsync and mouse on the net (I just typed: "vsync mouse issues opengl") and there are many topics talking about swapinterval, synchronisation, input lag...

I think you already found the solution to your issue: disabling vsync when you can't get a framerate equal to your monitor refresh rate. Some topics are talking about introducing a quick sleep time just before processEvent (LA_Launcher.cpp) but if disabling vsync solve the issue, i'd keep it as a valid solution to the problem.

While it's true that disabling vsync serves well for my current project, I regard it as a workaround rather than a proper solution.

I can understand if mouse input feels jerky when the framerate is low. But only mousewheel events mostly get ignored while all the other mouse events work fine feels to be a too severe a symptom to think of it as something expected.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/UPBGE/upbge/issues/1330#issuecomment-735547904, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABW3SWJEAYAHA2NKLUNIT53SSMSCPANCNFSM4T7ZH4MQ .

BluePrintRandom avatar Nov 30 '20 05:11 BluePrintRandom

Wheel is not like a mouse click. Click is active while you have the button pressed. Mouse wheel is active only 1 time i guess. It must make it harder to detect

youle31 avatar Nov 30 '20 05:11 youle31

I think the system is setup to skip events and 'catch up' if it's behind 'missing events' is a symptom of draw / input / logic being tightly coupled I think.

Yeah, what I meant was I can fully understand how some events might be skipped when the system cannot keep up with the requested framerates.

But when I rotate my mouse wheel randomly for 5 seconds, only 2-3 events get registered which renders the mouse wheel completely unusable, while other events like mouse move events or button clicks all work without causing much problem.

mysticfall avatar Nov 30 '20 06:11 mysticfall

This file seems to work well enough for me: https://pasteall.org/blend/971e1a6f7c61498788855ea1043977d4

(I run it at 6 fps. Wheel counter seems to increase normally except when i rotate the wheel very very fast. I don't see any noticeable chenge with or without vsync)

youle31 avatar Dec 01 '20 00:12 youle31

Ok, It works but when we have low fps AND we don't change of type of event instead of a lot events we have an unique event with several input.status or input.queue. I mean for:

for key, input in mouse.activeInputs.items():
            print(key, input.status, input.queue)

if you have good fps and only turns the mouse wheel down then you print:

#event (bge.events.WHEELDOWNMOUSE), input.status(only 1 active status), input.queue (only 1 justactived) 
123 [0,2] [1]
#event (bge.events.WHEELDOWNMOUSE), input.status(only 1 active status), input.queue (only 1 justactived) 
123 [0,2] [1]
#event (bge.events.WHEELDOWNMOUSE), input.status(only 1 active status), input.queue (only 1 justactived) 
123 [0,2] [1]
#event (bge.events.WHEELDOWNMOUSE), input.status(only 1 active status), input.queue (only 1 justactived) 
123 [0,2] [1]

but when you have bad fps and only turns the mouse wheel down then you print:

#event (bge.events.WHEELDOWNMOUSE), input.status(only 4 active status), input.queue (only 4 justactived) 
123 [0,2,2,2,2] [1,1,1,1]

The number of events of the same type is shadowed. Then you will have to make:

    def update(self):
        mouse = bge.logic.mouse
        scene = bge.logic.getCurrentScene()
        
        for key, input in mouse.activeInputs.items():
            if (key == bge.events.WHEELDOWNMOUSE):
                for num_input in input.status:
                    if (num_input == bge.logic.KX_INPUT_ACTIVE):
                        scene.objects["Cube"]["wheel"] += 1

Maybe you will have to reduce the number of inputs obtained when you move fast the wheel. mouse_wheel_text_mysticfall.zip

lordloki avatar Dec 01 '20 05:12 lordloki

Now, I understand better where the issue is. I will improve a bit the solution.

lordloki avatar Dec 01 '20 08:12 lordloki