Editing v0.31 Talk:Maximizing framerate

==World Gen editing to speed Fortress Mode==

On an old slow computer, I have found that editing the world_gen.txt file in the date/init folder to help:

 [CAVERN_LAYER_COUNT:3] - reduce for fewer cavern layers, so less fun, but more speed.
 [CAVERN_LAYER_OPENNESS_MIN:0]
 [CAVERN_LAYER_OPENNESS_MAX:20] not entirely sure what these do, but these were the figures when I stopped testing.
 [CAVERN_LAYER_PASSAGE_DENSITY_MIN:0]
 [CAVERN_LAYER_PASSAGE_DENSITY_MAX:0] restricts the density of passages, at these figures the caves are not filled with tiny passages

Since I haven't tested exhaustively I don't feel this should be on the front page yet. - JimiD

==More World Gen editing to speed Fortress Mode==

I did some similar testing but instead of changing the number of cavern layers I changed the size of the caverns themselves.  The defaults are '''Minimum Natural Cave Size 5, Maximum Natural Cave Size 25'''.  I lowered these to 4 and 12 and ended up with a map with less than 40 z levels below ground.  This significantly improved performance, load and save time without sacrificing the cave features.  In fact it's a little funner since I don't have to travel so far to get to magma.  Currently I'm running close to 50 dwarves and I'm noticing almost no hiccups or drop in frame rate(from 100).

I have only tested this on one map and each cavern layer has exactly 5 z levels each which is odd.  More testing needs to be done to get exact figures but it does seem to be an excellent alternative to lowering the number of caves or the size of embark.  Using this method, increasing the embark size isn't out of the question. 

I tested this map on my 1.6GHZ EeePC Netbook and got a reliable framerate of 34, which is quite playable. - Lemunde
::maybe you are confusing rare '''natural caves''' (familiar from 40d version, home to megabeasts, see worldgen-exported sites_and_pops.txt) with the new Cavern Layers which are guaranteed under every embark area. (.31.12) --[[User:TomiTapio|TomiTapio]] 00:49, 26 July 2010 (UTC)

==Importance of Speedup==

I think this is a really important feature which should have a high priority. Maybe this page can get some special attention on the front page along with other pages with high priority?
A lot of people just don't play anymore with all of the graphics problems in this version, which is sad.

Another possibility here is for an explanation of the various init.txt settings, they can really change a LOT in your performance. - Nether
:: try a 3x2 embark. --[[User:TomiTapio|TomiTapio]] 00:49, 26 July 2010 (UTC)

==Obsolete for the current version in italic==

I have changed the parts where it is explained that the action is obsolete for the current version into italic font. I believe that this is a minor change which makes the page a lot easier to read. 
- Nether

==How true is any of this?==
I've applied the various recommendations given here and noticed absolutely no speedup.  Getting rid of thousands of items by atom smashing or gifting to merchants? Nothing. Caging and uncaging fifty animals? Nothing. Blocking off the outside, or the cavern levels, with a locked door, a bridge, a floodgate, a channel? Nothing. Turning off my indoor waterfall was the only thing that seemed to help, getting me about 8FPS extra, from 25 to 33FPS with 105 dorfs. [[User:GhostDwemer|GhostDwemer]] 20:34, 10 November 2010 (UTC)

== PRINT_MODE: TEXT ==

Changing PRINT_MODE to TEXT increases my framerate to max (linux). Certain keypresses are however not noticed in terminal, such as shift + arrow key as well as the function keys.
--[[User:Questionmark|Questionmark]] 21:03, 27 November 2010 (UTC)
:PRINT_MODE: TEXT (vs 2D) made zero difference for me on Linux (Ubuntu 10.04) [[Special:Contributions/202.156.10.234|202.156.10.234]] 13:08, 14 December 2010 (UTC)
@@ Line 41: / Line 41: @@
 --[[User:Questionmark|Questionmark]] 21:03, 27 November 2010 (UTC)
 :PRINT_MODE: TEXT (vs 2D) made zero difference for me on Linux (Ubuntu 10.04) [[Special:Contributions/202.156.10.234|202.156.10.234]] 13:08, 14 December 2010 (UTC)
