I see that even when the value of the scroll speed is changed in the display panel of Simutrans 120.0.1, holding the right mouse button to scroll around will cause the view to be throw across or off the map. Even at the setting of 1, the scroll speed acts like it's on 9. Why is this?
I can not reproduce this behavior, although my Simutrans is closer to 120.1.1 than 120.0.1. Which OS are you running Simutrans on? If this is a bug in Simutrans, you will have to upgrade to get it fixed, so you should consider upgrading to 120.1.1 and see if it has been fixed already.
I've just tried pak64, 128, and 128brit on 120.1.1, while running on Windows 10, and the issue is present throughout all instances.
I have the same issue here. I just gave up and use the arrow keys instead. But if the mouse would work again, that'd be lovely.
Do you know if you are using the SDL or the GDI version? I've only tested the latter, and it works like it "always" has. And it is not stuck at maximum, because I tried turning up the scroll speed, at that made a difference, as did turning it back down.
How do I check? I am just using the versions downloaded from the scourgeforge, and I don't remember making a choice between either of those.
Enable/Disable in the properties of simutrans.exe file the DPI Scaling
that affects Windows 8.x - 10
option in german "Skalierung bei hohem DPI-Wert deaktivieren"
Disabling the DPI scaling worked. Thanks.
Quote from: Quakke on December 30, 2015, 02:36:41 PM
How do I check? I am just using the versions downloaded from the scourgeforge, and I don't remember making a choice between either of those.
Easiest way is to check is look at your mouse, if it's the same from the OS you're using GDI, if it's black like a Mac mouse, then it's SDL.
Are there any developers that have this problem? That users have to go into the file/shortcut attribute dialog and tweak this is not good. I have some possible solutions to try, but since I don't have this problem myself, I can't test if they actually work.
I'm using Win7; No intention of changing until absolutely necessary. I think everyone else is too...
I did just get a chance to try on a Win8.1 laptop - yikes, never mind scroll speed 9, more like 99999+. Completely unusable.
I can also confirm disabling the scaling fixes the problem - thanks Frank. The laptop has a mere 1920x1080 screen and the scale is set to the middle position. Hardly high DPI...
I think there's an Win8+ API call, but if we use that, Win7 and older wouldn't work.
Maybe the online installer can configure this? I can check next week. I think most Windows users install using it; Any who install manually would need to change this setting themselves.
In English: (for Win8.1)
simutrans.exe: properties \ compatibility tab \ setting section \ "Disable display scaling on high DPI settings" checkbox
Quote from: TurfIt on December 31, 2015, 09:16:58 PM
I think there's an Win8+ API call, but if we use that, Win7 and older wouldn't work.
Maybe the online installer can configure this? I can check next week. I think most Windows users install using it; Any who install manually would need to change this setting themselves.
It should be possible to specify DPI scaling support in a manifest. I'm unsure if Simutrans should claim to support DPI scaling or not. The latter seems likely to be the default. There is also the question of whether claiming such support means we have to process inputs differently, or if that only applies when operating on with points as a unit, while Simutrans only deals with pixels.
I have been able to reproduce it. It looks like due to Windows' DPI scaling, there is a rounding error when trying to move the cursor back to the original position. That means that we never get back to a situation where mx==cx && my==cy, causing constant scrolling by one pixel (before scroll speed scaling) along one or both axes.
I have not gotten a manifest to make any difference. I don't even know if I've gotten Windows to even consider the manifest, or if there are silent parse errors causing Windows to ignore the manifest completely, as Windows didn't complain when I omitted many elements listed as required.
Update:
Got something working that caused Windows to stop doing DPI scaling for Simutrans. The downside is that on high DPI screens, Simutrans will be proportionally smaller, as I expect it is on other OSes. On the other hand, the graphics doesn't get blured by the scaling. What I've done is tell Windows that Simutrans understands per-monitor DPI, which arguably is a lie.
Apart from that, there are two problems with the changes in the attached patch. 1) simres.o now has a dependency on Simutrans.manifest, but this is not reflected in the .d file generated by GCC. This means that changing Simutrans.manifest does not cause recompilation of simres.o. Hardcoding this dependency in Makefile causes the .d file to be ignored, which means that changes in simversion.h does not cause recompilation of simres.o. 2) The manifest is technically not correct. It's missing the supposedly required assemblyIdentity element. If this element is present, it must contain a version attribute or the program won't start, and I can't (at least easily) filter the version definitions from simversion.h into the manifest file. I don't get any errors from omitting the element entirely, so that's what I did.
Thank you. I played around with manifests in November, but aparently forgot to submit them. Included in r7709.
The res file gets newly build by each revision, so a dependece on the manifest is needed only if you hacking the manifest a lot ...