Print

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

[mzreaper]

Howdy
If someone has already broached this topic or toady already said he was looking it please feel free to boop me over the head.

That being said, there is 1 major issue with the game at its current state for me, performance. I know its a difficult issue, but I play on a decent gaming pc, with good single core performance, I'm also very FPS conscious while paying, setting up the fortress, laying out traffic designations and pathing, capping number of dorfs, visitors, pets, etc, using workshop to keep number of items in check and getting rid of excess items as well as using some df hack commands like clean all. Still, I'd say around 80% of all my played fortresses died of FPS death.

Losing a fortress in a FUN way or it reaching the end of its natural life leaves a very different kind of feeling than been forced to abandon an awesome fortress due to FPS.

And this problem gets compounded with some of the best features in the game like magma, water or god forbid the circus. And did someone say above ground structures?
I mean, how is a humble dwarf supposed to flood the world with magma or build 100z lvls tall steel colossus of a dwarf holding a giant golden mug of beer?

But in all seriousness, every time i get excited about a new fortress embark and give up a few minutes later when I realize my grand plans will never reach fruition, even if i survive, due to FPS.
I know its a hard issue to solve and that it isn't usually a priority during development, but should be looked into for the steam release.

Well, at least that's my opinion as an arm-chair expert.

[Bjorn]

I second this. In the same vain, world gen is very very slow. I know it is actually simulating a lot of things, but I imagine it would be a lot faster if it was done through multithreading. I imagine it would be pretty hard given that many events are supposed to be sequential, but if Toady ever managed to crack how to do it, it would be a huge game changer for me (because I love to make gigantic old worlds).

[ayy1337]

Performance is, hands down, the number 1 issue with the game for me and has been for probably 10 years?

Yes you can sort of design your fort around it to minimize the problem, but when you have to start making 100 immersion breaking adjustments to the way you play just so the game doesn't become unplayable.. I think it's fair to say the situation could use some improvement. Obviously optimizing performance is difficult and not everyone's cup of tea, but it desperately needs to be addressed imo.

Would be really great if Toady released some time profiling showing which functions or at least which broad activities are the most costly & tend to bog down advanced forts.

Performing some tasks in parallel and fixing pathfinding seem like the easiest major improvements to make but it's hard to say without seeing what the game is spending time on.

[A_Curious_Cat]

Multi-threading would, if I understand correctly, require that the game be rewritten completely from scratch.  It’s not really an option at this point…

[ayy1337]

Multi-threading would, if I understand correctly, require that the game be rewritten completely from scratch.  It’s not really an option at this point…

Well it's not entirely true that employing threading necessitates a lot of code rewriting in all cases. To give one example that might be easy, updating the wear level of all the items on the map - an item doesn't need to check the wear level of other items so you could split the items up into batches and give each batch to a thread and wait until they're all done, without even worrying about locks.

Making the whole game run in parallel and having different parts of the game update concurrently could be more tricky, but you don't need to do that to get a lot of benefit from it.

[☼Obsidian Short Sword☼]

The only parts that need to be run in parallel are the features that cause the biggest performance issues. Any thing else is a waste of time to re-build.

Another thing to take into account(Am I seeming rude?), is that Dwarf Fortress seems to operate on a lot of shared memory. Pathfinding, Temperature calculations, placing voxels, All require sharing memory.

[ayy1337]

The only parts that need to be run in parallel are the features that cause the biggest performance issues. Any thing else is a waste of time to re-build.

Another thing to take into account(Am I seeming rude?), is that Dwarf Fortress seems to operate on a lot of shared memory. Pathfinding, Temperature calculations, placing voxels, All require sharing memory.

Yeah you would definitely want to start with the worst offenders in terms of performance first.

And yes all threads operate on the same memory inherently, because they're in the same process. Basically a lot of the issues come from one thread reading/writing to the same object another thread is writing to. Generally speaking as long as each thread ONLY modifies objects no other thread is going to access, you can't get thread-based inconsistencies.
If you need to modify objects other threads need to access too, then you can manage that with things like locks but they're sometimes tricky to reason about and you might accidentally create deadlock situations.
But in any case it's not some insurmountable difficulty

[☼Obsidian Short Sword☼]

