Print

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

[Shazbot]

You know, Daikatana worked great if you stood still on the first level and stared at the floor. Unfortunately DF's upper limit for fortress mode is supposed to simulate 200 dwarves simultaneously plus livestock, wildlife and invaders. If it isn't possible to run a mature fortress at a reasonable framerate in a 4x4 embark using only vanilla UI elements, then something has to change. Maybe you can play without performance degradation with twenty or thirty dwarves. That's not the design spec.

[Purple Gorilla]

It appears, that creatures who can't find a path request a path on every turn (like the [clowns] if you seal [the circus]).

Possible solution :
* add a variable named unsigned int i_am_lost into the structure/class of a creature.
* got to the function, that computes a path. I assume it is called whenever a creature requests a path, and the path or parts of it are stored as nodes into the creature. we assume the creature is a pointer named *cr (in oop it might be a method of creature, thougt oop is not effecient in general).

At the beginning :
 if(cr->i_am_lost) {cr->i_am_lost--;return;}
 ....
At the point, there a creature didn't find a path to its destination :
 cr->i_am_lost=random(50)+50;

This will set stuck creatures to idle, and prevent the 100 stuck [clowns] from eating up CPU time.

*Now a bit optimization: If a creature needs a path to fight, or for the case it might want to flee, set cr->i_am_lost to zero if :
** It got attacked
** It is a dwarf, and its labour preference was changed
** It is a dwarf, and the player gave a military order
** A door or hatch was unlocked by the player
** A door, hatch drawbridge or floodgate was unlocked by a trigger
* more optimization : Decide, which creatures are Bosses. Forgotten [Fluffy Rabbit], Dr[ake], Mega [Fluffy Rabbit] or the like, are bosses, and the value is set to 10 instead of 50. This will give them a fast reponse time. The [clowns] of the [party catering], if you dig through an [asbestos] vein are no bosses -what makes the deadly is primary their number of 100 or so, and not the individual [clown]. The value should however always be set, as it appears, that a single stuck miner can slow down the game.

Instead of optimizing Dwarf Fortress, it might actually be more important, to fix the abundand crashes. I never actually "finished" a game in dwarf fortress, because it will always reach a point, then a safefile will crash after unpauseing, and of course crash every hour or so anyway. Dr Watson 32 shows, that all crashes are acces of a NULL pointer, so all crashes could be prevented, by checking for NULL Pointers before acessing them. An interesting point is also, that the famous tree bug actually calls a NULL Pointer, what is the Curse of Object-oriented Programming (probably a vitual Method). If someone ever wants to write a stable remake of Dwarf Fortress, I recomment, that you use standart C instead of C++, because it is much easier to prevent such critical errors with pure imperative programming.

[StagnantSoul]

It appears, that creatures who can't find a path request a path on every turn (like the [clowns] if you seal [the circus]).

Possible solution :
* add a variable named unsigned int i_am_lost into the structure/class of a creature.
* got to the function, that computes a path. I assume it is called whenever a creature requests a path, and the path or parts of it are stored as nodes into the creature. we assume the creature is a pointer named *cr (in oop it might be a method of creature, thougt oop is not effecient in general).

At the beginning :
 if(cr->i_am_lost) {cr->i_am_lost--;return;}
 ....
At the point, there a creature didn't find a path to its destination :
 cr->i_am_lost=random(50)+50;

This will set stuck creatures to idle, and prevent the 100 stuck [clowns] from eating up CPU time.

*Now a bit optimization: If a creature needs a path to fight, or for the case it might want to flee, set cr->i_am_lost to zero if :
** It got attacked
** It is a dwarf, and its labour preference was changed
** It is a dwarf, and the player gave a military order
** A door or hatch was unlocked by the player
** A door, hatch drawbridge or floodgate was unlocked by a trigger
* more optimization : Decide, which creatures are Bosses. Forgotten [Fluffy Rabbit], Dr[ake], Mega [Fluffy Rabbit] or the like, are bosses, and the value is set to 10 instead of 50. This will give them a fast reponse time. The [clowns] of the [party catering], if you dig through an [asbestos] vein are no bosses -what makes the deadly is primary their number of 100 or so, and not the individual [clown]. The value should however always be set, as it appears, that a single stuck miner can slow down the game.

Instead of optimizing Dwarf Fortress, it might actually be more important, to fix the abundand crashes. I never actually "finished" a game in dwarf fortress, because it will always reach a point, then a safefile will crash after unpauseing, and of course crash every hour or so anyway. Dr Watson 32 shows, that all crashes are acces of a NULL pointer, so all crashes could be prevented, by checking for NULL Pointers before acessing them. An interesting point is also, that the famous tree bug actually calls a NULL Pointer, what is the Curse of Object-oriented Programming (probably a vitual Method). If someone ever wants to write a stable remake of Dwarf Fortress, I recomment, that you use standart C instead of C++, because it is much easier to prevent such critical errors with pure imperative programming.

Any demon that's not made of vomit or anything weak like that is a challenge as an individual.

[cata2k]

