- v50 information can now be added to pages in the main namespace. v0.47 information can still be found in the DF2014 namespace. See here for more details on the new versioning policy.
- Use this page to report any issues related to the migration.
Difference between revisions of "v0.31:Maximizing framerate"
Orbcontrol (talk | contribs) (Added info about PRINT_MODE, and about the semi-popular "singlethreaded" misconception.) |
Orbcontrol (talk | contribs) (Added a bit more info to the single/multi-thread entry) |
||
| Line 29: | Line 29: | ||
* Some people try to reduce the number of items in the fort by "atom-smashing" them under a bridge or donating them away to traders. Alternatively, less digging in the first place results in fewer stones and corridors in the world to consider. | * Some people try to reduce the number of items in the fort by "atom-smashing" them under a bridge or donating them away to traders. Alternatively, less digging in the first place results in fewer stones and corridors in the world to consider. | ||
| − | * It will sometimes be mentioned is that since DF is single-threaded, followed by some-suggestion-or-other based on this assertion. This is no longer true. It is true that the vast majority of the work still takes place in a single thread, and Toady has no plans to ever multithread the game logic, but DF does have at least one other thread handling the SDL graphics. Be cautious of any FPS-increasing suggestions that | + | * It will sometimes be mentioned is that since DF is single-threaded, followed by some-suggestion-or-other based on this assertion. This is no longer quite true. It is true that the ''vast majority'' of the work still takes place in a single thread, and Toady has no plans to ever multithread the game logic, but DF does have at least one other thread handling the SDL graphics. This means that (all else being equal) DF should run faster on 2 cores than on 1, but won't run faster on 3 cores than it did on 2. |
| + | Be cautious of any FPS-increasing suggestions that still assume the game is completely single-threaded. | ||
| + | |||
== Success Stories == | == Success Stories == | ||
Revision as of 18:57, 10 December 2010
| This article is about an older version of DF. |
Template:L is used in Dwarf Fortress to measure the speed at which the game is running. To check your FPS (frames per second) in Dwarf Fortress, simply change [FPS:NO] to [FPS:YES] in Template:L, and your FPS will be displayed on the top row of the screen. The first number is the current frame rate, while the number in parenthesis is the current graphical frame refresh rate.
The graphical FPS is also used to control how often input is received; you may find 5-15 graphical rate too clumsy for fluid text and mouse input.
Ways to increase your framerate
- Limiting the number of dwarves and other moving units (cage or butcher animals!) greatly helps keep speed up.
- Due to bug (0000296), contaminants such as blood, snow, etc, count as items. Since contaminants can spread and you cannot easily get rid of them, try to avoid things that spread contaminants: wells, killing things in high traffic spots, and soap.
If you have a beast that exudes slime, you might as well save your game and wait for an update. Or kill it and use dfcleanmap.
- Get rid of blood and dirt splatters dwarves and pets are carrying around. Doing so increased FPS from 8 to 33 on my machine(6 embark tiles, 130 dwarves, 250 animals, 3 caverns). to achieve this, you can either build a moat/wading pool around a well-visited area, which keeps the water height on 1-2 by using a pump which will clean the water from the dirt. When the dwarves walk through the water, the contaminants will be washed away. A hacking-tools way is to place some 7/7 water splatters around important paths with dfliquids, and running dfcleanmap continuously to remove the blood that gets washed away from the dwarves.
- Decreasing the G_FPS in the init text file can improve your fortress' overall FPS. Be careful however, decreasing it too much can subject you to "incomprehensible graphic instabilities". G_FPS refers to the "maximum graphical frame refresh rate during play." In other words, the maximum number of times it repaints the graphics of your game per second. Remember, with a low G_FPS, it can be dangerous during battle or when arrows are flying over your Dwarves' heads, because the screen doesn't update as often. The default is 50 G_FPS, but it's been reported that 20 G_FPS is fine. Others report being able to play at even 5 G_FPS. There is no set number, just remember to test out a variety of numbers to see which one is right for you and your computer.
- While you're in the init file, play around with PRINT_MODE. DF has recently made it's first foray into SDL, and changing the print mode might let it take slightly better advantage of your graphics card.
- Disabling Temperature and Weather in the d_init file increases speed due to fewer calculations being required, but rain will clean the map from blood and broken arrows, so it may actually improve the framerate.
- World size and fortress site size increase RAM usage and decrease speed. Check if you are happier with an embark rectangle of 3x3 or 3x2 and a medium or small world.
- (DF .31.12) World size probably doesn't matter at all (except for save file size), but the embark size and how many cavern layers the world has (defaults to 3).
- Lowering the pathfinding cost for normal tiles to 1 can reduce lag created by open space, but then your high traffic zones are the same as normal zones. Alternatively, you can cover the entire map with high traffic tiles, and simply make everything you don't want your dwarves traveling through low or restricted.
- Closing the fort's entrance to the outside world with a raised bridge or forbidden door decreases the number of possible routes the pathfinder has to calculate, thus increases performance.
- Some people try to reduce the number of items in the fort by "atom-smashing" them under a bridge or donating them away to traders. Alternatively, less digging in the first place results in fewer stones and corridors in the world to consider.
- It will sometimes be mentioned is that since DF is single-threaded, followed by some-suggestion-or-other based on this assertion. This is no longer quite true. It is true that the vast majority of the work still takes place in a single thread, and Toady has no plans to ever multithread the game logic, but DF does have at least one other thread handling the SDL graphics. This means that (all else being equal) DF should run faster on 2 cores than on 1, but won't run faster on 3 cores than it did on 2.
Be cautious of any FPS-increasing suggestions that still assume the game is completely single-threaded.
Success Stories
Losing is Fun! But there's nothing fun about abandoning your fortress because the framerate has dropped to 6. For many, more fortresses are lost to fps death than anything else, and improving framerate remains a something of a mystery. If you find something that works, please share it here.
From 40fps to 140fps
pc: 2.2ghz 1.5gb ram. fortress: 2x2 embark, 40-50 dwarves, 130 animals. temp & weather off. 1 cavern
This fort ran at 150fps for a while but gradually after 11 years slowed to 27. At this point I've focused my efforts exclusively on maximizing framerate, trying the usual tricks:
- Atom-smashing: no help AT ALL.
- Animal slaughtering / caging: gained 10-15fps for killing about 50 animals.
- Then I notice that my dwarves are FILTHY! Some having over 10+ pages of various blood and pus spatterings in their inventories.
I dig a crude bath, which consists of a hallway which dips down into a brief channel and back up before hitting a dead end. I designate a Pond zone over the channel and the dwarves waste no time in drawing a bath (1/7 deep). After designating a burrow on the other side of the bath, I order the entire fortress to it via the Alerts screen (restricting them to that burrow). Immediately upon crossing the channel my framerate went from ~40 to ~140 and it is decided the fortress will live on!
Conclusion: The amount of items on the map and pathfinding were very minor causes of slowdown in my case. The increases gained from slaughtering animals may well have been from their contaminants being destroyed in the process rather than the pathing they were calculating. Above all, the contaminants were the cause of this fortresses near-demise. --Uninvited Guest 07:27, 1 December 2010 (UTC)