OpenTTD running at 60fps

[TrueBrain]

OMG! OMG! OMG! OMG! OMG! IT HAPPENED!

In the latest nightly (see https://www.openttd.org/downloads/opent ... atest.html ), you will notice a huge difference in how mouse, window, scrolling, etc behaves .. if you are in those kind of things. Well, I am pretty sure 90% of the people will notice, even more if you compare it side by side.

Buttttttt

The GUI of OpenTTD is finally running at 60fps by default! And you can change it to any value you like .. so if you have 144Hz screens like me, set it to refresh_rate to 144, and enjoy silky smooth map movement. One note .. it will cost you more CPU time, so Fast-Forward will be slower.

Talking about Fast-Forward ... check out how LIGHTNING fast it is now. And more improvements on the horizon .. owh, such good days.

How fast, you say?
Well, at 60fps, I can hit a simulation rate of 9999.99 frames/sec (on an empty map, I know, cheating). It turns out, I found the upper-limit of the Framerate Window ...

So how did we get here? What happened? Well, funny story ...

-----

While working on the SDL video driver, something was bugging me. I noticed that the drawing was tightly coupled to how fast we run the game .. meaning that on Fast-Forward it would be drawing the screen like a crazy person. I was like .. that sounds like a waste of good CPU time. Can't we split those two completely different tasks, and run them independent of each other? Turns out, yes, yes we can.
So, that solved a huge issue for me: I could now run the drawing on a normal 33.33fps, as the game did in 1.10, and have a Fast-Forward lightning-fast. That was what I set out to do, and it was awesome.

But a realization struck me .. if I can draw independent of the game-loop ... can I also not just render the game on a more normal 30fps? Yup. And owh, can I do it at 60fps? YES! OMG! THIS LOOKS SO MUCH BETTER AND SMOOTH AND OMG OMG!

So I was all happy ... turned out I could port this to all our video drivers ... and here we are: we can now all enjoy 60 fps UI, while the game still runs at a normal 33.33 fps. Sweet

Does it end here? Of course not! We already have in the works a window where you can control the Fast-Forward speed .. as it turns out that if 1 real-world second becomes 1 game-month, the current Fast-Foward button becomes .. less .. useful. So we will fix that soon too \o/

And what else? Well, michi_cc has made HUGE improvements to the OSX video driver .. and soon we hope to add OpenGL support for SDL (Linux) and Windows .. which is another huge improvements in drawing speed.

So what do I care?

Well, if you are like me, you are going to love the smoothness of 60fps.
But also, spending less time on drawing means your computer can handle bigger games easier.
And that is something we can all enjoy!

More trains more trains more trains .. and more NewGRFs of course

Why am I telling you this story? Well, sometimes you work on something else, and you find out that you can improve how the game plays for everyone everywhere .. just completely by accident. How insanely cool is that? I just had to share the happiness.


Owh, and andythenorth was forcing me to write this post. That also might have something to do with it. Make sure to give him a hug when you see him

[Andrew350]

So just for fun I tried building a small truck route on fast-forward and taking a picture as quickly as I could. It was only about ~25 tiles long, but even so I went bankrupt from loan interest before I could finish
This was the result:

Fradwood Transport, 2047-08-13.png

(185.2 KiB) Not downloaded yet

^^That was starting in 1950. It was the most intense 30s of OpenTTD gameplay I've ever experienced Good fun.

Seriously though it's an amazing improvement, a little weird to get used to the smooth map scrolling, but in a good way Only thing is it seems like my mouse cursor is still trundling along at 30fps unless I'm on fast forward, which just looks worse now that everything else is so buttery smooth. Not sure if there's something else besides setting the refresh rate to get that working better? I tried tweaking some settings but no effect. I'm on Windows.

Great work though

[TrueBrain]

So just for fun I tried building a small truck route on fast-forward and taking a picture as quickly as I could. It was only about ~25 tiles long, but even so I went bankrupt from loan interest before I could finish
This was the result:

Fradwood Transport, 2047-08-13.png

^^That was starting in 1950. It was the most intense 30s of OpenTTD gameplay I've ever experienced Good fun.

Seriously though it's an amazing improvement, a little weird to get used to the smooth map scrolling, but in a good way Only thing is it seems like my mouse cursor is still trundling along at 30fps unless I'm on fast forward, which just looks worse now that everything else is so buttery smooth. Not sure if there's something else besides setting the refresh rate to get that working better? I tried tweaking some settings but no effect. I'm on Windows.

Great work though

Hahaha, that is amazing That really sounds like fun to try

Mouse really should also run on 60fps now, weird that it lags behind .. I will check out what is going on with the windows driver!

[TrueBrain]

(..) Only thing is it seems like my mouse cursor is still trundling along at 30fps unless I'm on fast forward, (..)

Found the problem, and fix is pending Hopefully the next nightly will contain this Thank you for testing and finding this so quickly .. would have been embarrassing if that hit the official release

[Andrew350]

(..) Only thing is it seems like my mouse cursor is still trundling along at 30fps unless I'm on fast forward, (..)

Found the problem, and fix is pending Hopefully the next nightly will contain this Thank you for testing and finding this so quickly .. would have been embarrassing if that hit the official release

Awesome, thanks for a quick response It looks great in fullscreen mode now, but the sluggishness/flickering is still there in windowed mode. Is there anything that could be done there, or is that an unavoidable effect of running the game that way?

Thanks again

[TrueBrain]

(..)
Awesome, thanks for a quick response It looks great in fullscreen mode now, but the sluggishness/flickering is still there in windowed mode. Is there anything that could be done there, or is that an unavoidable effect of running the game that way?

Thanks again

Soon (tm), I hope It is most likely because drawing is not done during vsync, which gives a weird tearing effect. This has been there for years btw, but I hope soon we can finally solve that Stay tuned

[Juanjo]

That is a huge improvement and it needed a post in the forums indeed.

I have a question about the refresh_rate.

Now the user "chooses" which refresh_rate to use. But is it possible to set it to "automatic"?

I mean that if the refresh_rate is set to "automatic", then it is obtained from the system. So, if OpenTTD runs in a screen at 100 Hz, then the refresh rate is 100; and if it is run later in a screen at 30 Hz, the refresh rate is set to 30, without having to change the configuration at all.

[TrueBrain]

That is a huge improvement and it needed a post in the forums indeed.

I have a question about the refresh_rate.

Now the user "chooses" which refresh_rate to use. But is it possible to set it to "automatic"?

I mean that if the refresh_rate is set to "automatic", then it is obtained from the system. So, if OpenTTD runs in a screen at 100 Hz, then the refresh rate is 100; and if it is run later in a screen at 30 Hz, the refresh rate is set to 30, without having to change the configuration at all.

Possible? Ish .. and difficult. We might extend that in the future, but for now I don't have plans for that.

It is a likely assumption that monitors for systems running OpenTTD are at least 60Hz. So having that as fixed default, for now, will cover most people. This means not autodetecting is mainly annoying for people who have better than 60Hz screens. And I know that pain, as I have those But there are 2 reasons not to make higher a default for now:

1) currently, if I run the game on a refresh_rate of 144 and I try to play a large game, the time it takes the draw the screen eats away from the time available to do the simulation, meaning it easily slips under 1x simulation speed. This is not ideal. So first we would need some pressure system that favours keeping the simulation at 1x over drawing at 144fps. Or make it possible for the user to indicate which he prefers .. this has to be worked out This is already an issue at 60fps btw, but anything higher and the problem only becomes worse
2) auto-detecting Hz is crazy annoying and difficult, especially cross-platform. This is because Hz is per display, and it is not uncommon anymore that people have more than 1 display. So we need to figure out what we want to do with people dragging their window to the other screen, how to detect changes, etc etc. It is a lot of work. Doable, but it would need someone to sit down for it and figure it all out.

