Bay 12 Games Forum
Dwarf Fortress => DF Suggestions => Topic started by: bool1989 on January 09, 2023, 11:38:56 am
-
Hey, we're all thinking it, I just feel someone has to say it.
Ever since the release of ArchCrystal, Hundred year old forts have become the ideal, but FPS death is a major obstacle in front of it.
Even the guy who made ArchCrystal have to restrict his population to 35 just to keep the fps issues under control.
Now that Putnam is working on the project, I hope that he can somehow bring the FPS issue under control, as it's the one major outstanding issue affecting Dwarf Fortress.
-
Not sure what exactly you are suggesting.. but you should manage your expectations, late game lag is an issue in virtually all management games, with the more simulation elements there are the worse the problem is. The only people who never experienced that are those who play boring games.
-
A lot of the FPS problems comes down to the excessive individualism of the game. A lot of things are done individually that really should be done as blocks, grouping together similar dwarves with similar goals. So in other words, rather than individual dwarves going to bed, eating, working and so on, we have the whole household do these tasks simultaneously, so we do not have to individually calculate the paths for each dwarf.
-
A lot of the FPS problems comes down to the excessive individualism of the game. A lot of things are done individually that really should be done as blocks, grouping together similar dwarves with similar goals. So in other words, rather than individual dwarves going to bed, eating, working and so on, we have the whole household do these tasks simultaneously, so we do not have to individually calculate the paths for each dwarf.
There was a recent post that said that Pathfinding isn't a significant part of FPS loss.
Read it here: http://www.bay12forums.com/smf/index.php?topic=180561.0
-
A lot of the FPS problems comes down to the excessive individualism of the game. A lot of things are done individually that really should be done as blocks, grouping together similar dwarves with similar goals. So in other words, rather than individual dwarves going to bed, eating, working and so on, we have the whole household do these tasks simultaneously, so we do not have to individually calculate the paths for each dwarf.
There was a recent post that said that Pathfinding isn't a significant part of FPS loss.
Read it here: http://www.bay12forums.com/smf/index.php?topic=180561.0
Because there are only a few hundred dwarves perhaps?
-
A lot of the FPS problems comes down to the excessive individualism of the game. A lot of things are done individually that really should be done as blocks, grouping together similar dwarves with similar goals. So in other words, rather than individual dwarves going to bed, eating, working and so on, we have the whole household do these tasks simultaneously, so we do not have to individually calculate the paths for each dwarf.
There was a recent post that said that Pathfinding isn't a significant part of FPS loss.
Read it here: http://www.bay12forums.com/smf/index.php?topic=180561.0
Because there are only a few hundred dwarves perhaps?
No, because context checking (i.e. checking stuff for if it's in line of sight and reacting to it if it is) starts laggier than pathfinding and grows laggier faster than pathfinding does, so pathfinding is never relevant and actually becomes less relevant as more dwarves happen. The "FPS death" in the sense of "inevitable slowdown of a fortress" has absolutely nothing to do with pathfinding.
-
A lot of the FPS problems comes down to the excessive individualism of the game. A lot of things are done individually that really should be done as blocks, grouping together similar dwarves with similar goals. So in other words, rather than individual dwarves going to bed, eating, working and so on, we have the whole household do these tasks simultaneously, so we do not have to individually calculate the paths for each dwarf.
There was a recent post that said that Pathfinding isn't a significant part of FPS loss.
Read it here: http://www.bay12forums.com/smf/index.php?topic=180561.0
Because there are only a few hundred dwarves perhaps?
No, because context checking (i.e. checking stuff for if it's in line of sight and reacting to it if it is) starts laggier than pathfinding and grows laggier faster than pathfinding does, so pathfinding is never relevant and actually becomes less relevant as more dwarves happen. The "FPS death" in the sense of "inevitable slowdown of a fortress" has absolutely nothing to do with pathfinding.
Thanks for clarifying that Putnam. Congratz on the new job. I do hope the legacy code isn't giving you headaches.
-
No, because context checking (i.e. checking stuff for if it's in line of sight and reacting to it if it is) starts laggier than pathfinding and grows laggier faster than pathfinding does, so pathfinding is never relevant and actually becomes less relevant as more dwarves happen. The "FPS death" in the sense of "inevitable slowdown of a fortress" has absolutely nothing to do with pathfinding.
Actually it's about 6% according to you. Context checking is however what most people would consider part of pathfinding even if technically it isn't.
-
A lot of the FPS problems comes down to the excessive individualism of the game. A lot of things are done individually that really should be done as blocks, grouping together similar dwarves with similar goals. So in other words, rather than individual dwarves going to bed, eating, working and so on, we have the whole household do these tasks simultaneously, so we do not have to individually calculate the paths for each dwarf.
There was a recent post that said that Pathfinding isn't a significant part of FPS loss.
Read it here: http://www.bay12forums.com/smf/index.php?topic=180561.0
Because there are only a few hundred dwarves perhaps?
No, because context checking (i.e. checking stuff for if it's in line of sight and reacting to it if it is) starts laggier than pathfinding and grows laggier faster than pathfinding does, so pathfinding is never relevant and actually becomes less relevant as more dwarves happen. The "FPS death" in the sense of "inevitable slowdown of a fortress" has absolutely nothing to do with pathfinding.
Just jumping in here, but could a way for the player to mitigate this be moving things into different rooms and cutting off line of sight to the dwarfs? for example : splitting stockpiles further than like 1 big stockpiles with everything in it, since the dwarfs would have less stuff they'll be able to see?
Could a way to mitigate this be to pre-calculate reactions for things dwarf see often, like a statue, a dwarf's reaction could be stored for next time they see the statue instead of recalculating the reaction again?
-
A lot of the FPS problems comes down to the excessive individualism of the game. A lot of things are done individually that really should be done as blocks, grouping together similar dwarves with similar goals. So in other words, rather than individual dwarves going to bed, eating, working and so on, we have the whole household do these tasks simultaneously, so we do not have to individually calculate the paths for each dwarf.
There was a recent post that said that Pathfinding isn't a significant part of FPS loss.
Read it here: http://www.bay12forums.com/smf/index.php?topic=180561.0
Because there are only a few hundred dwarves perhaps?
No, because context checking (i.e. checking stuff for if it's in line of sight and reacting to it if it is) starts laggier than pathfinding and grows laggier faster than pathfinding does, so pathfinding is never relevant and actually becomes less relevant as more dwarves happen. The "FPS death" in the sense of "inevitable slowdown of a fortress" has absolutely nothing to do with pathfinding.
Just jumping in here, but could a way for the player to mitigate this be moving things into different rooms and cutting off line of sight to the dwarfs? for example : splitting stockpiles further than like 1 big stockpiles with everything in it, since the dwarfs would have less stuff they'll be able to see?
Could a way to mitigate this be to pre-calculate reactions for things dwarf see often, like a statue, a dwarf's reaction could be stored for next time they see the statue instead of recalculating the reaction again?
The problem isn't what they do with individual items, it's the fact that they have to check everything. This has actually been mitigated a good deal in 50.05 due to the fact that it's not checking if it needs to skip certain units anymore (removing branches is one of the best optimizations you can do), but it's still the big issue.
-
The problem isn't what they do with individual items, it's the fact that they have to check everything. This has actually been mitigated a good deal in 50.05 due to the fact that it's not checking if it needs to skip certain units anymore (removing branches is one of the best optimizations you can do), but it's still the big issue.
Why does it need to check everything? Do we not only need to check for the items that creatures are going to interact with?
-
The problem isn't what they do with individual items, it's the fact that they have to check everything. This has actually been mitigated a good deal in 50.05 due to the fact that it's not checking if it needs to skip certain units anymore (removing branches is one of the best optimizations you can do), but it's still the big issue.
Why does it need to check everything? Do we not only need to check for the items that creatures are going to interact with?
1. It's checking for other creatures that causes the most issue, not items, which I'm not even sure are taken into account (certainly if they are it doesn't show up in profiling, so it's irrelevant performance-wise)
2. You have to check whether the creatures can interact with it in the first place, which is (usually) the primary operation being done. Most of the slowdown before 50.05 was in skipping over units that are dead/caged/ghosts, as of 50.05 most of the slowdown is now in skipping over units which are too far away to possibly be interacted with.
-
Whats the chance we could get some sort of ingame (or hell, even DFHack) readout which shows what functions are causing the most slowdown? an ingame profiler if you will.
-
1. It's checking for other creatures that causes the most issue, not items, which I'm not even sure are taken into account (certainly if they are it doesn't show up in profiling, so it's irrelevant performance-wise)
2. You have to check whether the creatures can interact with it in the first place, which is (usually) the primary operation being done. Most of the slowdown before 50.05 was in skipping over units that are dead/caged/ghosts, as of 50.05 most of the slowdown is now in skipping over units which are too far away to possibly be interacted with.
Can we not divide the play area into invisible shapes, with overlapping shapes on their borders? As long as the shapes are bigger than how far creatures can see, can we not then reduce the number of checks needed by only going through a list of creatures in the shape?
-
Can we not divide the play area into invisible shapes, with overlapping shapes on their borders? As long as the shapes are bigger than how far creatures can see, can we not then reduce the number of checks needed by only going through a list of creatures in the shape?
That's more complicated and memory intensive than just finding the (square) distance between two points, even at O(N2). You've got to update those regions each time a unit moves. Add the overhead of finding and removing the unit from the proper vector once you've determined a unit has left the region.
-
Can we not divide the play area into invisible shapes, with overlapping shapes on their borders? As long as the shapes are bigger than how far creatures can see, can we not then reduce the number of checks needed by only going through a list of creatures in the shape?
That's more complicated and memory intensive than just finding the (square) distance between two points, even at O(N2). You've got to update those regions each time a unit moves. Add the overhead of finding and removing the unit from the proper vector once you've determined a unit has left the region.
A more comprehensive region system would have other benefits though tbf