Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fast forward on macOS is restricted by frame refresh rate #6546

Closed
DorpsGek opened this issue Mar 17, 2017 · 11 comments
Closed

Fast forward on macOS is restricted by frame refresh rate #6546

DorpsGek opened this issue Mar 17, 2017 · 11 comments
Labels
bug Something isn't working component: interface This is an interface issue flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) OS: MacOS This issue is related to a Mac OS problem patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay stale Stale issues

Comments

@DorpsGek
Copy link
Member

Ringding opened the ticket and wrote:

On macOS, fast forward does not run as fast as the CPU can do. It runs about twice the normal speed. This happens at least on El Capitan.

Following information unrelated to OpenTTD, specifically I'm not implying that I've run OpenTTD inside DOSBox -- http://www.vogons.org/viewtopic.php?f=32&t=46306:
I've had the same issue with DOSBox, and I found that it behaved like this when DOSBox was compiled on a contemporary macOS machine (I think Yosemite or later), but when I compiled it on Snow Leopard, the frame refresh restriction went away, even when running on El Capitan. I have not found out what caused this. Maybe someone can enlighten me.

Reported version: trunk
Operating system: Mac OS X


This issue was imported from FlySpray: https://bugs.openttd.org/task/6546
@DorpsGek
Copy link
Member Author

DorpsGek commented Sep 3, 2017

andythenorth wrote:

Is full-animation enabled here?

If so see #6469, which I suspect will at least mitigate this, or possibly eliminate it.


This comment was imported from FlySpray: https://bugs.openttd.org/task/6546#comment14748

@DorpsGek
Copy link
Member Author

DorpsGek commented Sep 3, 2017

Ringding wrote:

I can try, but I doubt it, as if this was the cause, the CPU usage would be much higher. It's showing ~30% in fast-forward vs. ~19% at normal speed.


This comment was imported from FlySpray: https://bugs.openttd.org/task/6546#comment14750

@DorpsGek
Copy link
Member Author

DorpsGek commented Sep 4, 2017

Ringding wrote:

As expected, it does not make a difference.


This comment was imported from FlySpray: https://bugs.openttd.org/task/6546#comment14757

@DorpsGek
Copy link
Member Author

DorpsGek commented Sep 5, 2017

andythenorth wrote:

Join IRC sometime if you want to investigate further https://wiki.openttd.org/Irc

Trading ticket comments is a non-fluid way to discuss the issue ;)


This comment was imported from FlySpray: https://bugs.openttd.org/task/6546#comment14758

@DorpsGek
Copy link
Member Author

Ringding wrote:

I've played around with this quite a bit, and for now I've accidentally found that setting [ this->cocoaview setWantsLayer:YES ] in wnd_quartz.mm is a cheap way to speed it up a good deal by pushing the frame rate up from 60 to 125.

Someone on the DOSbox forums hinted that this peculiar frame rate limiting behavior may already be a thing of the past on the Sierras. I'm still on El Capitan for now.


This comment was imported from FlySpray: https://bugs.openttd.org/task/6546#comment14783

@DorpsGek
Copy link
Member Author

Ringding wrote:

Basically, what I do now is this:

if (cur_time() - time_of_last_draw < 1/60.) continue;

right before the UpdateWindows() call in event.mm. And I record time_of_last_draw at the very end of OTTD_QuartzView:drawRect.

This works nicely, and it is also quite a bit faster than on Linux because the backbuffer does not needlessly get drawn hundreds of times each second. I just hope that the game state does not depend on anything done during UpdateWindows.


This comment was imported from FlySpray: https://bugs.openttd.org/task/6546#comment14788

@DorpsGek
Copy link
Member Author

andythenorth wrote:

Hi Stefan, got a patch / diff for that? I can test.

I'm on Sierra, speed of FFWD remains poor for both official OTTD binary and for local build.


This comment was imported from FlySpray: https://bugs.openttd.org/task/6546#comment14789

@DorpsGek
Copy link
Member Author

Ringding wrote:

This

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/6546#comment14790

@DorpsGek DorpsGek added component: interface This is an interface issue flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) bug labels Apr 7, 2018
@TrueBrain TrueBrain added the OS: MacOS This issue is related to a Mac OS problem label Apr 10, 2018
@andythenorth
Copy link
Contributor

andythenorth commented Apr 12, 2018

Test case

  • 512x512 map
  • no vehicles
  • 'full animation' on
  • viewport jammed in RH corner of map, showing only sea and black tiles

Time to run one game year on FFWD

  • 4m 55s: 1.8.0 official binary
  • 16s: patch above applied to OpenTTD master at 97c0594

I only ran the test once, watching a stopwatch for 4m 55s is boring :P

For completeness, locally compiled master without the patch runs around the same speed as 1.8.0 binary.

Mac OS 10.12.6 (Sierra)

@TrueBrain TrueBrain added patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay bug Something isn't working and removed bug from FlySpray labels Apr 12, 2018
@andythenorth
Copy link
Contributor

andythenorth commented Apr 12, 2018

Rubidium: technically what it does not drawing all the game ticks, so yeah... obviously it's faster... but if you use -v null it's even faster
[7:04pm] TrueBrain: ha; lol
[7:04pm] Rubidium: it doesn't really make the game itself faster
[7:04pm] TrueBrain: yeah, that is not the idea of Fast Forward
[7:04pm] TrueBrain: so comment that on GitHub please
Rubidium: so fast forwarding a pretty filled map won't get a big improvement

@andythenorth andythenorth added the stale Stale issues label Jan 5, 2019
@andythenorth
Copy link
Contributor

Thanks for this. There's been no activity on this for some time, and as it stands, it doesn't look likely that it will go any further. I'm closing it as we try to keep the issue count low for OpenTTD, it helps us focus on things that are important and fun. Feel free to discuss in irc or request re-opening if you disagree. Thanks for contributing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working component: interface This is an interface issue flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) OS: MacOS This issue is related to a Mac OS problem patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay stale Stale issues
Projects
None yet
Development

No branches or pull requests

3 participants