Performance issues on large maps
Moderator: OpenTTD Developers
-
- Engineer
- Posts: 23
- Joined: 20 Jul 2022 13:52
Performance issues on large maps
So I am playing on large maps 2048x4096 or 4096x4096.
I have some cities over 400k citizens.
When I try to zoom out and move without the game pausing I am getting stutters.
Do I need to invest in better hardware or there is nothing I can't do?
My specs:
i5-4460
rx570
Thanks for the help,
Cheers,
P.S.
Will putting this game on ssd help in any way ?
I have some cities over 400k citizens.
When I try to zoom out and move without the game pausing I am getting stutters.
Do I need to invest in better hardware or there is nothing I can't do?
My specs:
i5-4460
rx570
Thanks for the help,
Cheers,
P.S.
Will putting this game on ssd help in any way ?
Re: Performance issues on large maps
You can try a faster processor, but it may make very little difference. Most of the game only runs on a single core (some processes have been updated to run on multiple cores), it doesn't touch your graphics card at all. Running at game at 2048x2048 or beyond is pushing the limits of a clone of a game designed for PC hardware 30 years ago.
Do you like drones, quadcopters & flying toys? Check out Drone Strike Force!
Base Music Sets: OpenMSX | Scott Joplin Anthology | Traditional Winter Holiday Music | Modern Motion Music
Other Projects: 2CC Trams | Modern Waypoints | Sprite Sandbox & NewGRF Releases | Ideabox | Town Names | Isle of Sodor Scenario | Random Sprite Repository
Misc Topics: My Screenshots | Forgotten NewGRFs | Unfinished Graphics Sets | Stats Shack | GarryG's Auz Sets
Base Music Sets: OpenMSX | Scott Joplin Anthology | Traditional Winter Holiday Music | Modern Motion Music
Other Projects: 2CC Trams | Modern Waypoints | Sprite Sandbox & NewGRF Releases | Ideabox | Town Names | Isle of Sodor Scenario | Random Sprite Repository
Misc Topics: My Screenshots | Forgotten NewGRFs | Unfinished Graphics Sets | Stats Shack | GarryG's Auz Sets
Re: Performance issues on large maps
the short answer is: no, throwing more hardware at it probably doesn't solve anything.
much of the game performance is determined by a single thread, and single thread perforance hasn't increased as fast in the past 10 years (although there still were some improvements, it hasn't quite kept up with moore's law)
there's generally two things that need performance:
the first thing is influenced mainly by map size and the amount of vehicles travelling, plus each piece of cargo. with the exception of modern additions like cargo distribution, most of this was designed to run in a single thread, because everything depends on each other (like waiting at signals, collisions and stuff) and untangling that into several threads and then recombining it at the end is complicated, and probably creating more overhead than it speeds up things.
the second thing is influenced by how much is visible at once. here the main problem is that modern graphics cards are designed to handle 3D objects, which get smaller and less detailed the further away you go. what they aren't designed for is handling isometric worlds where everything has the same level of detail no matter how far it is away, plus old gimmicks like 8bit palette, animated colours, etc. which got left out of modern graphics cards because no modern game uses these tricks. when you zoom in, everything visible on the screen has 1 sprite to draw, which gets thrown into a pool, which needs to get sorted back-to-front for drawing. when you zoom out, still everything has 1 (now slightly smaller) sprite to draw, which still gets thrown into a (now much bigger) pool that needs to be sorted. due to the low demand, i don't think anyone has ever researched how to do this efficiently with multiple threads
now, for the scenario drawn here: scrolling zoomed-out world with unpaused game, these two things collide with each other head on.
if you zoom out while paused, and then scroll around, the part of the map that was visible before gets moved around the screen, and only the parts that became newly visited actually have to be redrawn. but when the game is unpaused, and things move around, also those areas have to be redrawn (on a busy world, this is probably the whole screen)
so the drawing has to wait for the game simulation to finish, the simulation has to wait while drawing is happening. either of these things on its own are likely to bring a modern system to the edge of performance limits, so combining them creates a perfect storm.
conclusion: just pause when you zoom out.
much of the game performance is determined by a single thread, and single thread perforance hasn't increased as fast in the past 10 years (although there still were some improvements, it hasn't quite kept up with moore's law)
there's generally two things that need performance:
- calculating what is happening in the world
- getting everything drawn on the screen
the first thing is influenced mainly by map size and the amount of vehicles travelling, plus each piece of cargo. with the exception of modern additions like cargo distribution, most of this was designed to run in a single thread, because everything depends on each other (like waiting at signals, collisions and stuff) and untangling that into several threads and then recombining it at the end is complicated, and probably creating more overhead than it speeds up things.
the second thing is influenced by how much is visible at once. here the main problem is that modern graphics cards are designed to handle 3D objects, which get smaller and less detailed the further away you go. what they aren't designed for is handling isometric worlds where everything has the same level of detail no matter how far it is away, plus old gimmicks like 8bit palette, animated colours, etc. which got left out of modern graphics cards because no modern game uses these tricks. when you zoom in, everything visible on the screen has 1 sprite to draw, which gets thrown into a pool, which needs to get sorted back-to-front for drawing. when you zoom out, still everything has 1 (now slightly smaller) sprite to draw, which still gets thrown into a (now much bigger) pool that needs to be sorted. due to the low demand, i don't think anyone has ever researched how to do this efficiently with multiple threads
now, for the scenario drawn here: scrolling zoomed-out world with unpaused game, these two things collide with each other head on.
if you zoom out while paused, and then scroll around, the part of the map that was visible before gets moved around the screen, and only the parts that became newly visited actually have to be redrawn. but when the game is unpaused, and things move around, also those areas have to be redrawn (on a busy world, this is probably the whole screen)
so the drawing has to wait for the game simulation to finish, the simulation has to wait while drawing is happening. either of these things on its own are likely to bring a modern system to the edge of performance limits, so combining them creates a perfect storm.
conclusion: just pause when you zoom out.
-
- Engineer
- Posts: 23
- Joined: 20 Jul 2022 13:52
Re: Performance issues on large maps
How about an ssd? It usually helps today's games.kamnet wrote: ↑31 Dec 2022 05:08 You can try a faster processor, but it may make very little difference. Most of the game only runs on a single core (some processes have been updated to run on multiple cores), it doesn't touch your graphics card at all. Running at game at 2048x2048 or beyond is pushing the limits of a clone of a game designed for PC hardware 30 years ago.
Re: Performance issues on large maps
Given that it sounds like the bottleneck is the CPU, there's likely no gameplay advantage in using an SSD - it'll make loading and saving faster, but that's probably about the limit.GrandSeverus wrote: ↑31 Dec 2022 11:15How about an ssd? It usually helps today's games.kamnet wrote: ↑31 Dec 2022 05:08 You can try a faster processor, but it may make very little difference. Most of the game only runs on a single core (some processes have been updated to run on multiple cores), it doesn't touch your graphics card at all. Running at game at 2048x2048 or beyond is pushing the limits of a clone of a game designed for PC hardware 30 years ago.
- Redirect Left
- Tycoon
- Posts: 7240
- Joined: 22 Jan 2005 19:31
- Location: Wakefield, West Yorkshire
Re: Performance issues on large maps
Disk access speeds aren't an issue for OpenTTD, or at least there's no difference I notice between using an old 5400RPM HDD (probably tops at about 60 to 80MB/s) with my current NVMe SSD with > 5000MB/s read speed when it comes to OpenTTD.GrandSeverus wrote: ↑31 Dec 2022 11:15How about an ssd? It usually helps today's games.kamnet wrote: ↑31 Dec 2022 05:08 You can try a faster processor, but it may make very little difference. Most of the game only runs on a single core (some processes have been updated to run on multiple cores), it doesn't touch your graphics card at all. Running at game at 2048x2048 or beyond is pushing the limits of a clone of a game designed for PC hardware 30 years ago.
I use an i9-12900k and OpenTTD does become noticeably slower at times for me too. I have over 5000 trains on a 2048x2048 map, it's not quite enough to slow it down beyond normal 1x speed, but the fast forward button now does... basically nothing.
Re: Performance issues on large maps
Not sure how relevant this is these days but If you're also using a lot of add-on graphics sets, you might be hitting the default sprite cache limit, in which case the LRU cache hits nearly every frame which is a massive slowdown.
Look for `sprite_cache_size_px` in openttd.cfg and try doubling it or so. Default appears to be 128.
Look for `sprite_cache_size_px` in openttd.cfg and try doubling it or so. Default appears to be 128.
He's like, some kind of OpenTTD developer.
Who is online
Users browsing this forum: No registered users and 3 guests