Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Putnam]

I don't need a giant list of dead/missing that keep on growing

I actually have the code for that implemented, with an in-game setting allowing you to adjust how many units are there before they start being culled, so that's good

[IronGremlin]

And it really doesn't help that the things the dwarves love, like mist, are FPS hogs.

Yeah I'd be really curious to know specifically about plans to improve FPS around fluid contraptions or the mandatory 50 FPS drop that happens when you open the magma sea.


At this point I can easily run the game for decades at max pop and get no noticable slowdown, but those two things will always brutalize my framerate.

[Thorfinn]

Never noticed the magma sea, but that may be because I beeline magma workshops and turn down the game speed once I hit magma to get everything set up. Cracking open the caverns, yeah, I notice that because I don't slow the game for that, just install a hatch and move the stairwell to wherever I can get around the caverns.

Probably same deal, right? Until you crack the magma, it doesn't spawn fire snakes and so forth? Guess that makes sense. Probably I'm blaming too much of the slowdown on cavern spores filling every open dirt instead of whatever is happening in the sea.

[IronGremlin]

The thing with the magma sea though is that the slowdown is always immediate - it's always like a sudden pop as soon as I breach it. I have frequently had the experience of being pinned at 100 FPS for an entire fort history and then dropping down below 50 as soon as that channel gets dug.

Caverns may or may not be the real culprit in any of my slowdowns - I sometimes seem to notice a bit of a hit around that time in the game, but it is never so drastic and it's not immediate, so it could be something else happening. The game is doing a hell of a lot every tick and I am deeply skeptical of any anecdotal observations about framerate, even my own - but the relationship with large water features and the magma sea is just too immediate for me to ignore.

[ab9rf]

No, because it would take forever, there are lower-hanging fruits, and the game does not run slow enough to do that.

Like... I am not terribly convinced that anyone who thinks this game runs unacceptably slow has ever played another game which is even mildly similar to this one in their life. Try playing Civilization IV sometimes, which is doing less simulation per tick and still takes multiple seconds. Or, hell, The Sims 3.

indeed, as harsh as I can often be with regard to the parts of this game that are not optimally coded, in reality most of the code is good. it's just that, well, it can always be better. and i've long been impressed by how robust dwarf fortress is.

[anewaname]

In a 1-wide corridor, dwarfs only will pass each other when there is no alternate route. If there is an alternate path, they will use it.

Here is a DFFD 50.05 example with two rooms connected by two 1-wide corridors, and three stockpiles linked in a loop. It should load up with two dwarfs heading towards each other in one corridor. When they meet, one reverses direction to use the other corridor, and there meets another dwarf but because there is no alternate route, one dwarf goes prone so they can pass.

[Saiko Kila]

Here is a DFFD 50.05 example with two rooms connected by two 1-wide corridors, and three stockpiles linked in a loop. It should load up with two dwarfs heading towards each other in one corridor. When they meet, one reverses direction to use the other corridor, and there meets another dwarf but because there is no alternate route, one dwarf goes prone so they can pass.

Maybe it's fatigue, but I cannot seem to find a stance indicator (if the dwarf is prone or not) in the new interface. I have downloaded your example, and got two dwarves in the same tile, but don't know which one is prone?

[anewaname]

Run it at a lower FPS, you'll see the dwarf's icon change when they go prone.

The prime reason for that example is to show the problem with using 1-wide corridors when alternate routes exist.

[Thorfinn]

In a 1-wide corridor, dwarfs only will pass each other when there is no alternate route. If there is an alternate path, they will use it.

That's what I thought was happening. Maybe I misunderstood this exchange?

Seems to me the simplest solution is to just let dwarves pass through one another on a path 1 wide that has already been charted for typical moves between points A and B.

they already do this

[EDIT]
Oh, I bet he thought I meant the behavior we all know about, lying down and letting the other guy go around him. I thought the easiest way to code it would be to path through the other dwarf as if he were not there. Then only objects the pathing would have to plan around are static objects like statues. Currently dwarves have not just the static objects to path around, but also the moving dwarves, which is inherently more time consuming.
[/EDIT]

[Saiko Kila]

Run it at a lower FPS, you'll see the dwarf's icon change when they go prone.

The prime reason for that example is to show the problem with using 1-wide corridors when alternate routes exist.

I honestly see no difference in their sprites if they are on the same tile.

Anyway, most of the time, if they are going in the opposite direction, they swap in one tick, without the intermediate step of being in the same tile. When they go the same direction, then for some ticks they are on the same tile (but I cannot tell if one of them is prone or not), when one of the dwarves is faster.

