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

Very long loading of the maximum "zoom out" level in 4K resolution #6566

Closed
DorpsGek opened this issue May 27, 2017 · 9 comments

Comments

@DorpsGek
Copy link

commented May 27, 2017

Qwest8K opened the ticket and wrote:

I run OpenTTD (x64 version r27875, Windows 7 SP1) in 4K resolution (3840x2160). When i try choose maximum level of "zoom out", I get freeze of game. But forty seconds later game unfreeze with highest level of "zoom out". I immediatly did "zoom in" and again try opened largest view of area. Game freeze again, but successfully unfreeze twenty seconds later. I again did "zoom in" and maximum of "zoom out". It opened twenty seconds later. Again.

So, when game work in 4K (in FullHD all normal), it loading highest "zoom out" level with some time period. While switching between all the others levels of zoom in any direction (out-in, in-out) always instantaneous.

Also, loading of highest view depend on the size of map. Forty-twenty seconds - on 256x256 size. On 4096x4096 loading takes minutes.

Reported version: trunk
Operating system: Windows


This issue was imported from FlySpray: https://bugs.openttd.org/task/6566
@DorpsGek

This comment has been minimized.

Copy link
Author

commented Jan 17, 2018

danielarmstrong wrote:

This bug is still in the latest version and it also happens on a windows 10 machine with an 2560 by 1440 monitor with super high specs.


This comment was imported from FlySpray: https://bugs.openttd.org/task/6566#comment14833
@TrueBrain

This comment has been minimized.

Copy link
Member

commented Apr 11, 2018

I am not sure whether this is a bug, or works-as-intended. But we need to look into this to be sure :)

@Qwest8K

This comment has been minimized.

Copy link

commented Apr 13, 2018

As author of this report, I start to wait.

@TrueBrain TrueBrain added bug and removed bug from FlySpray labels Apr 13, 2018
@planetmaker

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2018

Sounds to me like an issue with the size of the visible map area.

Is the delay the same for different kind of maps, e.g. comparing a very busy one with many towns and vehicles (trains, road vehicles,...) and a "idylic" one with few villages and mostly country side?

My suspicion is: there's so many sprites to order, that it simply takes a load of time - longer than desirable.

@nielsmh

This comment has been minimized.

Copy link
Contributor

commented Nov 1, 2018

I think this is fixed/improved with #6911.

@nielsmh nielsmh closed this Nov 1, 2018
@lediur

This comment has been minimized.

Copy link

commented Oct 9, 2019

I don't think this is fixed - when zooming out to the maximum zoom level OpenTTD still freezes for 3-5 seconds for me. Running latest JGRPP 0.32-rc5.

@LordAro

This comment has been minimized.

Copy link
Member

commented Oct 9, 2019

I would venture a guess that 3-5s is entirely expected - and a lot better than the originally reported 20-30s. 4k is a lot, and OTTD doesn't have any sort of GPU acceleration.

Please try with standard "vanilla" OTTD and give more information (map size, computer specs)

@lediur

This comment has been minimized.

Copy link

commented Oct 9, 2019

Yeah it's definitely improved performance over the original report, but it's also still noticeable. With vanilla 1.9.2, it takes slightly longer ~5-7 seconds than JGRPP on an older version of the same map.

I've kinda worked around it in JGRPP by making sure to be in transparency mode (with invisible trees), which makes sense given the sprite rendering explanation from above.

Map size is 1024x1024, with lots of trees and towns e.g.
image. I think the trees are the render time killer since it takes <1s to render the largest zoom level with invisible trees, which is within the "tolerable to gameplay UI latency perception" threshold for me.

Specs:
Intel Core i7 4770K at 4.2 GHz
NVIDIA GeForce GTX 1080

Edit: after playing around with the transparency options, toggling building invisibility has a good <300ms latency, whereas toggling tree invisibility takes several seconds.

@LordAro

This comment has been minimized.

Copy link
Member

commented Oct 9, 2019

I mean, there are a lot more trees than buildings... but it's possible (probable) there's some inefficiency somewhere that could be looked at

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.