Transport Tycoon Forums

with fast-forward mode frame rate is upper, but mouse pointer moves with issues

better performance between opengfx, zBase, aBase and night gfx -- with aBase set

When it's running in fast-forward, is the graphics running smooth or does it still skip? (Mouse cursor aside.) Maybe try recording another short video if you can. Also try clicking the "Game loop total" line in the framerate window and capture that on screenshot or video.

(My idea with all these questions is to try to narrow down the cause of the slowness, whether it's coming from something related to the render loop timing, event handling, graphics output, or maybe something else.)

does OSX have an equivalent for "perf top", "perf lock", etc?

Eddi wrote:does OSX have an equivalent for "perf top", "perf lock", etc?

sorry, no - as i know
only top and vm_stat

jfs wrote:When it's running in fast-forward, is the graphics running smooth or does it still skip? (Mouse cursor aside.) Maybe try recording another short video if you can. Also try clicking the "Game loop total" line in the framerate window and capture that on screenshot or video.

(My idea with all these questions is to try to narrow down the cause of the slowness, whether it's coming from something related to the render loop timing, event handling, graphics output, or maybe something else.)

with fast-forward - the same
i have recorded small video, on start the mouse pointer not focused on openttd window, after some seconds - clicked on app window and you can see freezes again

I can confirm this issue.

On macOS, OpenTTD is unplayable with versions > 1.9.0. The framereate is around 10 FPS (full screen).

I'd like to add that this only accours when playing full-screen or full window. If I reduce the window size to 1/4 of the screen, the FPS increases to about 30.

No issues with 1.8.0.

Happy to provide more info.

Can you try toggling the "Full Animation" flag found under the Options (cogwheel/wrench) menu in-game?

for me, there is no difference when switch this option ("Full detail" too)
Frame rate radically decrease to 8fps when i open WaterWays Construction

Full animation on: ~15 FPS
Full animation off: ~30 FPS, scrolling the map reduces FPS to 15 again.

I opened a new ticket to track this bug: https://github.com/OpenTTD/OpenTTD/issues/7644

OpenTTD is causing color space / pixel format conversion in the background. Likely due to mismatch of backing surface format chosen by OpenTTD and native surface format of the display/OS.

The slowdown scales with OpenTTD resolution and Mac machine's high resolution exacerbates the problem. This format/color space conversion happens on OpenTTDs main thread after a call to CGContextDrawImageWithOptions.

I don't have time to look at this in the source, but that is where the problem comes from. Perhaps these pointers are enough information?

Will test with my (classic) Mac Pro with a GTX 680 card. It's hooked up to a 1440p monitor, non-retina. I'll test how this acts.
On a iMac 27" it is way to slow. 1.8.0 is playable, but also seems a lot slower than it should be (might be that the resolution is actually 2880p because of Retina?)
Haven't tested on my MacBook Pro 2018 yet, but will do - probably the same issue though.

If there is anything I can do to help, let me know (build, test etc).

I have the following Mac's that can be compared to a Windows PC (i5 + GTX 1060):

- MacBook Pro 2018 (not dedicated graphics)
- iMac 27" 2019 (RX 580)
- Mac Pro (2009->2010 flashed, six cores, GTX 680)

All running Mojave.

Had some time to look at this last evening and the issue is, as expected, due to a mismatch in colourspaces:

OpenTTD queries the system for the colourspace of the monitor. On many monitors (including external ones!) this returns a pretty standard sRGB colourspace which works just fine with how OpenTTD handles colours internally. What happens in this case, and which causes problems for OpenTTD, is that the main display of iMacs and MacBooks actually returns a P3 colourspace as its best fit because these displays are capable of more than what sRGB supports (they are pretty good displays!). Now OpenTTD tries to use P3 even though it really shouldn't as its outputting in the sRGB colourspace which means the pixel data is incompatible and thus won't look right. Additionally, the system introduces a conversion step from an internal image to the image the OS will use to show the window, this step is very costly as the P3 colourspace requires much more data per pixel than the usual sRGB space and the pixel formats involved in P3 are far more complex to convert between.

All relevant code for this problem is in wnd_quartz.mm. Here is a breakdown of it: The NSWindow that OpenTTD uses (created on line 287, WindowQuartzSubdriver::SetVideoMode) is in the P3 colourspace by default when running on the main display of a Mac. The CGContext that is used (created on line 605, WindowQuartzSubdriver::WindowResized) to store OpenTTD's drawing results internally is created with a colourspace from QZ_GetCorrectColorSpace (line 109) which returns whatever CGDisplayCopyColorSpace (line 116) returns which is in the case of running on the main display of a Mac; also P3. These two combined result in very slow calls to CGContextDrawImage (line 191 and 212, (void)drawRect:(NSRect)invalidRect) which is what drags down the performance of the game.

To get around the issue I made changes to 2 lines. Objective is to prevent running with a P3 colourspace. macOS is pretty smart and will make sure everything looks right even when mixing colourspaces as long as we tell it in what space the pixels we give it are. With that in mind I changed line 116 to always return a standard sRGB colourspace:
And added a new line after line 291 that sets the colourspace of the window to match the one we use internally:
With these two changes I get much improved performance and everything looks right. I can't make the actual change in the code for reasons so someone else will have to do that but it should be pretty straightforward. I should add that this fix did not go through extensive testing and there are edge-cases I'm likely unaware of but I think it should work for most if not all cases. Probably important to test on an external monitor too to see if that's still alright.

P.S.: If someone is willing to; is anyone else seeing issues with compiling the release version on macOS? I was seeing misaligned stack errors and had to enable debug mode to compile a working binary. Wondering if any of you sees the same error? I was compiling with Xcode 11 beta on Catalina.

We have released 1.9.3 RC1 which should solve this problem. Download
If there aren't any major issues this will be re-released as 1.9.3, perhaps as soon as later today or tomorrow. Please get to testing

jfs wrote: ↑08 Sep 2019 06:57 We have released 1.9.3 RC1 which should solve this problem. Download
If there aren't any major issues this will be re-released as 1.9.3, perhaps as soon as later today or tomorrow. Please get to testing

thank you!
i can confirm that 1.9.3rc works without freezes on last macosx

Hi everyone. I came here through the bug report on Github. The bug thread itself already contains more information, but I just wanted to affirm that there's still a problem even with the latest builds. I've been stuck on 1.8.0 for that reason.

Funny thing is that running 1.9.3 on Windows (through a Windows 7 VM, running on the same OSX host system) works absolutely fine. I'd use that but unfortunately there's something weird about the mouse when running the game in the VM (not OpenTTD's fault but the VM's, I'm sure), so that doesn't quite work either. But that definitely shows this is a weird OSX-only bug.

I'll see if I can compile both versions myself later to see if that shows anything more. Just wanted to at least leave a reminder that the mystery performance regression is still there as of 1.9.3.

Yes, andythenorth repeatedly complains about it on IRC, still

More recently, he's been able to reproduce a situation where a small change in the time taken for the game loop (from e.g. average 2 ms to average 3 ms) causes a massive drop in overall framerate (from 34 to 17 fps), which should really only happen if the game loop time was rising as high as 60 ms.
This behaviour is more proof for my suspicion that the poor performance is caused by something related to timers, timer accuracy, OS scheduler allocation of time slices, or Vsync. My best explanation for that kind of behaviour would be that when the game loop time crosses a certain threshold, it runs late for a deadline required for something to be able to run at 33.3 Hz, and ends up running at 16.7 Hz instead.