Print

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

[Putnam]

Yeah, the rendering of the tiles themselves is threaded but putting together everything that needs to be rendered takes some time. It ought to be negligible, though, like, only noticeable if you're a weirdo who plays at 1200 FPS like me.

[bloop_bleep]

The game actually does use SPEC_HEAT. Heat transfer, per tick, adds (environment temp-item temp) to the fractional portion of the item's temperature fixed point, and if the item's fractional portion is > the SPEC_HEAT of the material, it rolls over to the next.

Temperature is a 32-bit fixed point, 16 bites reserved for the whole part and fractional part each. If e.g. iron is 1000 degrees hotter than the environment, it'll cool by 1000 fractional parts, which means next tick it'll be at (assuming the environment here is 10000) 10097+350 fractional part, which is of course 10097.777... degrees.

Ah... interesting. In that case you can remove from the list any items that have reached environmental temperature, which is most of them, no?

[mightymushroom]

I think it would depend in part on how much 'environmental temperature' is subject to change. Outdoor weather, for instance. Also, many items (anything worn/equipped, anything in a minecart, etc.) can move from tile to tile. One can easily check if an item matches the tile temperature on the current tick, but that equality is in my opinion an uncomfortably loose predictor as to whether it continues to match its tile temp in the next tick.

(Edit: I only half-expressed my concern.)

[SystemsTestCanary]

What about the thing that I saw discussed on the Kitfox Discord? I forget what exactly was said, but it was something about setting "normal pathing" (probably not the right phrase) to 0 and other paths to 1 giving a big boost? What's the deal with that?

You're thinking of a post where someone researched the effects of using different Traffic Designations, and of using init.txt to change some of those to 0 or -1 cost. I'll try to find you the exact thread.

[Putnam]

What about the thing that I saw discussed on the Kitfox Discord? I forget what exactly was said, but it was something about setting "normal pathing" (probably not the right phrase) to 0 and other paths to 1 giving a big boost? What's the deal with that?

EDIT: snip

[Qev]

A lot of the CPU time in unit checks is wasted in branch misprediction due to the fact that it's checking the units vector and just skipping everything that happens to be inactive/caged/a ghost; if those units' indices (or pointers to them, as the case happens to be, unfortunately) were simply cached in a vector that contains only active/uncaged/non-ghostly units, that would be avoided and the game would probably run quite a bit faster.

So does this mean that caging excess livestock is actually worse, or am I misreading things?

[Putnam]

It's better, it's just not as much better as it could be.

[bloop_bleep]

It's better because otherwise the game would actually be doing sight checks for the livestock if they were out of the cage, instead of just branch mispredicting on them.

[Xen0n]

Very interesting read, thanks for your efforts, Putnam!

I've always tried to read through discussions on FPS loss when I play over the years, and I hate constantly having in the back of my head, "Well I could design this section of the fort the way I actually want, but instead I need to think about what will be the most FPS-friendly since every fort is playing on a time-limit."
I have always worried about how much of it is actually accurate and how much is just speculation / rumour, so it's nice to get a little verification on which factors are significant or not.

In particular, does this issue with units checking every other unit make any difference on whether a dead dwarf was buried in a coffin vs. atomsmashed / burned in magma? I know you mentioned that ghosts contribute to the "checking for line of sight," but assuming you have slabs for all dead dwarves, is there any one particular method of body disposal that would be "best" as far as mitigating the number of units needing to check each other?

[Bumber]

Sounds like Toady just needs to do for units what he's already done with df.global.world.items.other vectors.

[Putnam]

Very interesting read, thanks for your efforts, Putnam!

I've always tried to read through discussions on FPS loss when I play over the years, and I hate constantly having in the back of my head, "Well I could design this section of the fort the way I actually want, but instead I need to think about what will be the most FPS-friendly since every fort is playing on a time-limit."
I have always worried about how much of it is actually accurate and how much is just speculation / rumour, so it's nice to get a little verification on which factors are significant or not.

In particular, does this issue with units checking every other unit make any difference on whether a dead dwarf was buried in a coffin vs. atomsmashed / burned in magma? I know you mentioned that ghosts contribute to the "checking for line of sight," but assuming you have slabs for all dead dwarves, is there any one particular method of body disposal that would be "best" as far as mitigating the number of units needing to check each other?

Doesn't make a difference, unit's still loaded anyway. DFHack's fix/dead-units unloads them either way, though.

[Xen0n]

Doesn't make a difference, unit's still loaded anyway. DFHack's fix/dead-units unloads them either way, though.

Good to know, thanks! Already updating my standard "FPS best practices" personal notes I keep in anticipation of the Steam release.

[ab9rf]

Guys, the ideal data structure would be a hash table, e.g. std::unordered_set, no? O(1) insertion, deletion, iteration, at least in theory. At most there could be some data locality issues with jumping between different buckets.

The principal high-load use for this data requires enumerating it, not searching it by a key, and so a contiguously allocated vector, ideally aligned with cache line boundaries, is what you want for peak performance.

[Alyfox]

I'm a rather non-technical person (though, I do wish I had the brainpower for coding and understanding it!), but my take on this whole discussion so far is: keep populations lower. Its difficult/impossible to control the presence of wildlife, raiders, sieges, etc, but pop-control is easier for your dorfs and their pets/livestock/etc. Keeping those lower should help? (edit: also lowering the number of allowed visitors!)
Also, are vermin counted in these "checking everything for presence of LOS" checks?

[Robsoie]

Then some question about fortress optimisation, on DF 34.11 there was this :
https://dffd.bay12games.com/file.php?id=7750
that was having 400 dwarves , lots of items ... while not suffering from any fps death, it was actually running quite fast.

What was the reason of this , even when i was playing on 34.11 i never saw something running well once i started to get a hundred of dwarves on small map size like that ?