So, for now, I went for the: lets enjoy something new first, lets improve on it later Iterate, and baby steps

But, if anyone feels up for it adding refresh-rate detection, I am all in favour! We accept Pull Requests (and would love it if someone gives it a spin!)

[Juanjo]

Possible? Ish .. and difficult. We might extend that in the future, but for now I don't have plans for that.

Great. I fully agree with you. The automatic detection would just be the cherry on top of the cake, and probably not worth the effort.
Sorry, I don't have time (or the skills ) for looking into it.

[Toffo]

Amazing work, thank you!

[LaChupacabra]

This is powerful, epoch-making, just shocking!
How dare You allow the thought of not sharing this news that even Andy had to persuade you to do so!?

For starters, I created some new game with several AIs...
I put a few buses on the line, than I pressed >> and...
... I didn't know where I was and what was going on.

Yes, you gave a really nice turbo to this engine.

Then I launched an old test save with long (14.8 ) trains of the PKP set, where each locomotive and each car consists of two elements. Here the speed has increased by almost x5. Awesome!

Before and after the change

Game speed with 600x15 trains (PKP set).png (52.03 KiB) Viewed 589 times

Test wydajności 600x15 (PKP), 23 lip 2022.sav

(413.64 KiB) Downloaded 12 times

List of the latest development version of OTTD - check yourself the differences

Now I'm doing tests with other different conditions and the results are going to be quite surprising...