But in any case it's not some insurmountable difficulty

Coordination should not be impossible, But I'm concerned about scalability issues.

[Starver]

...not a direct and personal reply, just a handy reference to jump off of in restating my usual opinion...

I second this. In the same vain, world gen is very very slow.

When I first started playing, I'd start a worldgen at the end of the day and let it run. By the morning I'd have a genned world waiting for me. (Initially, that being done, I enjoyed the worldgen map, scrolled round it, and probably genned another one later, just to get another. I certainly took a while to learn how to properly use that map, with much stupidity along the way, including being unable to reliably feed my fortress, hence this username.)

I have really never had FPS Death in a fort. Not because of brilliant machines (rarely was that the current reality), not because of clever FPS-sympathetic designs (I design mostly for multipath fortresses that makes for efficient game-time for each dwarf but apparently really slows play-time) and not always because I'm abandoning/not continuing fortresses early (if I do, it's because intentions and 'game reality' fail to mesh to some insurmountable degree).

I just do so much micromanagement that, most of the time, I'm often on pause anyway whilst juggling designations or managing dwarves (direct or through Therapist) and waiting a significant craction of a second for the next bit of action is irrelevent. Not like an FPS where you're wondering if your strafe command has gotten through the keyboard/mouse and you're in doubt whether enough (or too many!) of your shots are going to end up going in the desired direction once the cause of lag gets resolved...


The one FPS-Death instance I could tell you of was Adventure Mode. As best I ever could tell, deep below the terrain I was walking on was some sort of badly generated caverns/etc, where magma/water/both busily flowed around and through some discontinuity (or perhaps Clowns had found an open flap on their circus-tent). I tried to map the area of effect by setting up campfires (it was just after bogeymen were introduced, yet all I saw on the surface was a normal amount of wildlife) but it got far too laggy so I never got to find out if the campfires even survived chunk un/reloading as I tried to establish the edge of effect...


Obviously, my style of play (and expectations/tolerance) is not typical of everyone, especially those with issues to declare in the vein of this thread, so I'm going to be a lonely voice here for various reasons. I do not deny that someone else (new to the game) could be put off before learning the various joys and peculiarties. However, the situation is much improved from the 'good old days', if only because CPUs are given GHz speed-ratings rather than MHz ones and physical RAM has had a similar degree of Moore's Law upgrade (with disc-access being faster too, when it does need to page-swap). And whether the Premium-Capable release has optimisations (not outweighed by additional resource-sapping 'improvements') is as yet unknown. I suspect there'll be some rewrites making it not just two-thread (as it became in my time) but capable of better using 4-core-or-more systems, or maybe using even single-cores more efficiently overall.

[ayy1337]

But in any case it's not some insurmountable difficulty

Coordination should not be impossible, But I'm concerned about scalability issues.

Like what in particular?

Another idea I had the other day was on item checks, instead of checking every item every frame, you could do item checks on a fraction of items so that each one is updated every 2, 3, 4, or 5 frames. Combine that with threads and you can easily cut time taken for maintaining items 90+%.

[☼Obsidian Short Sword☼]

Like what in particular?

You would have to lock the voxel data every time you need to write to it, And that scales rather poorly

[ayy1337]

You would have to lock the voxel data every time you need to write to it, And that scales poorly

Well, it depends how you set it up I think. If you have some task like update all the voxels, you could split them up so that only one thread touches each voxel.

But even if you have a task where you can't ensure that level of separation the overhead of locks is going to be a tiny tiny cost compared to the advantage of 2-8x the processing capacity afforded by multithreading.

[Bumber]

The issue is where a calculation in one area can mess up a whole bunch of other ones. Fluid pressurization (itself an optimization) allows liquids to teleport all the way across the map in a single tick, so you can't readily break the issue down into smaller chunks.

I suspect many of the FPS issues are actually related to bugs. E.g., this one:
http://www.bay12games.com/dwarves/mantisbt/view.php?id=3807
Plants grow on top of other plants, causing increasingly bloated plant vectors over time. These vectors need to be iterated frequently for plant growth.

[Salmeuk]

Howdy
If someone has already broached this topic or toady already said he was looking it please feel free to boop me over the head.

no you're the first one after 18 years