CleverRaven / Cataclysm-DDA

Cataclysm - Dark Days Ahead. A turn-based survival game set in a post-apocalyptic world.
http://cataclysmdda.org
Other
10.1k stars 4.11k forks source link

#74169 cause to fps freeze while game generate new map tiles #75166

Open KHeket opened 1 month ago

KHeket commented 1 month ago

Describe the bug

After playing latest experemental - I noticed freezes of a game for 0.5-1 second when I am traveling by legs or car, what is very noticeable for me And I found, that before https://github.com/CleverRaven/Cataclysm-DDA/releases/tag/cdda-experimental-2024-06-19-1857 there is no such freezes pf game But after the #74169 pr was merged - there is became a freeze of a game after a few seconds And also I noticed, that it happened at unexplored tiles. You can start the game, go somewhere and see freeze for 0.5-1 second every ~ 15 seconds, but if you go back by the same way - you dont see such freezes, as I can understand, because game dont need to waste game time to generate new territory The same performance issue I have and at a latest experimental https://github.com/CleverRaven/Cataclysm-DDA/releases/tag/cdda-experimental-2024-07-22-0629

Attach save file

N/A

Steps to reproduce

Download version before changes, for example https://github.com/CleverRaven/Cataclysm-DDA/releases/tag/cdda-experimental-2024-06-19-1635 Spawn a character in new world Go somewhere and se no performance freezes

Download https://github.com/CleverRaven/Cataclysm-DDA/releases/tag/cdda-experimental-2024-06-19-1857 or later version, make the same steps and see, that when map is generating - there will be short but noticeable freeze every time you going furture to no explored locations

Expected behavior

Dont have game freeze

Screenshots

No response

Versions and configuration

Additional context

No response

KHeket commented 1 month ago

@PatrikLundell can you check pls?

PatrikLundell commented 1 month ago

I see sub second delays occasionally as I keep a direction key pressed, but they're too short for me to see if there is a regular pattern to them (stepping one tile at a time doesn't delay things enough for me to notice, as it's only visible in a direction press movement stutter). If it's terrain generation it should be every 12 or 24 steps (the map is generated one overmap at a time, i.e. every 24 tiles, but the reality bubble only loads the first half of it and loads the second half 12 tiles later (but without generating it: it was generated the first time, so it only has to be loaded). I cannot say if these small stutters are more common or worse than in the past.

Unfortunately, I don't think I can do much at this stage, as I don't know how to do performance profile measurements, which is what would be needed to figure out where the problem lies. If the changes work as intended, the amount of work performed should be essentially the same as before, just being shuffled around (instead of generating 21 tinymaps one at a time a 21 level smallmap is generated once and then iterated over one level at a time to add the contents).

KHeket commented 1 month ago

I cannot say if these small stutters are more common or worse than in the past.

I can attach videos of noticeable freezes if it needed

I don't know how to do performance profile measurements, which is what would be needed to figure out where the problem lies.

As I know, few peoples can do this, @ZhilkinSerg or @akrieger as far as I know are good in this. Can you help pls guys?

PatrikLundell commented 1 month ago

I made a very primitive attempt to use what I found under the Debug menu: Test scenario: Start Performance Profiles set to CPU and start with recording disabled. Teleport to field location directly adjacent to unrevealed terrain (to ensure it will definitely have to be generated). Start recording and walk in a straight line into the unknown by keeping the direction key pressed. Stop recording after a while when running into fungaloids. Results:

My conclusion from the above is that the lookup_submap operation is unexpectedly expensive, so it might be useful to look at ways to reduce its usage. It looks like it might be possible to cache the info about whether submaps are present in the MAPBUFFER at the initial read and use that cached info rather than reading it again later, for a saving of about 5%. Also, the amount of time spent on map_buffer::unserialize_submaps indicates a fair bit of time might be spent reading files rather than running the CPU.