SDL mouse handling code is broken

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: SDL mouse handling code is broken

Re: SDL mouse handling code is broken

by _mental_ » Sat Jun 08, 2019 4:19 am

Fixed in aa75f08.

Re: SDL mouse handling code is broken

by _mental_ » Sat Jun 08, 2019 2:57 am

I have posted a few comments in PR. I cannot run it at the moment, so I could get something wrong though.

Re: SDL mouse handling code is broken

by Gutawer » Sat Jun 08, 2019 2:44 am

Re: SDL mouse handling code is broken

by _mental_ » Sat Jun 08, 2019 2:41 am

Please do a PR, it's much easier to comment there.

Re: SDL mouse handling code is broken

by Gutawer » Sat Jun 08, 2019 2:31 am

Thanks for taking a look, but I don't feel like this fix is really complete. There's a bunch of other bugs in this code such as the EV_GUI_BackButtonDown/Up and EV_GUI_FwdButtonDown/Up events never being fired and the button mappings for all of the extra mouse buttons (MOUSE4-8) being handled wrong. This is my proposed fix for all the issues: https://github.com/Gutawer/gzdoom/commi ... 9135e05dcb. Hopefully this should be tested by anyone who runs Linux/any other OS where the SDL backend can be used (my comment in the code reflects that hopefully this should have been done before merging).
There is one other issue which I'm not sure exactly how to fix, which is that the event handler requireMouse field is never actually checked in SDL, so event handlers will always get mouse events regardless of whether they want them.

Re: SDL mouse handling code is broken

by _mental_ » Sat Jun 08, 2019 2:29 am

I guess you forgot about else block. Anyway, please post code. It's not obvious how you propose to change it.

Re: SDL mouse handling code is broken

by Edward-san » Sat Jun 08, 2019 2:22 am

Actually, see here. The check is there, but the order of the checking was inverted.

Re: SDL mouse handling code is broken

by _mental_ » Sat Jun 08, 2019 2:01 am

I have pushed the fix. Although, I tested it on macOS where SDL backend can behave differently from Linux. In any case, wrong event data were read, so an extra check is needed.

Re: SDL mouse handling code is broken

by Gutawer » Fri Jun 07, 2019 4:45 pm

Just a heads up - I've decided to fix this myself. I'm heading to bed now but in the morning I'll finish fixing stuff up and get some people to test if my fixes work on their machines.

SDL mouse handling code is broken

by Gutawer » Thu Jun 06, 2019 3:57 am

So I was writing a menu today and wanted to make it respond to right clicking and dragging, when I discovered that right clicking and dragging wasn't working for me as no Type_MouseMove event was getting fired. I've made sure that it works fine on Windows by asking Nash to run the code I was using:

Code: Select all

class Test : EventHandler {
    override void WorldTick() { isUiProcessor = true; requireMouse = true; }
    override bool UiProcess(UiEvent e)
    {
        if (e.type == UIEvent.Type_MouseMove)
        {
            Console.printf("%d", gametic);
        }
        return false;
    }
}
On either OS, moving the mouse around here prints the gametic continuously. On Windows, pressing right click does nothing to this and it carries on going, but on Linux, it stops printing the gametic immediately, so the event isn't being fired. I've looked into the code at src/i_input.cpp and after some googling and talking to Marisa Kirisame on Discord, the issue seems to be this sort of thing:

Code: Select all

	case SDL_MOUSEBUTTONDOWN:
	case SDL_MOUSEBUTTONUP:
	case SDL_MOUSEMOTION:
		if (!GUICapture || sev.button.button == 4 || sev.button.button == 5)
		{
SDL_Event is a union, so this is treating sev as if it's a Button event regardless of if it's actually a Motion event. This appears to basically be invoking undefined behaviour, and the exact same issue can be found at https://stackoverflow.com/questions/129 ... consistent.
I'd attempt to fix this myself but I tend to avoid SDL so have no significant experience working with it.

Top