And  when they would bump into one another going opposite direction, and there is alternate route, then one changes route to alternate - which is as it was in previous versions.

Isn't it as it is supposed to be?

[anewaname]

Yep, it is the same as before, and it appears to be as it was intended to be. I also don't think it should be changed. But it can a nasty surprise when a mob of dwarfs find an alternate route through 300 tiles of the caverns because they were all using a 1-wide tunnel to haul stuff 30 tiles then you opened a second entrance into the caverns elsewhere while mining. Or, you have two staircases going into the depths but one goes through a heavy aquifer project that you lost control of and also created an alternate path through the pouring water (when you find a pile of dead dwarfs and wheelbarrows at the bottom of the stairs, you question why they chose that much longer and more dangerous route).

My reason for uploading the DFFD example is because pathing in 1-wide hallways was mentioned a bunch of posts earlier, but the "unless there is an alternate route" condition wasn't mentioned. I remember those forts every time I'm choosing how wide to dig a hallway.

[Thorfinn]

Yeah, thanks. Agreed on that it's working as intended and as it should.

I used to run into that long alternate path stuff in my early days of trying to figure out forts that weren't just branching out from a central stair.

[shiverczar]

I read through most of this thread, and paid attention but didn't understand many of the parts when y'all got a bit more technical...

To put what I think I understand in layman's terms:

Every time a check is made to see what Dwarf Child A can see, it checks against every creature that has ever existed in the fortress, as opposed to only those that are still alive, present, and reasonable to consider.
Which means if you had 200 ducks, they'd slow down line of sight checks because the game is both checking to see if each of those ducks can see anything and everything else has to check to see if they can see each of those ducks.
Then, when you slaughter them it will help a bit (we no longer have to check if the 200 ducks can see anything) but would still leave a permanent dent because 50 years later Dwarf A (now an adult) will still be considering whether it can see each one of those 200 long-dead ducks whenever it checks to who it can see.

It sounded like there were several different options on how to fix this - from pruning the list of inactive creatures, to creating a new list specifically for these kinds of checks that only contains the active creatures from the original complete list - but right now, it sounds like having fewer creatures *ever* within your fortress is the best way to block FPS slowdown, rather than worrying as much about how many are there at any given time?

TBH it's not something I'm overly concerned about as I can't recall having any FPS-death forts aside from ones that were already dying from flooding
My forts usually 'die' because I embarked in a rather suicidal manner, screwed up something significant, or wanted to try something different before I even got that far.

But I am always curious about the reasoning behind these issues whenever I happen to be made aware of them

[Putnam]

Every time a check is made to see what Dwarf Child A can see, it checks against every creature that has ever existed in the fortress, as opposed to only those that are still alive, present, and reasonable to consider.

No, it was actually explicitly skipping dead/caged/ghost units that was causing most of the slowdown. They're not being checked at all for most purposes.

It sounded like there were several different options on how to fix this - from pruning the list of inactive creatures, to creating a new list specifically for these kinds of checks that only contains the active creatures from the original complete list - but right now, it sounds like having fewer creatures *ever* within your fortress is the best way to block FPS slowdown, rather than worrying as much about how many are there at any given time?

Pruning the list of dead creatures is maybe in the pipeline, creating a new list that contains only the active creatures has actually already been done the whole time, which is why just removing the redundant check from the list was such a large performance improvement

[shiverczar]

Every time a check is made to see what Dwarf Child A can see, it checks against every creature that has ever existed in the fortress, as opposed to only those that are still alive, present, and reasonable to consider.

No, it was actually explicitly skipping dead/caged/ghost units that was causing most of the slowdown. They're not being checked at all for most purposes.

Ah, so rather than Dwarf A actually checking to see if he could see the long-dead ducks, it was Dwarf A deciding: "I don't have to check if I can see duck 1...200"?

It sounded like there were several different options on how to fix this - from pruning the list of inactive creatures, to creating a new list specifically for these kinds of checks that only contains the active creatures from the original complete list - but right now, it sounds like having fewer creatures *ever* within your fortress is the best way to block FPS slowdown, rather than worrying as much about how many are there at any given time?

Pruning the list of dead creatures is maybe in the pipeline, creating a new list that contains only the active creatures has actually already been done the whole time, which is why just removing the redundant check from the list was such a large performance improvement

Ah, so you already did the thing. Didn't catch that while reading through the thread. After looking back, I suppose that's the "Other fixes/tweaks: Sped up line-of-sight code" that I kind of missed in the changelog   

Thanks for taking the time to answer!