Print

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

[gchristopher]

It helps just to know that the length of the unit vector matters. Thanks!

Maybe that's a step towards being able to write dfhack scripts to clean up that and other structures that expand during fortress mode? Is there anything from world activation that's growing unbounded and not being trimmed like it would be in worldgen?

Fortresses at FPS death don't have THAT many more units/items/etc if you've been careful about keeping the fort clean. Is there also a giant array of dirty socks or fire ash or pecans somewhere killing the game?

[Orange-of-Cthulhu]

My personal non-verified belief is that trees and junk amount to a lot of FPS death.

I'm pretty sure all items are simulated also regarding their tempature and dryness/wetness and so on. So if you have thousands and thousands of items like avocado pits and xxxsockxxx and so on, it's got to use computing power.

I started atom smashing junk straight from the z-screen, where you can really have thousands and thousands of leftover junk items generated for instance by avocados. Some plants generate a waste item, you also get peach pits for instance. And you can easily have 10K of those lying around sucking computing power without even being aware of it.

Another belief I have is that TREES slow down the game. I read somewhere the game simulated the growth of branches and twigs and so on, so a single tree must take up computing power.

I had some forts that were in heavily forested areas and grind slowly to a half, destpite the population not growing a lot. Since then I've taken to do very heavy-handed forest management, preventively clearing most of the surface from trees - and it seems to work.

[Putnam]

My personal non-verified belief is that trees and junk amount to a lot of FPS death.

I'm pretty sure all items are simulated also regarding their tempature and dryness/wetness and so on. So if you have thousands and thousands of items like avocado pits and xxxsockxxx and so on, it's got to use computing power.

I started atom smashing junk straight from the z-screen, where you can really have thousands and thousands of leftover junk items generated for instance by avocados. Some plants generate a waste item, you also get peach pits for instance. And you can easily have 10K of those lying around sucking computing power without even being aware of it.

Another belief I have is that TREES slow down the game. I read somewhere the game simulated the growth of branches and twigs and so on, so a single tree must take up computing power.

I had some forts that were in heavily forested areas and grind slowly to a half, destpite the population not growing a lot. Since then I've taken to do very heavy-handed forest management, preventively clearing most of the surface from trees - and it seems to work.

No, no, this is pretty verified. The slowest parts of a 6x6 fort I ran for 25 years were:

1. some sort of map activity that I'm like 50% sure was tree/plant growth
2. temperature

So this is, in fact, borne out by the data.

But this can be mitigated massively by just playing on a smaller embark.

[Erk]

Obviously the correct solution is to pave all growable soil on the surface.

[Orange-of-Cthulhu]

Obviously the correct solution is to pave all growable soil on the surface.

Or just dig away the soil layers, so it's just lovely bare rock.

[Insert_Gnome_Here]

What's the (software) caching of LOS like? AFAICT, whether Urist McAlice can see Urist McBob can change if either of them move, if Urist McAlice gets her eyes stabbed out etc. or if some bit of the environment that affects LOS changes.
So you could have an nxn matrix for your n units used as a cache. Whenever a unit moves, its row and column are wiped. Whenever something in the world changes e.g. a tree is felled so you can see through where the trunk used to be, the whole matrix is wiped (or maybe you can find a way to only wipe a subset of it). World LOS changes don't seem to happen that often unless something weird is happening like obsidian is being formed so you'd usually only have to recalculate LOS relating to entities that moved last tick.

Sorry if this is a bad suggestion I seldom stray this close to bare metal. IDK if it would play nice with the crazy optimisations CPUs do nowadays.

[Putnam]

I'm not sure there is any.

On my latest fort, which currently has 270 citizens, the "can I see these units?" check has been overtaken by a huge margin by checks that I'm pretty sure are actually line-of-sight stuff, so hey, ignore my advice earlier, you totally should try to keep dwarves from clustering up too hard.

To be specific, it's something that checks that both units are historical figures and then checks their relationships to each other--might have to do with family needs? It's kinda hard to tell what's actually happening, but there's a lot of binary searching through the hist figure vector going on.

[therahedwig]

To be specific, it's something that checks that both units are historical figures and then checks their relationships to each other--might have to do with family needs?

That might also be villain/intrigue stuff, there's a lot of little variables there that afaik are largely in the histfig?

[Dr. Hieronymous Alloy]

My personal non-verified belief is that trees and junk amount to a lot of FPS death.

I'm pretty sure all items are simulated also regarding their tempature and dryness/wetness and so on. So if you have thousands and thousands of items like avocado pits and xxxsockxxx and so on, it's got to use computing power.

I started atom smashing junk straight from the z-screen, where you can really have thousands and thousands of leftover junk items generated for instance by avocados. Some plants generate a waste item, you also get peach pits for instance. And you can easily have 10K of those lying around sucking computing power without even being aware of it.

Another belief I have is that TREES slow down the game. I read somewhere the game simulated the growth of branches and twigs and so on, so a single tree must take up computing power.

I had some forts that were in heavily forested areas and grind slowly to a half, destpite the population not growing a lot. Since then I've taken to do very heavy-handed forest management, preventively clearing most of the surface from trees - and it seems to work.

No, no, this is pretty verified. The slowest parts of a 6x6 fort I ran for 25 years were:

