Seems like most of the map is not redrawn. See screenshot, which was taken after resizing the window.
Edit: this is a version without multithreading. It works fine with a multithreaded compile.
Scrolling the map around creates a much more interesting effect for a screenshot!
Clearly nobody who self builds single threaded uses the smart hide cursor setting... Much better when the ground outside the hide radius is actually drawn - try r8300.
I didn't know there was such a thing as smart hiding. Then again, I never trust claims that anything a computer does is smart.
QuoteClearly nobody who self builds single threaded uses the smart hide cursor setting... Much better when the ground outside the hide radius is actually drawn - try r8300.
A bigger question one should be asking is why one can still build Simutrans without multithreading support in 2017. Even modern smart phones have 6 cores...
At some stage pthreads should probably become mandatory so a lot of duplicate code and macros can be removed to avoid bugs like this. I think it already is mandatory for Simutrans Extended for performance reasons.
Threading is difficult when working on the same mutable data structure. Sometimes even counter-productive. Apparently, there are still bugs in there, and they are difficult to track down. And Simutrans appears to only use threading when working on the same data structure. It would be much less error prone to remove the threading from the rendering, and introduce threading in the routing code where you only need to read shared data, and only when it is not mutating.
Although this build is limited to non-threaded builds, it is only a visual glitch, unlike the bug related to smart hiding in multithreaded builds, which locks everything up with complete loss of data. That makes me still happy to be able to stay away from the threaded builds. (Although mingw64 insists on linking against pthreads anyway. And it also insists on linking that particular library dynamically, unless I remove the files needed for that.)