-== 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 [[Contaminant|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. --[[User:Uninvited Guest|Uninvited Guest]] 07:27, 1 December 2010 (UTC)
-===From 11fps to 24fps===
-''pc: 2.1ghz 2gb ram. fortress: 2x2 embark (i think), 110 dwarves, 100 animals.''
-As this was my first playthough, I didnt noticed any strange (only that the game was designed to be a bit too low) until I read somewhere about the framerate problems, so I activated mine to show them and saw i was at 11 fps!
-I found this guide, and followed the previous case example, I skipped killing animals, or smashing objects, and when straight for the dwarf-wash.
-I downloaded DFHacks (http://www.bay12forums.com/smf/index.php?topic=58809) and made some 7 high water blocks on some chocke points. After unpausing, the whole place was full of mud and blood, so used the dfcleanmap on the same utility pack to make then dissapear.
-My FPS went straight to 24 fps; Basically I now see everything x2 the speed i was used to see!
-BTW, be carefull with this method, I killed 3 dogs by accident as they smashed on other objects (tidal force I guess) and the 3 of them were pets of my main warrior, who is very angry now! I fear a lot of fun is comming xD
-'''Conclusion''': I did not tried any of the other methods, so I cant say they dont work, but I can say, that the filthiness of the dwarf population have a HUGE impact on FPS.
-'''Krelian'''
-===From 11fps to 32fps===
-Started looking into why my fort had suddenly slowed down from thirty to almost less than ten fps and looking through here I found that a while ago I had un-penned a lot of animals and most of them had accidentally gotten some blood covering on themselves. Using dfliquids to create a 2/7 of water on top of all animals and after stepping forward three or four frames ran the dfcleanmap to clean the resulting blood pools instantly raised fps to almost three-times of what it was.
-'''Conclusion''': (To mimic Krelian) The filthiness of any part of your creature population has a HUGE impact on fps.
---[[User:Egodeus|Egodeus]] 16:09, 1 June 2011 (UTC)
-Whoops. Apparently I had forgotten one dorf to pull a lever on repeat. As it was connected to eleven doors, this caused quite a lot of lag as each caused changes in the pathing and blah. Totally forgot to turn that of. Whoopdidah. Cleaning still helped a lot. --[[User:Egodeus|Egodeus]] 16:31, 1 June 2011 (UTC)
-== Running water ==
-Nice work by DeMatt in tidying up this page.
-Is there any reason running water isn't mentioned?  I was under the impression brooks and rivers were big FPS killers, at least in previous versions.  Perhaps a sentence about having an off switch for any mist generators, too?
-[[User:Bognor|Bognor]] 14:39, 4 January 2011 (UTC)
-:Short answer - I forgot.  So did Gzalzi.  So me using his revamp as a reference for my revamp missed it.  I'll go put a note in.  If it's something that is pretty much inarguable, feel free to add your own points;  take care to explain it clearly.  --[[User:DeMatt|DeMatt]] 19:19, 4 January 2011 (UTC)
-::Yeah, I pretty much just edited the information that was already on the page to make it sound better, rather than adding anything else to it. --[[User:Gzalzi|Gzalzi]] 20:04, 4 January 2011 (UTC)
-Cool, that was what I'd guessed... Glad it's in now.  Copyeditors/Wiki-gnomes are valuable creatures.  [[User:Bognor|Bognor]] 13:38, 5 January 2011 (UTC)
-== D_init.txt Option: WALKING_SPREADS_SPATTER ==
-On [[v0.31:Release_information/0.31.16]] the following is listed under "New stuff":
-<blockquote>
-* added spatter init options (dwarf mode defaults to no walking spread of spatter)
-</blockquote>
-However, on the [[v0.31:Maximizing framerate]] page, under "Contaminants", it mentions these D_init options and immediately following it says "(as of&nbsp;{{version|0.31.18}})". This implies that said options were first introduced with&nbsp;{{version|0.31.18}}, which seems to be untrue. Further, it completely fails to mention what these D_init options are called.
-As such, I am editing the page to be more accurate and specific. --[[User:Thundercraft|Thundercraft]] 08:27, 19 February 2011 (UTC)
-== Setting "normal" pathing cost to 1 ==
-I've noticed this inclusion has been controversial in the past (I am not the person who included it or earlier removed it). I checked the reference, and I believe that Urist Da Vinci is correct. The way to understand this is that the A* pathing algorithm is guaranteed to produce the shortest path. This means it must eliminate alternative possibilities, by searching them also.
-Imagine a simple setup like this, or create it in game. The blank spaces (.'s) are normal pathing cost, the H are high pathing areas, the dwarf is travelling from A to B.
-<code>
-<nowiki>##############################</nowiki><br />
-<nowiki>A............................B</nowiki><br />
-<nowiki>##.########################.##</nowiki><br />
-<nowiki>.#.....HHHHHHHHHHHHHHHH.....#</nowiki><br />
-<nowiki>.############################</nowiki><br />
-</code>
-If you test this, you note that the game does find "long cut" and the dwarves take it, avoiding the short cut. The pathfinder thus explores both branches to discover which is shorter. But when the pathing cost is all 1's, it can just search "as the crow flies", find the destination, and be confident that it has found the shortest route. It *can't* do that if the tiles it is searching are cost 2, because there might always be an alternative route containing some cost 1 tiles. Thus it needs to search much further and wider to preclude the possibility of alternative, shorter, routes.
-I'm actually not convinced there would ever be a benefit in using the default settings / high pathing areas. Perhaps it would help the pathfinder to locate stairwells and such, but I have my doubts. Perhaps it would be good if someone was to test fiddling around with things in a large, complicated fortress with many dwarves, and see what impacts on framerate there are? Maybe there's something special about DF's pathfinder heuristics which means it doesn't quite work as we'd expect (although I doubt it).<br />
---[[User:Nand|Nand]] 06:10, 6 January 2012 (UTC)
-== Multicore ==
-Is there any way to modify Dwarf Fortress to take advantage of multicore CPUs? I recently got a beast of a computer, but with a large fort I'm still slowed down to 30fps since DF is only using 1/8 my processing power. I'd think not, such a thing is a pretty major change... so I guess really I should be asking if there's any indication from Toady that he's implementing multithreading in the upcoming release? If he's looking for a way to improve performance, I can think of none better. --[[Special:Contributions/74.102.134.192|74.102.134.192]] 23:42, 13 February 2012 (UTC)
-*Nope. --[[User:Quietust|Quietust]] 03:15, 14 February 2012 (UTC)
-== Process priority ==
-I just tried to increase the priority of Dwarf Fortress.exe in task manager. I set it to high (realtime was not permitted) and went from 50 to 60 fps. Anyone wanna verify? [[User:Surma92|Surma92]] 20:07, 12 April 2012 (UTC)