Transport Tycoon Forums

kaaremai001 wrote:This is NOT true. I have tested it with three different mouse brands and it's all the same. As this is only a problem in OpenTTD i'm inclined to believe that the fault is within this game somewhere...

Of course it is a bug of OpenTTD, but devs are ignoring this fact. Doesn't matter in which part of OpenTTD this bug present: 3rd party library or whatever. If this is a part of OTTD then it should be fixed.

I've been expecting this issue will arise after RS3 release. I wonder why devs were not expecting this.

Frustrated and bored I tried other versions of openttd. Right scroll works with 1.4.4

1.5.3
1.6.1
1.7.1

are still broken.

1.5.0
1.5.1
1.5.2

also broken, so something must have changed after 1.4.4

probably something to do with this:

1.5.0-RC1 (2015-03-18)
------------------------------------------------------------------------
- Fix: GCC 5 compilation (r27185, r27183)
- Fix: Compilation with MinGW64 (r27176)
- Fix: Windows randomly drops SetCursorPos calls, breaking the RMB-scrolling [FS#6238] (r27172)

1.5.0-beta2 (2015-02-24)
------------------------------------------------------------------------
- Fix: [SDL, Windows] Right-mouse-button scrolling scrolled/jumped too far, when OpenTTD lagged during mouse event processing (r27167)

?

I've got the same problem. From the point of user's view, I think it is somehow related to display scaling in Windows 10 (used on high-DPI devices). But after installing Windows 10 Fall Creators Update the problem is much bigger. Now panning is so random... openttd is not playable.

Yesterday I downloaded openttd sources, compiled the minimum version of it (without direct music support and without many misc libraries: zlib, lzo, lzma, png, freetype, icu), debugged the code, and found a workaround on source code level.

The patch working for me is:
file win32_v.cpp, line 750:
if (_cursor.UpdateCursorPosition(x, y, false)) {

I've only changed true to false in the mentioned line to avoid queued mouse events processing inside CursorVars::UpdateCursorPosition. When building with SDL video driver (not my case), you'll find similar line in sdl_v.cpp (line 535).

Note: It seems to be the workaround only. As fas as I understand the code, queued mouse event processing was introduced to improve cursor behaviour "esp. when OpenTTD lags a bit" (quote from source code comment). My observation is: on modern PCs processing the queue is not required. That's why I disabled it, not trying to find the bug in processing (I don't know the sources well, spent 2 hours on the whole process).

Feel free to share this observation with anyone/pass info to developer team. Maybe someone more experienced will take a closer look at it...

Same here, right after the latest Windows 10 update. I understand it's due to a Windows change, but this issue makes the game unplayable.

After spending a while in front of the code, I have a suspicion about the root cause. I'm basing this on r27167 and r27172 (both between 1.4.x and 1.5.0; I found them before reading tomb's message) which were supposed to fix rightclick scrolling. The underlying issue is that rightclick scrolling locks the cursor in place. This is achieved by warping the cursor back to the position it was in when starting the scroll action. That by itself is not yet an issue, but when cursor warping does not "rebase" (speaking in Git version control terms) later cursor movement events already in the queue on top of the new cursor position, things get complicated. OpenTTD has to deal with that in its win32 and sdl video drivers (judging by the queued_warp parameters passed to UpdateCursorPosition - this is what tomb changed).
OpenTTD has to guess what source cursor position a mouse movement event is based on so it can calculate the difference between source and destination (because it wants to know the relative movement). To top it off, a Windows bug (see r27172) seems to randomly cause it to ignore the calls setting the cursor position.

The "fix" discovered by tomb will very likely break stuff (at least on older Windows versions) as it essentially lets OpenTTD's win32 video driver assume that all cursor movements in the queue are based on the position the cursor is locked at. It could be that Windows did actually get changed to "rebase" the cursor movements, or you just got lucky. After all, the behavior will be pretty much identical to what was present in 1.4.x which sometimes did misbehave, making the fixes in r27167 and r27172 necessary.

As a temporary fix, the cursor position locking could be disabled. That will feel very wrong though, unless you enable the setting to reverse the scroll direction. Therefore I propose to disable it only when reverse scrolling is on. I need someone who experiences the scrolling issue and can compile their own version to test that fix (maybe you, tomb?) - just open window.cpp, search for and replace it with and recompile. Test it with reverse scrolling on (duh). That should work just fine.