On the topic of optimisation I am a little confused. For one I was taught that optimisation was for the end of a project and thought this was a common rule of programming. On the other hand I see sense in getting some extra performance when the fruit is low hanging. Luckily for us Toady does some optimisation of this kind after major releases.

DF isn't supposed to be complete for 20+ years. Nobody is going to wait that long to get playable FPS. I, for instance, have a cap of 80 dwarves in a fortress on my i5 laptop, and get ~25 fps. There's a lot going on in DF, I get it, but how much longer can we continue to add features that will continue to eat processing power in a game that isn't even multithreaded and already nearly unplayable due to slow performance?

[lethosor]

An interesting point is also, that the famous tree bug actually calls a NULL Pointer, what is the Curse of Object-oriented Programming (probably a vitual Method). If someone ever wants to write a stable remake of Dwarf Fortress, I recomment, that you use standart C instead of C++, because it is much easier to prevent such critical errors with pure imperative programming.

Sort of - the issue is that pending constructions on trees are deleted incorrectly, which causes a crash when DF tries to call a virtual function after the vtable has been overwritten (according to this comment). It could be that this memory is zeroed by something else, causing a null pointer dereference, but that has nothing to do with the use of C++ over C - free() would similarly cause a crash.

[StagnantSoul]

Multi-threading is often the cause of fps death, or does close to nothing for a game. Optimization is better done with something more reliable and less time consuming.

[Bumber]

*Now a bit optimization: If a creature needs a path to fight, or for the case it might want to flee, set cr->i_am_lost to zero if :
** It got attacked
** It is a dwarf, and its labour preference was changed
** It is a dwarf, and the player gave a military order
** A door or hatch was unlocked by the player
** A door, hatch drawbridge or floodgate was unlocked by a trigger
* more optimization : Decide, which creatures are Bosses. Forgotten [Fluffy Rabbit], Dr[ake], Mega [Fluffy Rabbit] or the like, are bosses, and the value is set to 10 instead of 50. This will give them a fast reponse time. The [clowns] of the [party catering], if you dig through an [asbestos] vein are no bosses -what makes the deadly is primary their number of 100 or so, and not the individual [clown]. The value should however always be set, as it appears, that a single stuck miner can slow down the game.

Instead of optimizing Dwarf Fortress, it might actually be more important, to fix the abundand crashes. I never actually "finished" a game in dwarf fortress, because it will always reach a point, then a safefile will crash after unpauseing, and of course crash every hour or so anyway. Dr Watson 32 shows, that all crashes are acces of a NULL pointer, so all crashes could be prevented, by checking for NULL Pointers before acessing them. An interesting point is also, that the famous tree bug actually calls a NULL Pointer, what is the Curse of Object-oriented Programming (probably a vitual Method). If someone ever wants to write a stable remake of Dwarf Fortress, I recomment, that you use standart C instead of C++, because it is much easier to prevent such critical errors with pure imperative programming.

Whoa, easy on the commas there!

"i_am_lost" should be reset to zero whenever the pathing map changes. You forgot to account for constructions, digging, and temperature (magma.)

[Putnam]

Pathfinding is really not that big of an FPS problem. I used force migrants to get >100 dwarves and it didn't affect my FPS much at all (~200->~180). FPS death is almost surely something else entirely.

[StagnantSoul]

If pathfinding or large amounts of creatures was the issue, then bees would kill us. I've had 16 colonies going at once with high fps before. Remember the giant mosquito swarms in 34.1? Yeah, those didn't cause fps death, just the regular variety.

[Putnam]

bees do not pathfind

[StagnantSoul]

bees do not pathfind

...Oh. I thought even vermin did?

[Putnam]

vermin pop in and out of existence wherever they're allowed to exist

[StagnantSoul]

vermin pop in and out of existence wherever they're allowed to exist

Wow, never knew that. Thanks.

[Zammer990]

The UI is perfect unless you don't want to spend ten minutes learning it.

I like the UI, but there is real inconsistency in the hotkeying.
looking at you blacksmithing

[Vattic]

On the topic of optimisation I am a little confused. For one I was taught that optimisation was for the end of a project and thought this was a common rule of programming. On the other hand I see sense in getting some extra performance when the fruit is low hanging. Luckily for us Toady does some optimisation of this kind after major releases.

DF isn't supposed to be complete for 20+ years. Nobody is going to wait that long to get playable FPS. I, for instance, have a cap of 80 dwarves in a fortress on my i5 laptop, and get ~25 fps. There's a lot going on in DF, I get it, but how much longer can we continue to add features that will continue to eat processing power in a game that isn't even multithreaded and already nearly unplayable due to slow performance?

Hence the last two sentences you quoted. I am in favour of the continued trend of major releases being followed by periods of bug fixing and optimisation. As has been said the main issue causing FPS loss in longer forts seems to be some kind of bug (probably poor memory garbage collection). In the past such bugs have been fixed (see linked reports earlier in the thread). I don't know how long features can continue to be added before performance loss makes the game literally unplayable and neither do you. I feel we are all repeating ourselves by this point.