OS X and 1.9.0 version

Got a problem with OpenTTD? Find some help here.

Moderator: OpenTTD Developers

dimaloop
Engineer
Engineer
Posts: 12
Joined: 04 Apr 2019 08:43

Re: OS X and 1.9.0 version

Post by dimaloop » 28 Apr 2019 11:00

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
Attachments
Снимок экрана 2019-04-28 в 12.55.29.png
retina 5k test
(122.85 KiB) Not downloaded yet

User avatar
jfs
Director
Director
Posts: 610
Joined: 08 Jan 2003 23:09
Location: Denmark

Re: OS X and 1.9.0 version

Post by jfs » 28 Apr 2019 18:54

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.)

Eddi
Tycoon
Tycoon
Posts: 7424
Joined: 17 Jan 2007 00:14

Re: OS X and 1.9.0 version

Post by Eddi » 29 Apr 2019 02:10

does OSX have an equivalent for "perf top", "perf lock", etc?
You might not exactly be interested in Ferion, but if you are, have fun :)

dimaloop
Engineer
Engineer
Posts: 12
Joined: 04 Apr 2019 08:43

Re: OS X and 1.9.0 version

Post by dimaloop » 10 May 2019 12:08

Eddi wrote:does OSX have an equivalent for "perf top", "perf lock", etc?
sorry, no - as i know
only top and vm_stat

dimaloop
Engineer
Engineer
Posts: 12
Joined: 04 Apr 2019 08:43

Re: OS X and 1.9.0 version

Post by dimaloop » 10 May 2019 12:21

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

wousser
Engineer
Engineer
Posts: 3
Joined: 06 Nov 2007 20:25

Re: OS X and 1.9.0 version

Post by wousser » 01 Jul 2019 08:17

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.

User avatar
jfs
Director
Director
Posts: 610
Joined: 08 Jan 2003 23:09
Location: Denmark

Re: OS X and 1.9.0 version

Post by jfs » 01 Jul 2019 09:54

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

dimaloop
Engineer
Engineer
Posts: 12
Joined: 04 Apr 2019 08:43

Re: OS X and 1.9.0 version

Post by dimaloop » 01 Jul 2019 10:15

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

wousser
Engineer
Engineer
Posts: 3
Joined: 06 Nov 2007 20:25

Re: OS X and 1.9.0 version

Post by wousser » 01 Jul 2019 13:53

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

User avatar
jfs
Director
Director
Posts: 610
Joined: 08 Jan 2003 23:09
Location: Denmark

Re: OS X and 1.9.0 version

Post by jfs » 08 Jul 2019 20:35

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

SoothedTau
Engineer
Engineer
Posts: 2
Joined: 16 Aug 2019 05:17

Re: OS X and 1.9.0 version

Post by SoothedTau » 16 Aug 2019 05:23

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?

nordemoniac
Engineer
Engineer
Posts: 52
Joined: 11 Jun 2011 18:45

Re: OS X and 1.9.0 version

Post by nordemoniac » 27 Aug 2019 08:55

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.

SoothedTau
Engineer
Engineer
Posts: 2
Joined: 16 Aug 2019 05:17

Re: OS X and 1.9.0 version

Post by SoothedTau » 04 Sep 2019 18:02

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:

Code: Select all

colorSpace = CGColorSpaceCreateWithName(kCGColorSpaceSRGB);
And added a new line after line 291 that sets the colourspace of the window to match the one we use internally:

Code: Select all

[this->window setColorSpace:[[[NSColorSpace alloc]initWithCGColorSpace:QZ_GetCorrectColorSpace()] autorelease]];
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.

User avatar
jfs
Director
Director
Posts: 610
Joined: 08 Jan 2003 23:09
Location: Denmark

Re: OS X and 1.9.0 version

Post by jfs » 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 :)

dimaloop
Engineer
Engineer
Posts: 12
Joined: 04 Apr 2019 08:43

Re: OS X and 1.9.0 version

Post by dimaloop » 08 Sep 2019 16:53

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
:lol:

Post Reply

Return to “OpenTTD Problems”

Who is online

Users browsing this forum: No registered users and 7 guests