FS#221 - Some mouse events are lost when using the SDL driver

Attached to Project: OpenTTD
Opened by init (init) - Tuesday, 27 June 2006, 20:25 GMT
Last edited by KUDr (KUDr) - Wednesday, 15 November 2006, 13:42 GMT
Type Bug
Category Interface
Status Closed
Assigned To KUDr (KUDr)
Operating System Linux
Severity Medium
Priority Normal
Reported Version trunk
Due in Version 0.5.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


When playing the game using SDL for video and input, some mouse events are lost. This applies to fast clicks with a mouse button, such as when clicking a button. The click is simply not detected by the program, and is quite irritating. I have to apply this patch to play, otherwise the game is nearly unplayable (although that might just be my personal preference).

The problem is that the program does not ensure that mouse button events are received properly by those UI elements that may receive them. A mouse press simply sets a global flag for the corresponding button to true, and clears it when the button is released. In the game main loop, each round the input queue is (completely) processed once. If both the button press and the button release events appears in the event queue while the queue is being processed, the flag will be set and cleared before the rest of the code have any chance of reacting to this information (since this happens outside the processing of the input queue).

I have written a patch that solves this problem. It adds code on the receiving end that flags the input processor when the input events have been seen, and updates the input processor to act accordingly. Thus, the button flags cannot be cleared before the receiving end has seen the new state.

There is also a related drag problem, mostly seen when dragging signals along a track. If you click and drag quickly from the starting point, the game will detect the drag as beginning not where you clicked but one tile along the dragged path. This means that if you click on a one-way signal, the game will think that you clicked on the next tile, that hasn't got any signals, and therefore create two-way signals at the perceived starting point and onwards. This problem is not fixed in the patch though, since I have not yet figured out how dragging works.

The patch works for SVN revision 5388.
This task depends upon

Closed by  Darkvater (Darkvater)
Wednesday, 15 November 2006, 21:01 GMT
Reason for closing:  Fixed
Additional comments about closing:  r7157
Comment by init (init) - Saturday, 01 July 2006, 00:10 GMT
Updated patch to work with rev 5435. Also changed patch indentation to clarify what it actually does. This also reduced the sice of the patch by about 20%.
Comment by KUDr (KUDr) - Wednesday, 15 November 2006, 12:57 GMT
This one should solve the problem for both drivers (SDL and Win32) and both inputs (mouse and key).
Comment by KUDr (KUDr) - Wednesday, 15 November 2006, 14:51 GMT
Here are handled also keys for cocoa (dunno if it will work):