1. some sort of map activity that I'm like 50% sure was tree/plant growth
2. temperature

So this is, in fact, borne out by the data.

But this can be mitigated massively by just playing on a smaller embark.

Is it the size of the embark or the size of the, for lack of a better term, exposed surface area?

A small embark that's been massively mined out would have a lot of exposed space and items that would need ongoing temperature checks.

[malvado]

Personally I think that putting a limitation to how many trees grows and growth ratio (depending on amount of trees in area and fungus / mushrooms etc ),  might help FPS a bit over time.
I remember that sometimes discovering areas with fungus and then seeing the increase in growth ratio used to also affect the FPS.
Im playing on a 6x6 map right now with a lot of trees and Can't say it's bad. Been ages since I've had a time for DF but I guess im going to play a bit more from day to day.

[Telgin]

I'd guess opening the caverns and starting fungal growth in all underground areas may still impact FPS, unless the game is running the same checks on every tile whether or not plant growth is actually possible on the tile.

[Kylerace]

Very surprising that LOS is implemented that way. For dwarf fortress I'd imagine a good improvement is to just put everything in an oct-tree, possibly with an additional optimization to subdivide leaf nodes to only cover the z levels that actually have non solid tile connections to other z levels based on some heuristic (im betting most entities that end up in LOS to each other are on the same z coordinate most of the time). any spatial data structure is going to have more overhead than the current implementation for some number and configuration of entities but since the problem is n^2 fps death at 150+ entities it shouldn't really matter. Also have to deal with removing/inserting/possibly rebalancing any structure you use but with < 300 entities and < 1 node transition per tick per entity the vast majority of the time its probably a completely trivial overhead. Optimizing for only interconnected z levels is probably better on average but worse for entities that ignore or dont have obstructing floors/ceilings like fliers or creatures with EXTRAVISION.

Also interested in how often this is calculated. If theres nothing potentially hostile on the map you might not need to do this very often at all. The naive solution is to just set a flag if any entity on the map is hostile to any other entity on the map and change the global LOS check frequency between 1 / n ticks and 1 / 1 tick but obviously that has a lot of down time as an optimization. I think? a better solution is to update the flag per entity whenever an entity comes onto the map / becomes inanimate / becomes animate / changes loyalty / becomes/stops being agressive etc. and then put each entity into a matching fixed length circular timer list and/or check their LOS immediately, and then provide a time delta to each process when its called again so it can scale factors by the appropriate amount as if they had repeated that process once per tick.

EDIT:

On my latest fort, which currently has 270 citizens, the "can I see these units?" check has been overtaken by a huge margin by checks that I'm pretty sure are actually line-of-sight stuff, so hey, ignore my advice earlier, you totally should try to keep dwarves from clustering up too hard.

To be specific, it's something that checks that both units are historical figures and then checks their relationships to each other--might have to do with family needs? It's kinda hard to tell what's actually happening, but there's a lot of binary searching through the hist figure vector going on.

didnt see this, this definitely doesnt sound like something that has to happen every LOS check

[Putnam]

My personal non-verified belief is that trees and junk amount to a lot of FPS death.

I'm pretty sure all items are simulated also regarding their tempature and dryness/wetness and so on. So if you have thousands and thousands of items like avocado pits and xxxsockxxx and so on, it's got to use computing power.

I started atom smashing junk straight from the z-screen, where you can really have thousands and thousands of leftover junk items generated for instance by avocados. Some plants generate a waste item, you also get peach pits for instance. And you can easily have 10K of those lying around sucking computing power without even being aware of it.

Another belief I have is that TREES slow down the game. I read somewhere the game simulated the growth of branches and twigs and so on, so a single tree must take up computing power.

I had some forts that were in heavily forested areas and grind slowly to a half, destpite the population not growing a lot. Since then I've taken to do very heavy-handed forest management, preventively clearing most of the surface from trees - and it seems to work.

No, no, this is pretty verified. The slowest parts of a 6x6 fort I ran for 25 years were:

1. some sort of map activity that I'm like 50% sure was tree/plant growth
2. temperature

So this is, in fact, borne out by the data.

But this can be mitigated massively by just playing on a smaller embark.

Is it the size of the embark or the size of the, for lack of a better term, exposed surface area?

A small embark that's been massively mined out would have a lot of exposed space and items that would need ongoing temperature checks.

I checked again using a decompiler and some struct knowledge--#1 was actually map block processing, which included spatters and... temperature. So not a terribly huge surprise. And yes, more exposed surface and more items is going to make it far worse. A desert is also going to have less issues, due to fewer contaminants from leaves etc.

[Bumber]

A desert is also going to have less issues, due to fewer contaminants from leaves etc.

DFHack's clean command has been known to recover some FPS in my old forts. Feels like we should have some performance options to disable things like snow cover and useless tree droppings for fort mode. That's only a delay to the inevitable FPS death, however.

[ab9rf]

I'd guess opening the caverns and starting fungal growth in all underground areas may still impact FPS, unless the game is running the same checks on every tile whether or not plant growth is actually possible on the tile.

the game does this check in a staggered manner over the course of many ticks. only a fraction of eligible tiles are checked each check, and i believe even the "staggered" checks aren't done on every tick. so the ultimate impact is likely to be relatively low even if you were mine out every level of all the caverns.