If Windows was changed to "rebase" the cursor movements, then changing tomb's fix to ask Windows if it's new enough should suffice as a better fix. However, I don't know how that would be done (my software normally isn't written for Windows), and I don't know if that's what Microsoft changed, so that could revert the situation to pre-1.5.x for users on the new Windows version.

@3298:
Thanks for your comments, now I understand more.

After applying your temporary fix, panning is ok, but - as expected, and mentioned by you - the cursor moves while panning. "Reverse scrolling on" is also something strange for me. So, we've got two workarounds now, zero solutions. Yet.

Make it an option to enable/disable it in a configfile or in the settings?

Lighteye wrote:Make it an option to enable/disable it in a configfile or in the settings?

Lighteye: but enable/disable what?? If you read carefully above, it's only workarounds for the issues on panning that appeared with Creator Update for Windows 10.

Please note: Are workarounds!!

No solution but just to confirm as per others that it worked yesterday and today it does not.

Difference Windows update to latest Windows 10 1709

Changing to 'left click scroll' makes it playable.

Oddly enough, on my laptop the problem mostly disappeares when plugged in and the performance slider is all the way to the "Best performance" option. See if this helps anyone else.

It has been pointed out before but I will repeat it this time. Problem didn't appear with Windows 10 Creators Update (Version 1703) but was raised with the Fall Creators Update (Version 1709). Same happened to me since the update.

Also, disabling pointer acceleration didn't change anything.

CharlyHRO wrote:It has been pointed out before but I will repeat it this time. Problem didn't appear with Windows 10 Creators Update (Version 1703) but was raised with the Fall Creators Update (Version 1709). Same happened to me since the update.

Also, disabling pointer acceleration didn't change anything.

The same thing is happening to me.

has anybody tried using windows 10 compatibility settings to run OTTD as windows 7 and/or disable windows screen scaling.

TimeLapse1357 wrote:has anybody tried using windows 10 compatibility settings to run OTTD as windows 7 and/or disable windows screen scaling.

Tried 8, 7 and Vista compatability, no change.

Microsoft compatability program says the program (OTTD) is incompatable.

I have the same trouble. On 3 different PC with W10 1709 with 3 different mice. But on 4th is installed W10 1703 and without problem. If you have any solution please help me. Because OpenTTD is great game.

Herry wrote:I have the same trouble. On 3 different PC with W10 1709 with 3 different mice. But on 4th is installed W10 1703 and without problem. If you have any solution please help me. Because OpenTTD is great game.

welcome to the club ^^
2 of the machines I use got the 1709 update and, since I needed things working on the BTPro world, I compiled a client using tomb's workaround.

Link for the changes can be found here (check Readme.txt file), but remember, it's a modified client, but compatible with 1.7.1 (currently) servers so, issues you have with it must be reported there, unless that can be recreated with vanilla OpenTTD.

I'm only posting the link to BTPro forum because tomb's workaround made panning map with mouse right button work normally again after W10 1709 update. "tomb", came on this issue and figured out this workaround and I compiled BTPro client with it. Please remember, it's a workaround that can break other things on the game that I can't understand.

Enjoy OpenTTD games, because it's a great game (known fact ^^)

Edit: if the workaround works, say something ^^

Lighteye wrote: Since I installed Windows 10 Fall Creators Update yesterday the problem exists.

This has now occured for me. This morning I got the fall creators update, and now the scrolling on OpenTTD with RMB is completely messed up. This occurs in trunk, and also JGRs patchpack.

Hope OpenTTD can quickly overcome this issue! No idea why Win10 doesn't allow this action anymore.

quoting frosch: "Apparently W10 has a (new) method to retrieve relative mouse movement", here

ST2 wrote:quoting frosch: "Apparently W10 has a (new) method to retrieve relative mouse movement", here

It would be awesome if someone ask frosch about any ETA. According to bug tracker this issue is 2 weeks old.

eshield wrote:

ST2 wrote:quoting frosch: "Apparently W10 has a (new) method to retrieve relative mouse movement", here

It would be awesome if someone ask frosch about any ETA. According to bug tracker this issue is 2 weeks old.

ETA of what? As far as I am aware, OpenTTD has not allocated any staff to this problem because it has no paid staff. OpenTTD does however gladly offer full refunds of your purchase cost of the game if you are unsatisfied with the support at any time.