v50 Steam/Premium information for editors
- 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.
This notice may be cached—the current version can be found here.
Editing Maximizing framerate
Jump to navigation
Jump to search
Warning: You are not logged in.
Your IP address will be recorded in this page's edit history.
If you are creating a redirect to the current version's page, do not use any namespace. For example: use #REDIRECT [[Cat]], not #REDIRECT [[Main:Cat]] or #REDIRECT [[cv:Cat]]. See DF:Versions for more information.
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
− | + | {{Quality|Exceptional|12:48, 18 May 2015 (UTC)}} | |
− | {{Quality| | ||
{{av}} | {{av}} | ||
[[File:Frames_Per_Second_Meter.png|300px|thumb|bottom|A picture of ''Dwarf Fortress'' with frames per second displayed.]] | [[File:Frames_Per_Second_Meter.png|300px|thumb|bottom|A picture of ''Dwarf Fortress'' with frames per second displayed.]] | ||
− | [[Frames per second|Framerate]] is used in ''Dwarf Fortress'' to measure the speed at which the game is running. It is measured in "frames per second", or FPS for short. To check your FPS in-game, | + | [[Frames per second|Framerate]] is used in ''Dwarf Fortress'' to measure the speed at which the game is running. It is measured in "frames per second", or FPS for short. To check your FPS in-game, simply change [FPS:NO] to [FPS:YES] in [[init.txt]], 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 parentheses is the current graphical frame refresh rate. |
==Increasing your framerate== | ==Increasing your framerate== | ||
− | In general, the more stuff the game has to keep track of, the slower the game will run. So, reducing the amount of stuff that's active keeps your game running fast | + | In general, the more stuff the game has to keep track of, the slower the game will run. So, reducing the amount of stuff that's active keeps your game running fast. The lists below separate ways to improve FPS into two categories: things that don't change the game in any fundamental way, and things that do. |
+ | |||
+ | ===Displaying the map=== | ||
+ | |||
+ | Displaying a map tile takes a varying amount of work depending on what it is: | ||
+ | |||
+ | * Unrevealed tiles take almost no time at all - it just needs to look up what "random glyph" to display there | ||
+ | * Layer stone tiles need to take the biome number and layer number and look up the layer material, then look up the inorganic raw object to get the symbol/color | ||
+ | * Lava stone tiles need to take the biome number and look up some region information to determine what lava-stone to use, then continue as above | ||
+ | * Feature stone tiles (i.e. adamantine) need to look up the map feature located within the tile to figure out what it's made of, then continue as above | ||
+ | * Vein stone tiles need to do a linear lookup within a list specific to the 16x16x1 map block to see which vein they match and determine the material, then continue as above | ||
+ | * Grass tiles need to do a linear lookup within that same list to figure out what type of grass is present, then look up the plant raw object to get the symbol/color (and also account for animations) | ||
+ | * Shrubs and saplings need to search a separate list (not sure if it's the global list or a column-specific one) to find the plant in question and determine its symbol/color | ||
+ | * Trees need to do a linear search through a column-specific list (one list per 48x48 tile embark region block) to determine what growths are present in the tile and look up within the plant itself to get the symbol/color | ||
+ | * Constructed tiles need to do a binary search by X/Y/Z coordinates in a separate list to determine what material it uses, then look up that material for the symbol/color | ||
+ | * On top of all of that, it does a binary search by X/Y/Z coordinates in yet another list to determine whether or not an engraving is present (and, if there is, what tile to display) | ||
+ | * Other tile contents (units, buildings, items, vermin, etc.) get displayed | ||
+ | * After all of that is done, it then does yet another linear search (though the same list as with vein stones and grass) to see if the tile has a spatter on it (e.g. mud, blood, vomit, or leaves) and adjust the symbol/color accordingly | ||
===Without Game Alterations=== | ===Without Game Alterations=== | ||
Line 14: | Line 30: | ||
====World Generation==== | ====World Generation==== | ||
− | * Larger worlds require more background processing to update. The larger the civilizations, the more events occur in the world and the more complex they are. Generating too-large civilized populations can result in a permanent, unavoidable FPS drop | + | * Larger worlds require more background processing to update. The larger the civilizations, the more events occur in the world and the more complex they are. Generating too-large civilized populations can result in a permanent, unavoidable FPS drop. |
* Longer histories require more memory and storage space for [[historical figure]]s and events. | * Longer histories require more memory and storage space for [[historical figure]]s and events. | ||
* Reducing the number of civilizations, sites, beasts, and setting world population cap can limit the resources spent updating the rest of the world. | * Reducing the number of civilizations, sites, beasts, and setting world population cap can limit the resources spent updating the rest of the world. | ||
− | * [[Caverns]] can be an FPS hog due to | + | * [[Caverns]] can be an FPS hog due to [[pathfinding]] and how complex they can be. Creatures will repeatedly try to path into your fort from a cavern. Sometimes even [[Trading#Caravans|trading caravans]] will try to path out of your fort underground. |
** Adjusting the [[Advanced_world_generation#Cavern_Layer_Number|cavern layer number]] in [[advanced world generation]] parameters can reduce the number of [[cavern]] layers (default 3). However, this will restrict access to subterranean plants and creatures, and reduce the number of spawned [[forgotten beast]]s. | ** Adjusting the [[Advanced_world_generation#Cavern_Layer_Number|cavern layer number]] in [[advanced world generation]] parameters can reduce the number of [[cavern]] layers (default 3). However, this will restrict access to subterranean plants and creatures, and reduce the number of spawned [[forgotten beast]]s. | ||
− | ** Similarly, one could adjust [[Advanced_world_generation#Layer_Openness_Min.2FMax|Layer Openness]] and [[Advanced_world_generation#Layer_Passage_Density_Min.2FMax|Layer Passage Density]] in [[advanced world generation]] to | + | ** Similarly, one could adjust [[Advanced_world_generation#Layer_Openness_Min.2FMax|Layer Openness]] and [[Advanced_world_generation#Layer_Passage_Density_Min.2FMax|Layer Passage Density]] in [[advanced world generation]] to turn caverns into wide, open expanses instead of complex mazes that have to be pathed through. However, there is some evidence that excessively open caverns cause performance issues as well.[http://www.bay12forums.com/smf/index.php?topic=104643.msg3096896#msg3096896] |
− | |||
− | |||
====Fortress Design==== | ====Fortress Design==== | ||
* Larger embark sites dramatically increase the amount of terrain which DF needs to keep track of and path through. | * Larger embark sites dramatically increase the amount of terrain which DF needs to keep track of and path through. | ||
− | ** Reducing the size of your embark site from the default | + | ** Reducing the size of your embark site from the default 4x4 squares to 3×3 or even 2×2 will have an enormous impact on FPS. |
** Keep in mind that a 2×2 embark is only 25% of the size of a 4×4 embark. However, in 3D it is still a large enough area for many fortresses in normal play. | ** Keep in mind that a 2×2 embark is only 25% of the size of a 4×4 embark. However, in 3D it is still a large enough area for many fortresses in normal play. | ||
− | * | + | * Multi-tile trees are a potential source of lag. |
− | ** | + | ** Choosing an embark location that only grows trees on one or two squares can improve performance. |
− | |||
− | |||
− | * Fewer items inside a fort means fewer items checked for | + | * Fewer items inside a fort means fewer items to be [[stockpile]]d, checked for [[wear]], and so on and so forth. |
** The obvious solution is not to generate so many items in the first place. Don't build such large [[Farming|farm plot]]s and don't go overboard with multiple [[Workshop|workshops]] constantly queued or set on perpetual repeat. | ** The obvious solution is not to generate so many items in the first place. Don't build such large [[Farming|farm plot]]s and don't go overboard with multiple [[Workshop|workshops]] constantly queued or set on perpetual repeat. | ||
− | ** Use a [[Dwarven | + | ** Checking for clothing [[wear]] and unhappy [[thoughts]] could still have some impact on FPS. (Research is needed.) Armor counts for missing clothing thoughts, so dwarves can wear armor instead of clothes or going naked. If nothing else, dumping excess/worn out clothing may help FPS on an old fortress. |
− | ** [[Exploit#Quantum_stockpiles|Quantum stockpiles]] | + | ** Use a [[Dwarven Atom Smasher]] to remove items, or donate them to [[Trading|passing caravans]] to be taken away. |
+ | ** [[Exploit#Quantum_stockpiles|Quantum stockpiles]] can [http://www.bay12forums.com/smf/index.php?topic=92241.msg3276117#msg3276117 reportedly] improve game speed. | ||
** The quantity of items in any particular stack doesn't affect framerate so much as the number of stacks in general, due to the resultant impact on [[hauling]], [[stockpiles]], [[pathfinding]] and other CPU-intensive tasks. The research done on the [http://www.bay12forums.com/smf/index.php?topic=92241.0 Undump Engine] and [http://www.bay12forums.com/smf/index.php?topic=109319.0 Micha's experimental fort] demonstrate very FPS efficient solutions, while avoiding traditional stockpiles and the use of [[barrel]]s and [[bin]]s. | ** The quantity of items in any particular stack doesn't affect framerate so much as the number of stacks in general, due to the resultant impact on [[hauling]], [[stockpiles]], [[pathfinding]] and other CPU-intensive tasks. The research done on the [http://www.bay12forums.com/smf/index.php?topic=92241.0 Undump Engine] and [http://www.bay12forums.com/smf/index.php?topic=109319.0 Micha's experimental fort] demonstrate very FPS efficient solutions, while avoiding traditional stockpiles and the use of [[barrel]]s and [[bin]]s. | ||
− | ** That said, [http://www.bay12forums.com/smf/index.php?topic=104643.msg3094753#msg3094753 total quantity of items does matter]. Quantity matters far more with objects that have quality or decorations than boulders, as they take up more memory. | + | ** That said, [http://www.bay12forums.com/smf/index.php?topic=104643.msg3094753#msg3094753 total quantity of items does matter]. Quantity matters far more with objects that have quality, wear, or decorations than boulders, as they take up more memory. Even in quantum stockpiles, temperature checks, wear increments, and other issues lag the game, although it takes far larger item quantities (10,000+) to be seriously notable. |
+ | * Flowing [[water]] slows the game down. | ||
+ | ** Don't build [[mist]] generators, [[Screw pump|pump stacks]], or other major water-moving projects. If you do build them, build a [[Lever|way to switch them off]]. | ||
+ | ** Don't embark on a [[river]] or [[ocean]]. Rivers aren't too bad in their natural state, because the game only needs to calculate at where the water enters and where the water leaves, more-or-less skipping the water in between. Then you start damming them and pumping water out, and it gets worse. | ||
+ | ** [[Aquifer]]s don't impose load until you start digging around in them. | ||
+ | ** [[Water wheel#Perpetual motion|Dwarven water reactors]] also slow down the game, often significantly. | ||
+ | ** Wall off areas with changing water levels[http://www.bay12games.com/dwarves/mantisbt/view.php?id=5986#c22870]. This prevents the game from needing to update pathfinding information whenever the water level changes and is safer anyway. | ||
* Changes to the map's connections can cause brief lag spikes as the game's connections map needs updating. | * Changes to the map's connections can cause brief lag spikes as the game's connections map needs updating. | ||
** This is most notable with doors, drawbridges, or other objects linked to a [[repeater]]. An atom-smasher linked to a repeater, even disconnected from the rest of the fortress, can cause lag spikes every time it is raised or lowered. If you use an atom-smasher to eliminate garbage, make it operate only very infrequently through mechanics, or operate it manually by [[lever]]. | ** This is most notable with doors, drawbridges, or other objects linked to a [[repeater]]. An atom-smasher linked to a repeater, even disconnected from the rest of the fortress, can cause lag spikes every time it is raised or lowered. If you use an atom-smasher to eliminate garbage, make it operate only very infrequently through mechanics, or operate it manually by [[lever]]. | ||
− | |||
* Proper use of [[traffic]] designations will help. | * Proper use of [[traffic]] designations will help. | ||
− | |||
** Setting corridors to "high" traffic, and dead-end workshop rooms next to them to "low" traffic, means the pathfinder algorithm will search more quickly along the corridor, and waste less time searching in the rooms. | ** Setting corridors to "high" traffic, and dead-end workshop rooms next to them to "low" traffic, means the pathfinder algorithm will search more quickly along the corridor, and waste less time searching in the rooms. | ||
− | * | + | ** Changing the normal traffic weight to 1 in d_init.txt will optimize the pathfinder at the cost of High traffic zones not making a difference ([http://www.bay12forums.com/smf/index.php?topic=97763.msg2841109#msg2841109 source]) |
+ | * Reducing the area which the pathfinder algorithm has to search lets the game run faster. | ||
** The obvious solution is to not dig out quite so much of the ground. | ** The obvious solution is to not dig out quite so much of the ground. | ||
** Some careful fort planning and design can cut down on pathfinding with shorter trips. | ** Some careful fort planning and design can cut down on pathfinding with shorter trips. | ||
Line 57: | Line 75: | ||
** Caverns are probably the worst offender for pathfinding in irrelevant areas. So keep any part you aren't occupying closed off. | ** Caverns are probably the worst offender for pathfinding in irrelevant areas. So keep any part you aren't occupying closed off. | ||
** Don't designate large areas to be smoothed at once.{{bugl|5986}} | ** Don't designate large areas to be smoothed at once.{{bugl|5986}} | ||
− | ** Trapped dwarves, particularly trapped [[mood]]y dwarves cause significant lag at times. | + | ** Trapped dwarves, particularly trapped [[mood]]y dwarves cause significant lag at times. There is a bug where a trapped dwarf with a [[strange mood]] will slow the game down tremendously. {{bug|8698}} Free them of bondage or life to get on with your own. |
** [[Location]]s without sufficient floor space invite frequent pathing. Make sure your locations are large enough for your population. | ** [[Location]]s without sufficient floor space invite frequent pathing. Make sure your locations are large enough for your population. | ||
− | * Each animal needs to | + | * Each animal needs to pathfind, too. |
− | ** Tame animals can be put into [[cage]]s, | + | ** Tame animals can be put into [[cage]]s, keeping them from having anywhere to go. Or you can butcher them. |
− | * | + | ** Avoid pet-impassable doors; animals will stand at the door and continuously path through it.{{bug|797}} |
− | |||
* [[DF2012:Contaminant|Contaminants]] can accumulate on the ground and on dwarves and creatures. Especially for old forts, this can impact FPS. There is a bug ({{bug|296}}) which makes contaminants continuously multiply and another ({{bug|3270}}) which prevents blood from ever disappearing. | * [[DF2012:Contaminant|Contaminants]] can accumulate on the ground and on dwarves and creatures. Especially for old forts, this can impact FPS. There is a bug ({{bug|296}}) which makes contaminants continuously multiply and another ({{bug|3270}}) which prevents blood from ever disappearing. | ||
** If the contaminants are outside, isolate the area and let [[DF2012:Weather|rain]] slowly wash it away. Pets can be kept out with a [[Activity_zone#Pen.2FPasture|pen/pasture]] or a [[Activity_zone#Pit.2FPond|pit]]. Similarly, setting the [[traffic]] designation to restricted and/or assigning [[Activity_zone|Activity Zones]] strategically may keep dwarves away. | ** If the contaminants are outside, isolate the area and let [[DF2012:Weather|rain]] slowly wash it away. Pets can be kept out with a [[Activity_zone#Pen.2FPasture|pen/pasture]] or a [[Activity_zone#Pit.2FPond|pit]]. Similarly, setting the [[traffic]] designation to restricted and/or assigning [[Activity_zone|Activity Zones]] strategically may keep dwarves away. | ||
− | ** Add in some in-fortress means of cleaning dwarves and pets. | + | ** Add in some in-fortress means of cleaning dwarves and pets. The [[User:Uristocrat/Dwarven_Bathtub|Dwarven Bathtub]] is one example. And make sure you have the [[cleaning]] labor enabled. Details of these and other suggestions can be found on the [[cleaning]] page. |
* Encountering [[HFS]] will dramatically reduce FPS AFTER you seal the breach ({{bug|1340}}). Either avoid doing so or use the work around posted in the bug report. | * Encountering [[HFS]] will dramatically reduce FPS AFTER you seal the breach ({{bug|1340}}). Either avoid doing so or use the work around posted in the bug report. | ||
* Heavy construction, especially megaprojects, will cause increasingly severe input lag as the fortress grows. Forbid materials (especially stones, blocks, and bars) as much as possible to reduce the time the game needs to calculate the list of available materials to build constructions with. | * Heavy construction, especially megaprojects, will cause increasingly severe input lag as the fortress grows. Forbid materials (especially stones, blocks, and bars) as much as possible to reduce the time the game needs to calculate the list of available materials to build constructions with. | ||
+ | * Training your military can cause lag, mostly due to sparring. Try to avoid training more than one or two squads at a time. | ||
* When a team comes back from a raid/mission, a huge lag can appear suddenly (down to 5 fps). You can disband the squad and situation should come back to normal. | * When a team comes back from a raid/mission, a huge lag can appear suddenly (down to 5 fps). You can disband the squad and situation should come back to normal. | ||
* The same can happen when sending a squad out for a mission. If squad members are somehow locked inside, they will continuously try to find a path to the mission and the game can grind to a near halt. | * The same can happen when sending a squad out for a mission. If squad members are somehow locked inside, they will continuously try to find a path to the mission and the game can grind to a near halt. | ||
− | * | + | * Use as few engravings as possible. |
+ | * Keep your map clean of contaminants. The DFHack "clean map" command works well for this, though some may consider it cheaty. | ||
* Minimize the number of living plants. This will not endear you to the Elves. | * Minimize the number of living plants. This will not endear you to the Elves. | ||
− | * Avoid looking at complicated areas. | + | * Avoid looking at complicated areas. |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
====Game Settings==== | ====Game Settings==== | ||
* G_FPS is a setting in the [[init.txt]] file. It controls how often Dwarf Fortress redraws the screen. It also controls how often the game checks for keyboard or mouse input. | * G_FPS is a setting in the [[init.txt]] file. It controls how often Dwarf Fortress redraws the screen. It also controls how often the game checks for keyboard or mouse input. | ||
− | ** Reducing G_FPS | + | ** Reducing G_FPS can speed up the rest of the game. The default choice of 50 works well, but many people reduce it down to 20 with no ill effect. |
+ | ** Reducing G_FPS too far can make the game unresponsive and glitchy. Some people can cope with 5; most cannot. | ||
+ | * PRINT_MODE is another init setting. It controls the method Dwarf Fortress uses to draw the screen. | ||
+ | ** More advanced methods allow DF to make more use of OpenGL features and therefore your graphics card. STANDARD and VBO are good starting points. | ||
+ | ** More advanced methods may still have bugs. 2D is more likely to be reliable. | ||
+ | * Using creature graphics may reduce FPS. (Using a custom ASCII tileset should have no effect) | ||
+ | *PRIORITY represents how much importance the game is given when it makes a request of the CPU. From [[init.txt]]: | ||
+ | **"Change this to make the dwarfort.exe process have a different priority. From highest to lowest, the options are REALTIME, HIGH, ABOVE_NORMAL, NORMAL, BELOW_NORMAL and IDLE." | ||
+ | **While it's best to run DF with no other programs in the background if FPS is an issue, giving the priority a bump or two can help speed things up regardless. | ||
+ | *TEXTURE_PARAM controls how the graphics are displayed, specifically how the color value of each pixel is smoothed. It is LINEAR by default. Turning this off gives the CPU one less thing to do, though the improvement in performance is so far unquantified. | ||
+ | **From [[init.txt]]: "Change this to NEAREST if you want the texture values to use the nearest pixel without averaging. Change this to LINEAR if you want the texture values to be averaged over the adjacent pixels." | ||
===With Game Alterations=== | ===With Game Alterations=== | ||
Line 94: | Line 111: | ||
====Game Settings==== | ====Game Settings==== | ||
+ | * Consider running an older version of DF. While lacking features, 40d, v0.31, or v0.34 ''may'' run faster than 2014. *Disputed* (See [http://www.bay12forums.com/smf/index.php?topic=122441.0 this topic] for a debate over FPS on 2012 vs v0.31, game settings, and other FPS issues.) | ||
* [[Temperature]] calculations place a significant load on the processor. | * [[Temperature]] calculations place a significant load on the processor. | ||
− | ** Disabling them will speed things up | + | ** Disabling them, using the settings in d_init.txt, will speed things up. |
** Without temperature calculations, [[obsidian farming]] becomes unusable; as the tiles never cool down, dwarves refuse to step on the obsidian floor, preventing access for hauling dwarves.{{bug|6033}} You can re-enable temperature occasionally to allow tile temperatures to normalize. Alternatively, you can work around this issue by altering obsidian in the raws to give it [MAT_FIXED_TEMP:10000] (as [[nether-cap]] does normally), preventing it from being hot. | ** Without temperature calculations, [[obsidian farming]] becomes unusable; as the tiles never cool down, dwarves refuse to step on the obsidian floor, preventing access for hauling dwarves.{{bug|6033}} You can re-enable temperature occasionally to allow tile temperatures to normalize. Alternatively, you can work around this issue by altering obsidian in the raws to give it [MAT_FIXED_TEMP:10000] (as [[nether-cap]] does normally), preventing it from being hot. | ||
** Disabling temperature calculations will cause [[fire]] to become glitchy, including creatures who can create it ([[fire imp]]s, [[dragon]]s, [[forgotten beast]]s, etc). Dwarves set on fire with temperature disabled will burn perpetually until exposed to water, though they won't receive any damage. Tiles exposed to fire with temperature calculations disabled will become entirely impassable, which may lead to significant parts of your map being blocked away. If confronted by fire or fire-based creatures, it may be worth turning temperature back on until they're dealt with. | ** Disabling temperature calculations will cause [[fire]] to become glitchy, including creatures who can create it ([[fire imp]]s, [[dragon]]s, [[forgotten beast]]s, etc). Dwarves set on fire with temperature disabled will burn perpetually until exposed to water, though they won't receive any damage. Tiles exposed to fire with temperature calculations disabled will become entirely impassable, which may lead to significant parts of your map being blocked away. If confronted by fire or fire-based creatures, it may be worth turning temperature back on until they're dealt with. | ||
** Multiple users have reported an FPS increase of 100% or better when disabling temperature calculations [http://www.bay12forums.com/smf/index.php?topic=86761.msg2352509#msg2352509]. | ** Multiple users have reported an FPS increase of 100% or better when disabling temperature calculations [http://www.bay12forums.com/smf/index.php?topic=86761.msg2352509#msg2352509]. | ||
− | * Disabling [[weather]] | + | * Disabling [[weather]] ''might'' speed things up as well, but then rain won't refill [[murky pool]]s, clean contaminants, kill dwarves, etc. |
− | * Each dwarf | + | * Each dwarf needs to keep track of where they're going. |
** Limit the number of dwarves by setting a [[immigration|population cap]]. | ** Limit the number of dwarves by setting a [[immigration|population cap]]. | ||
− | * | + | * Invaders also need to pathfind. |
− | ** | + | ** Turn off invasions using the option in [[D_init.txt]]. Or you can kill them all. |
* The game also has to track what is happening in the caverns. | * The game also has to track what is happening in the caverns. | ||
** You can disable cavern layers in [[advanced world generation]]. Without caverns, you will have far fewer critters and threats pathfinding through winding passages. Unfortunately, you also lose underground [[plant]]s and [[tree]]s. Alternatively, you can reduce the number of cavern layers to just one. | ** You can disable cavern layers in [[advanced world generation]]. Without caverns, you will have far fewer critters and threats pathfinding through winding passages. Unfortunately, you also lose underground [[plant]]s and [[tree]]s. Alternatively, you can reduce the number of cavern layers to just one. | ||
Line 113: | Line 131: | ||
* Constantly-growing piles of cast-off clothes and checking for clothing [[wear]] and unhappy [[thoughts]] can impact FPS. | * Constantly-growing piles of cast-off clothes and checking for clothing [[wear]] and unhappy [[thoughts]] can impact FPS. | ||
− | ** One could [[Modding_guide|modify]] clothing to prevent [[wear]]. This can be done by adding an [[DF2012:Armor_token|ARMORLEVEL:1]] token. Aside from a possible FPS gain, this has other benefits as well. This fix is part of the [[DF2012:List_of_mods#Modest_Mod|Modest Mod]] as an optional "Eternal Fashion module". It might also be found in other mods which are based around Modest Mod. (Search the [http://dffd.wimbli.com/ DFFD] for "Modest".) Also, [[DF2012:List_of_mods#Masterwork_Dwarf_Fortress_.28MDF.29|Masterwork Dwarf Fortress]] allows the creation of metal clothing. | + | ** One could [[Modding_guide|modify]] clothing to prevent [[wear]]. (This would require a [[DF2012:World_generation|world regen]].) This can be done by adding an [[DF2012:Armor_token|ARMORLEVEL:1]] token. Aside from a possible FPS gain, this has other benefits as well. This fix is part of the [[DF2012:List_of_mods#Modest_Mod|Modest Mod]] as an optional "Eternal Fashion module". It might also be found in other mods which are based around Modest Mod. (Search the [http://dffd.wimbli.com/ DFFD] for "Modest".) Also, [[DF2012:List_of_mods#Masterwork_Dwarf_Fortress_.28MDF.29|Masterwork Dwarf Fortress]] allows the creation of metal clothing. |
+ | |||
+ | * Some mods have been created specifically to improve performance. They often reduce and standardize materials (like leather and bone) and may reduce the types of clothing available to control item count (especially for invaders). | ||
+ | ** [http://www.bay12forums.com/smf/index.php?topic=117954.0 Accelerated Dwarf Fortress] for v0.34.11 | ||
+ | ** [http://www.bay12forums.com/smf/index.php?topic=141715.0 Modest Accelerated Mash] for v0.40.x | ||
+ | ** [http://www.bay12forums.com/smf/index.php?topic=148265.0 Modest Mod] for v0.42.x has the Accelerated module | ||
==DFHack commands== | ==DFHack commands== | ||
Line 124: | Line 147: | ||
*{{DFtext|tweak fast-heat|white}} Further improves temperature update performance. | *{{DFtext|tweak fast-heat|white}} Further improves temperature update performance. | ||
− | |||
− | |||
*{{DFtext|fastdwarf|white}} Causes dwarves and other creatures to move and work faster or causes them to teleport. Run {{DFtext|fastdwarf help|white}} for more information. | *{{DFtext|fastdwarf|white}} Causes dwarves and other creatures to move and work faster or causes them to teleport. Run {{DFtext|fastdwarf help|white}} for more information. | ||
Line 139: | Line 160: | ||
If you run any indexing, exclude DF directory. | If you run any indexing, exclude DF directory. | ||
− | Installing | + | Installing libjemalloc using your distro's package manager and writing a bash script to preload it and run ''Dwarf Fortress'' may result in improved framerates: |
<nowiki>#!/bin/sh | <nowiki>#!/bin/sh | ||
− | + | cd /path/to/df_linux | |
− | cd | + | LD_PRELOAD="/usr/lib/x86_64-linux-gnu/libjemalloc.so.1" ./df</nowiki> |
− | |||
− | |||
− | |||
==Mac OS X or GNU/Linux Specific== | ==Mac OS X or GNU/Linux Specific== | ||
===Setting process niceness=== | ===Setting process niceness=== | ||
− | One thing that Unix-like systems feature is being able to control the priority of a process in relation to other processes running at the same time. This is its "niceness" value, with -20 being most favorable to the process. | + | One thing that Unix-like systems feature is being able to control the priority of a process in relation to other processes running at the same time. This is its "niceness" value, with -20 being most favorable to the process. To set Dwarf Fortress's niceness, you can use the "renice" command as so: |
<nowiki>sudo renice -n -20 -p $(pgrep Dwarf_Fortress)</nowiki> | <nowiki>sudo renice -n -20 -p $(pgrep Dwarf_Fortress)</nowiki> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | This command should work in most distributions of GNU/Linux. For macOS (whose Dwarf Fortress binary uses Windows' naming convention for some reason), use: | |
<nowiki>sudo renice -n -20 -p $(pgrep dwarfort.exe)</nowiki> | <nowiki>sudo renice -n -20 -p $(pgrep dwarfort.exe)</nowiki> |