[LaChupacabra]

So...
I checked what it would look like with the most demanding and processor-intensive Timberwolf's UK Trains set, where each, even the smallest, car consists of three elements.
There also ran 600 trains with a length of 14.9 along the same route. In version 1.10.3 the game was extremely slow: ~ 0.26x. In the latest development version of 20210220-master it was ~ 0.58x. So here the speed has also increased significantly, but not that much.

Before and after the change

Game speed with 600x15 trains (Timberwolf's UK Trains).png (61.15 KiB) Viewed 569 times

Speed Test 600x15(Timbertrains), 2031-09-12.sav

(881.89 KiB) Downloaded 10 times

[LaChupacabra]

Then I checked the differences with the saved game from the reddit Vanilla server with standard vehicles.
And here, surprisingly, the speed of the accelerated game slightly decreased compared to the current version of the game.

Before and after the change

Game speed reddit vanilla server (default vehicles).png (52.7 KiB) Viewed 567 times

Ebola Transport, 2020-06-14.sav

(3.14 MiB) Downloaded 7 times

[TrueBrain]

(..)

Yes, you gave a really nice turbo to this engine.

(..)

Tnx

Then I checked the differences with the saved game from the reddit Vanilla server with standard vehicles.
(..)

Interesting regression. I am going to check out what is going on here I jumped to an early conclusion, but that seems wrong .. so I need to take some time to understand what is happening .. tnx for the savegame

[jfs]

This is powerful, epoch-making, just shocking!
How dare You allow the thought of not sharing this news that even Andy had to persuade you to do so!?

For starters, I created some new game with several AIs...
I put a few buses on the line, than I pressed >> and...
... I didn't know where I was and what was going on.

Yes, you gave a really nice turbo to this engine.

Then I launched an old test save with long (14.8 ) trains of the PKP set, where each locomotive and each car consists of two elements. Here the speed has increased by almost x5. Awesome!

I'm not sure what's happening here, because the improvements talked about in this thread are about how often the game draws the screen and how often it accepts input.
The things you show in your screenshot is that the simulation is more performant, that's something entirely different.

To be clear: The speed improvement you display in some of these examples should not be the result of the changes discussed in this thread.

[TrueBrain]

(..)
Interesting regression. I am going to check out what is going on here I jumped to an early conclusion, but that seems wrong .. so I need to take some time to understand what is happening .. tnx for the savegame

JGR helped me out: a big change in 1.11 is that sprites are cached for the viewport. This is most likely why you see such a huge improvements in the other two games. I would like to take credit, but that really is not my work You can thank Timberwolf for that

The last savegame, is most likely because our nightlies are compiled with "assertions" on. They indicate sooner when things are about to break, but they take some CPU time. So for that game, we would have to make a release-build and see what the speed does against 1.10.3. I will check that out this week, just to be sure. But I have a suspicion that with release, it will be equally if not faster

(..)

I'm not sure what's happening here, because the improvements talked about in this thread are about how often the game draws the screen and how often it accepts input.
The things you show in your screenshot is that the simulation is more performant, that's something entirely different.

To be clear: The speed improvement you display in some of these examples should not be the result of the changes discussed in this thread.

I do not expect a user to be able to differentiate what causes his game to run faster, so I think it is fair he assumed it was because of the 60fps. But it turns out we did more great things in the meantime

[LaChupacabra]

I reasoned faster game performance from what you wrote...

But also, spending less time on drawing means your computer can handle bigger games easier.
And that is something we can all enjoy!
More trains more trains more trains .. and more NewGRFs of course

And from new feature which allow to change game speed (it's a great, very useful solution, I think it's can be better than my zipper mockup.)
The first tests showed that the progress is really big.

Either way, thanks for all the work you do. (almost all*, you know)
Don't be angry, but the title of the epochal change in this case will probably have to go for someone else.
Thanks Timberwolf! These three-piece wagons scared me a bit, but now I see that you knew what you were doing.

[Timberwolf]

If I knew what I was doing, I'd have a nice graphical scheme for drawing large volumes of UK-styled vehicles at 8/8 length like Pikka and Andy have! (Disclaimer: other sets are available, those are the ones I'm most familiar with).

It was only after spotting that multiplayer games struggled once a few players had 100 or so trains each that I started looking for a speedup, and in fact the original idea for only re-resolving sprites on a direction change came from JGR; our solutions diverge a bit (mine is based more on "will this be part of a viewport" whereas JGR's approach is "has anything happened to cause this vehicle's sprite to change?") but without the speedup that was in JGR I wouldn't have known where to start. And of course the dev team who helped with my extremely rusty and out-of-date C++ knowledge through a lot of pull request conversations .