Rocks'n'Diamonds

Using a touchpad, vertical scrolling is normal (two fingers up goes up, two fingers down goes down), however horizontal scrolling is reversed (two fingers left goes right, two fingers right goes left). Toggling the reverse or so-called "natural" scrolling toggles in system settings ... well, seems to vary. On another system it kept horizontal scrolling reverse but also made vertical scrolling reverse. On this system it actually reverses both, horizontal scrolling is now normal, but vertical scrolling is reversed.

I'm not even sure this is a rocksndiamonds problem, it could be an SDL problem. The browser versions are unaffected, both horizontal and vertical scrolling are normal at least under Firefox. I could not test the Windows version of RnD under WINE because it for whatever reason will not open under WINE now on this system.

I also tried an older version, 3.3.1.2, which apparently completely lacks horizontal scrolling via touchpad, heh... drag scrollbar only there

I think this problem is inevitable. That is: there are so many layers of interpretation involved in both of these binary toggles ('left/right natural scrolling' & 'up/down natural scrolling') that it is inevitable that some of the time, on some systems, one or both directions will be screwy.

Therefore, as a matter of self-defense, programs which might care at all about these things should have two separate settings which amount to: 'invert left/right scrolling [yes/no]', 'invert up/down scrolling [yes/no]'. They should not use the word 'natural' or anything like that; the point is simply to toggle whatever conclusions the rest of the system has come to, and whether the user thinks of the final result as 'natural' or not is completely irrelevant and distracting.

I think that filbo is right about both the cause of such problems (too many layers of system, library and application code trying to do the "right thing") and also a possible solution for it (optionally reversing scroll directions directly in the application, separately for horizontal and vertical directions).

The observation that the browser version differs in behavior from the standalone version seems to suggest that some layer below the R'n'D code is causing this trouble. I will have a look at this, to see how events are handled in these cases.