Dwarf Fortress Wiki - User contributions [en]

40d:Maximizing framerate

2010-02-09T23:57:59Z

Kludge: /* Advice for v0.28.181.40d */ -- Accel v. link updated, 40d16 -> 40d17 & removed "rumor" since... well, it´s a rumor.

Dwarf Fortress is an extremely CPU-intensive application that currently requires a fast, modern machine ([[System_requirements|recommendations]]). The objective of this page is to help you reduce game lag, a crippling problem for many players.

Please mark all advice with the most recent game version it is known to work for. This game is under rapid development, Toady One clearly intends to reduce lag where possible, and so methods that worked in, say, v0.27.169.33g may not a few months later.

== Advice for v0.28.181.40d ==
There exists [http://www.bay12games.com/forum/index.php?topic=44829.0 an accelerated version] of DF. It utilizes OpenGL much more effectively. You might want to give it a try. Due to it being an alpha of an alpha you can expect anything from wonders to utter fail.

=== OpenGL ===
* If framerate is extremely slow with an otherwise CPU-friendly fortress and a decent machine, your graphic card's interaction with the OpenGL code used by the game may be at fault. Updating your drivers usually works; you may also have to adjust some settings in your graphic card's control software, such as turning vertical synchronization off.

However, the acceleration program above works by altering the way DF interacts with OpenGL. It may be worth a try too.

== Advice for v0.27.176.38c ==

=== World size ===
Reducing the generated world size will make a large improvement in speed on computers with low physical memory. The world itself is generated faster, smaller, and it will take less time to save and load.
* When starting the game pick the "Design New World With Parameters" option.
* Select medium or smaller by using the arrow keys.
* Generate the new world.
* Start a new game in the smaller world.
Smaller is not always better. If you make your world too small then there will be nothing interesting on it. So try medium first before going smaller. Pocket dimensions are generated extremely quickly but are mostly just for testing mods. Newer versions have world generation settings which can be used to create "perfect world" as small as pocket one but with most interesting things in. This however isn't easy and requires much time.

== Advice for v0.27.169.33b-g ==

=== Game options ===
In the folder "\data\init" is a file named "init.txt". Edits to this file can greatly increase game speed. Keep backups for safety and to save yourself having to re-enter values every time you upgrade.

{| border="1" cellpadding="2"
!Parameter
!Effect
!Speed Improvement
|-
|[SOUND:OFF]|| Disables sound. ||Slight increase in speed.
|-
| [FPS:YES], [FPS_CAP:100]: ||Handy indicator of how fast your game is running.||
|-
| [G_FPS_CAP:15]:|| Controls refresh rate. ||Lower values often boost speed dramatically ... at the cost of less frequent visual updates, which can pose a problem during battles.
|-
| [VSYNC:OFF]: || Attempting to synchronize refreshes ||can kill game speed for some players (depending on your OS, graphics card, and OpenGL settings).
|-
| [PARTIAL_PRINT:YES:2]:||This makes the game only refresh sections of the screen that need to be refreshed. From init.txt: "The number refers to how many frames it will redo a printed tile before skipping it, so you might try increasing it a bit." || Can hugely increase performance but doesn't work on all systems. Using a higher value than 2 may be necessary for it to work (many players report it working when it's set one higher than their [G_FPS_CAP]).
|-
| [PRIORITY:HIGH]:||This option automatically makes the game run in high priority. ||This will probably prevent your computer from effectively running anything at the same time as the game and, for some players, causes major lag in the DF interface as well. Still worth a try, though.
|-
|[PRIORITY:REALTIME] ||devotes even more resources to Dwarf Fortress, but has been known to cause stuttering gameplay. ||Increasing priority will make the game difficult to kill using task manager if it locks up. This happens because things like screen output and HD access are not entirely part of DF. However, a dual-core machine can use realtime priority without fear of consequences, at least as long as DF remains single-threaded.
|-
| [TEMPERATURE:NO]: || Turns off temperature greatly increases speed. ||It also kills off some rather nice lava warming effects, stops rivers from freezing and (importantly!) thawing, makes glacial maps less interesting, and prevents sudden deaths from exposure. You're well-advised to stick with "warm" or "hot" fortress sites if you turn temperature off and your source of water is a stream.
|-
| [WEATHER:NO]: || Turns off weather ||increases speed noticeably.
|-
| [CAVEINS:NO]: ||Turns off cave-ins ||increases speed only fractionally.
|-
| [POPULATION_CAP:40]: || Keep your population under control to prevent the game bogging down. ||Pathfinding for numerous dwarves can bring even a fast machine to its knees.
|}

=== Fortress site ===
* Moving fluids are the major source of lag in most maps at game start. Magma and (to a lesser extent) running water are CPU hogs in the current version. If you haven't got the hardware to run DF with a magma site, suck it up and go without. Gigantic major rivers lower the framerate significantly. Aquifers (until tapped) and stagnant pools seem not to cause major speed issues.
* Avoid elevation extremes. The fewer the z-levels, the faster the game runs.
* Minimize map size. Smaller maps get you substantially more speed.
* Avoid caves, towns, ruins, or anything populated. Everything in them invokes the pathfinding code frequently.
* [[Glowing pit|Hidden Fun Stuff]] can cause a substantial slowdown once you break into it, though it's not a problem while it's still hidden.

=== Fortress layout and gameplay ===
* Narrow paths and bottlenecks cause the pathfinding algorithm to repeatedly recompute a faster route for each dwarf (and pet) as the paths empty and clear. Use large hallways and multiple stairways to connect any two spots where lots of dwarves will want to be.
* Keep wandering pets and wild animals to a minimum and cage livestock. The AI for all of these has become more efficient of late and each one costs much less CPU time than a dwarf, but sheer numbers matter.
* Avoid designating very large areas for chopping, gathering, detailing, or mining, especially if many dwarves do these things.
* Some observers suspect that having massive numbers of objects in stockpiles also impacts FPS; others believe any effect is minor{{verify}}. Food stockpiles seem to be the worst offenders; if your fortress overproduces food, you may see a progressive slowdown even if your population and pathing complexity don't change.
* Blocking off areas of the fortress entirely - especially (only?) with removable obstacles like drawbridges or forbidden doors - causes serious problems with pathfinding.

=== Cheating ===
* Fully revealed areas are faster than hidden ones. Running reveal.exe will make the game faster.
* As of 28.181.40d this appears to be quite the reverse.

=== Non-factors ===
The following things ''don't'' have a significant effect on game speed, at least as tested.

* Fullscreen or windowed (if OpenGL settings are compatible with the game)
* Use of [[List of user graphics sets|custom graphics sets]], choice of graphics tileset
* Size of tiles
* Number of z-levels mined out (fortress pathfinding complexity matters; mere distance up and down doesn't)

== Advice for v0.27.169.33a ==
* Upgrade.

== Advice for earlier versions ==
* If framerate is always slow at startup, your graphic card's interaction with the OpenGL code used by the game is likely to be at fault. Turning off vertical synchronization and updating your drivers usually works.
* Put animals in cages. Never keep them behind locked doors and reduce wandering pets to a reasonable number.
* Do not specify huge areas for mining or (especially) detailing.
* Open up \data\init\init.txt. Turn off TEMPERATURE and WEATHER and reduce POPULATION_CAP.

== Hardware- and OS-specific Advice ==

=== Dual Processors ===
* Go into task manager and set the affinity of Dwarf Fortress to one processor, and then set all the programs that use significant resources to the other. If Dwarf Fortress ever utilizes more than one processor, this will of course become irrelevant; currently, however, very few programs do and the best use of a dual processor is to give DF its own processor. This is ''not'' recommended for laptop computers, which will switch betwee processors as a heat management technique. Pinning to one processor will cause the processor to start slowing down instead.

* Vista's START command can be used to set affinity with the /AFFINITY switch, so basically you can create a shortcut and you won't need to set affinity manually.

=== Laptop computers ===
* Frame rate is higher when running off mains power. This is because laptops reduce CPU performance to extend the battery life.
* You can disable that feature in MS Windows, at the expense of the battery running out much more quickly.
* Some laptops may overheat if you run Dwarf Fortress for too long, keep your laptop cool if you find that after a while FPS suddenly drops. (This is due to CPU throttling intended to prevent possible damage from heat building up.)

===Dual monitors===
* Display DF entirely on one screen (no overlap to the second screen whatsoever).

==See also==
*[[System requirements]]
*[[water]]
*[[One-way|One-way paths]]

[[Category:Guides]]
{{Game_Interface FAQ}}

40d Talk:Maximizing framerate

2010-02-09T23:51:35Z

Kludge: /* New 40d# releases and the Acceleration program */

== Using DF with Mac ==
I'm using a Powerbook G4, and DF 0.28.181.40d. I have NEVER experienced ANY lag... EVER! It's absolutely awful when I try to play on my Windows PC, it seems so chunky. I tried it an the macs at school and it works great on those as well. DF certainly is more Mac-friendly than Windows-firendly! --[[User:Darkond2100|Darkond2100]] 03:48, 27 January 2010 (UTC)

== Effect on # of dwarves, framerate calculations ==

I'm not sure how important the number of dwarves is on the framerate. I was getting about 12 to 15 with 22 dwarves, and this has fallen to 9 with 97 dwarves. I think it is more bad pathing, like animals being caught behind doors that causes more problems than the number of units themselves. The addition of 80 goblins had an impact of 1 fps as well... although again, they probably weren't having any trouble path finding to no where. --Gotthard 13:53, 3 December 2007 (EST)

:I typically see a substantial drop in framerate when new immigrants come, and afterward the game's never as fast or responsive. However, I also demand a higher framerate (not less than 40, to avoid annoying interface lagging/jerkiness) than many people seem prepared to tolerate, so our findings aren't inconsistent. You just have more load already and so don't notice a given amount of additional usage as much. [[User:Fedor|Fedor]] 05:39, 7 December 2007 (EST)

::If this is the case, then I doubt there is a linear relationship associated with the FPS values. The G_FPS might also impact this. Typically, 10-12 more dwarves lowered my FPS by 1 at max, and I have 6 masons making blocks for my castle, and 18 dwarves running around permanently putting them up. I would guess that the FPS drops off fast to begin with, so it takes a lot to go down from 10-9 fps compared to 40-39 fps. --Gotthard 08:35, 7 December 2007 (EST)

:::Yes, this is expected. Framerate changes aren't linear and here's why: Let us imagine that a given computer can process 10,000 game things per second. A framerate of 100 means that the game requires only 100 calculations per update, and therefore can update 100 times/second. A framerate of 1 means the game has to perform 10,000 calculations per update. To drop from 40 to 39 FPS, the game must require ~6 more calculations per update. To drop from 10 to 9 FPS, the game must require ~111 more calculations per update. [[User:Fedor|Fedor]] 08:51, 13 December 2007 (EST)

::Wow, I can't stand things if FPS falls under ~80! Though, running a 2.1Ghz Dual Core and 512M 8600GeForce probably has some bearing on it. Personally, I run my G_FPS at only 10, and FPS_CAP at 200. I haven't gotten to economy sized populations yet with these settings (mostly on purpose cause I also keep my POP_CAP to only 10 until I've gotten the majority of the fortress dug out and a good stock of food and bedrooms, etc. The extra dwarves end up just getting in the way any other time I've tried my play-style. With this setup, I usually average around 150 FPS. Also, I've noticed a difference in FPS if I have the map section open, either single or double pane, moreso when there are a large number of creatures on the map. Simply closing (tabbing) the map got me an increase from ~125 to ~140. Should be worth 2-3 frames at the low FPS levels you guys are talking about. I'm also curious if the FPS counter itself has a significant effect on frames... --[[User:n9103|n9103]] 11:40, 17 Dec 2007 (PST)

:::Dude... you are runnning the game displaying at 10 FPS even though it's 80~200 FPS (IE: Should be pretty damn jerky), and never got an economy sized population. Of course you have a good FPS. Hell, mine was sticking at 100 with 10 dwarves and I just have a ~2 year old straight out of the box PC. [[User:Milskidasith|Milskidasith]] 22:18, 11 November 2008 (EST)

== Weather and Trees ==

Is it just me, or with weather turned trees will not grow back. Most saplings have withered and died. The landscape is littered with them. I'm in a Mirthful area, so it's not alignment. I haven't been able to get any trees since I deforested the entire area, and yes, it has been over three years. I'm playing 33d. [[User:Klada|Klada]] 19:50, 5 December 2007 (EST)

:Well I've been playing map for 6 years now, and I've had weather on the entire time, tons of trees have grown back. I've not deforested the ENTIRE area, but from what I understand trees grow back at a proportional rate to the amount of area there was to grow, so it should be better. I think saplings randomly die, perhaps moreso with traffic on them but... I don't have an explanation. --Gotthard 19:23, 6 December 2007 (EST)

::"Is it just me, or with weather turned trees will not grow back." Turned on or turned off? Logically, if weather were turned off, trees shouldn't grow to maturity. --[[User:n9103|n9103]] 11:29, 17 Dec 2007 (PST)

:::Trees grow back just fine with weather turned off. I don't know why sometimes most or all the saplings die, but it's not turning weather off that causes it. --[[User:BurnedToast|BurnedToast]] 00:00, 4 January 2008 (EST)

::::N9103, logic has no place here. Begone! --[[User:Savok|Savok]] 15:12, 21 March 2008 (EDT)

:::::HA! Tell that to Flingify() ^.^ Most things in DF do get a logical implementation... notable exceptions exist of course, but generally speaking, things follow commonsense. ... So Nya! --[[User:N9103|Edward]] 05:55, 22 March 2008 (EDT)

:Is any part of the area you embarked at evil? If so, are they the areas that the trees could grow in? (i.e. a mirthful mountain next to haunted woods) If you're beyond doubt sure that that's not the case, then going on what else has been investigated, I see one of two things: Complete deforestation *stops* tree growth, including saplings; Or, you've got some kind of bug that hasn't been documented yet. --[[User:N9103|Edward]] 19:05, 2 April 2008 (EDT)

== Economy ==

Can we confirm/disprove the effect of the economy on framerate? --[[User:DDouble|DDouble]] 02:42, 13 December 2007 (EST)

:Not sure what you mean exactly. The economy makes several changes, any of which might potentially impact speed. Can you give more detail on what specifically might potentially be causing a slowdown (or speed boost)? Is there a discussion on the forum that you have in mind? [[User:Fedor|Fedor]] 08:51, 13 December 2007 (EST)

::I'm pretty sure he's talking about the init setting and turning it off. The 'potentially' part you mentioned is what he wanted clarification on. Does turning the setting off before the economy activates improve pre-economy performance? There might indeed be people out there that are willing to lose one of the cooler features for a much improved framerate. A good question is does turning that setting off prevent you from ever gaining an economy (when you decide to turn the option back on) should you pass the point where it should have activated? --[[User:n9103|n9103]] 11:27, 17 Dec 2007 (PST)

== One Way Stairs ==

"Use ...multiple one-way stairways to connect any two spots where lots of dwarves will want to be"

How do you make a one way stair? I tried searching here, and on the forum, but didn't find it. [[User:Calculus|Calculus]]

:I mean to use paired up and down staircases instead of up/down ones. This suggestion is now removed because I'm not sure it actually makes a difference (it's safer for your dwarves, but I don't see a difference in game speed) [[User:Fedor|Fedor]] 14:50, 2 January 2008 (EST)

::How is a single-floor staircase (down+up) any safer than using a multiple-floor staircase (down+down/up+up)?

::Or for that matter, how is it different than making all your staircases down/up (minus bottom level of course)? --[[User:N9103|Edward]] 22:40, 3 January 2008 (EST)

:::If a dwarf falls down a multi-level up/down staircase, he may die or be badly injured.[[User:Fedor|Fedor]] 22:52, 3 January 2008 (EST)

::::What would cause a dwarf to fall down stairs aside from combat?--[[User:Maximus|Maximus]] 01:59, 4 January 2008 (EST)

:::::Haven't a clue. I just know that several people have reported their dwarves getting killed or maimed that way.[[User:Fedor|Fedor]] 15:17, 5 January 2008 (EST)

::::I used to use the up/down staircases for a central mineshaft until I had multiple dwarves become maimed/die when fighting on the stairs. I now use a spiral staircase design instead. I don't think anything BUT combat makes them fall, but if they charge a goblin snatcher and miss, there's no promise they won't end up 15 levels down missing all their limbs. --Gotthard 11:08, 7 January 2008 (EST)

:::::How about using floor hatches every level? -- Digger

::::::Those cause annoying blinkage. --[[User:Silfir|Silfir]] 07:17, 5 November 2008 (EST)

:::::::Don't use stairs at all. Use ramps, the distance to travel a ramp is only 1, compared to a stair, which is two. (ramps, step on it, your down auto; stairs, you step on it, then you step down.) – [[template:unsigned|unsigned]] comment by [[User:Zchris13|Zchris13]]

::::::::Please, please, ''please'' sign your comments (use four tildes). Anyway, I haven't had any significant problems with dwarves dodging and falling down stairs, because my levels don't span in a way that allows it to happen in the first place. Personally, I find that it's easier to lock down things that way, but others will probably disagree. ~ [[User:Midna|Midna]] 02:11, 9 December 2009 (UTC)

== Weather and windmills ==

To BurnedToast: You seem to be right that turning weather off doesn't stop windmills from working. I wasn't sure where I got that impression, but after looking it up, it was from several instances on IRC where people came in, said "The windmill isn't making power :(", were told to "turn weather on", went "Ah ha!", and never said that it didn't make them start working. (After I while I started suggesting it too since nobody had reported it not working, until recently.) So, hmm. I just switched a fort that had weather to not having it, and yeah, the windmills all still work. So I built a new one - also works. Then I generated a new world with weather off, started a new fort in it, built a windmill, and it produced 20 power. Oh well. --[[User:SL|SL]] 13:24, 9 January 2008 (EST)

== Multiple CPUs/Cores ==

As far as I have tested, DF uses 3 threads. It seems to put all its efforts in a single one, but even so, the other two still take cpu time, so having a dual-core machine still helps even if the threads are synchronized (and it isn't such a huge difference). I assume one of the threads link the display to the game core while the other runs the input buffer. I'd have to do more testing. [[User:Soulwynd|Soulwynd]] 23:37, 17 March 2008 (EDT)

== Bulging Histories ==

Any chance history plays a role in framerates? I have a fairly beefy machine and was regularly getting 100FPS in my first few forts, but after about 15 forts and 30 adventure modes (I'm quite suicidal), I can't get my FPS above 35 even on initial embark and a 3x3 fortress plot. [[User:Weasello|Weasello]] 12:43, 21 March 2008 (EDT)

:Well... from that data, that's likely. Personally, I play all my forts on separate worlds. --[[User:Savok|Savok]] 15:12, 21 March 2008 (EDT)

:I think I have to second the idea of (small histories == higher framerates) I've been playing a lot of small and smaller worlds, and even when I pick larger than normal sites, my frames seem to stay up better than on standard worlds. I'll test at some point just how well a Full Local map holds up in a Pocket world. --[[User:N9103|Edward]] 19:04, 2 April 2008 (EDT)

== Disconnection ==

I've found it '''VERY''' important, in terms of framerates, not to block all paths between your fortress and the outside world, either with raised bridges, or with forbidden doors. I'm not certain about walls, as I haven't desired "permanent" blocking, but temporary, to prevent thives and the like. Infact, pathfinding errors from those I desire to keep out are exactly what crashes the framerate. 
 
I'm talking about '''50% loss''', and that's just to start. If you continue to block the pathfinding, It's possible to have it completely crawl to a stop, as in 0-1 FPS! 
It's a shame that such a primitive defense results in such a catastrophic failure of the pathing system. :( 
 
As I didn't see it mentioned anywhere, I'm adding it here, and will eventually add it to the main article if no one else feels like pretty-ing it up for display. 
--[[User:N9103|Edward]] 17:42, 29 March 2008 (EDT)

:That's happening for you? I've been setting up an elaborate set of bridges and floodgates that serves as the only entrance to my fortress, and have closed my dwarves off inside on numerable occasions and it caused little more than make them cancel tasks that required them to leave the fortress.--[[User:Eurytus|Eurytus]] 15:57, 2 April 2008 (EST)

::Have you turned off invasions as well? I used to do that when I played with invasions off to develop my management abilities. I did it now in three different worlds (smaller) and have had it happen every time. The framerate loss began as soon as a goblin/kobold tried to do mischief and pull a lever, as determined in the error log. I would assume that thieves/snatchers would likely cause similar frame-crashes, but that much isn't verified on my part. --[[User:N9103|Edward]] 04:04, 4 April 2008 (EDT)

:::I have invasions on, although any attackers have died rather quickly.--[[User:Eurytus|Eurytus]] 21:48, 2 April 2008 (EST)

::::Hey look! invaders! I closed the gates and lowered the bridge, but my framerate didn't drop. In fact, just as the invaders got there my framerate went back up from a puzzlingly low 40 back up to a regular 90.--[[User:Eurytus|Eurytus]] 22:19, 2 April 2008 (EST)

::::I've tested it again with a couple more waves of goblins, and I've come to the conclusion that the preceding immense slowdown is while the goblins are on the map but not in view. This makes me think that either hidden units contribute to lag more, or the difficult terrain in my area causes their pathfinding to temporarily "freak out."--[[User:Eurytus|Eurytus]] 1:03, 3 April 2008 (EST)

:::::Well, it would seem obvious that invaders have glitches that have direct effects on framerates... just not well defined effects :-/ The "not in view" part seems true enough since the 'mischief-makers' are always invisible until discovered, and my forts generally have been rather far from invasion points. Looks like this is gonna be on hold for the page until someone does some '''extensive''' testing. --[[User:N9103|Edward]] 04:04, 4 April 2008 (EDT)

::::::I'll be happy to start testing it as soon as I start establishing some more long-term fortresses.--[[User:Eurytus|Eurytus]] 11:23, 4 April 2008 (EST)

:[[User_talk:Squirrelloid#Animals_try_to_path_through_tightly_closed_doors|Squirrelloid]]'s done some tests that end up proving the same point, but with animals instead of thieves/snatchers. Both of those groups use flawed pathfinding that doesn't properly account for created obstacles that are passable under certain conditions that aren't true at the time of the pathfind. (Doors being forbidden, or bridges raised for the thieves, and doors being designated as pet forbidden for the animals.) I still say that failed pathfinds cause 90% of framerate loss. --[[User:N9103|Edward]] 06:24, 1 May 2008 (EDT)

:I've uploaded a zip of my errorlog.txt that encompasses a decent, but not overly long amount of time. The unzipped file is 22MB! Thankfully, text compresses very well, and the zip is only 387K. <99% of the file is failed mischief from either goblins or kobolds. [http://dffd.wimbli.com/file.php?id=167] --[[User:N9103|Edward]] 02:29, 11 May 2008 (EDT)

: At some point the article on Maximizing Framerate should include a section that deals with player actions that can have an impact. Things like connecting a large open pipe system to a running water source, mass-designating stone for dumping, and closing off your fortress should all be listed as cons. I'm doing some research right now into the benefits of intelligent [[traffic area]] designations as well. For example, rooms larger than 11x11 with only two doors should have a high-traffic line linking the two doors, and two low-traffic "curbs" on either edge, to prevent the Dijkstra half of A* from spending extra cycles looking in dumb places. --[[User:Jurph|Jurph]] 18:01, 8 April 2009 (UTC)

== Dual Screens ==

I just put a second monitor on my computer, partly so I could fullscreen DF with the wiki in another screen. However, running DF in fullscreen make sit take up one screen like normal, and the other goes black. Ckciking the black monitor causes DF to stretch across the monitors. Since there is info here about running DF in one monitor to save CPU cycles, I was wondering is anyone could help. – [[template:unsigned|unsigned]] comment by [[User:Ilmmad|Ilmmad]]

:I don't understand what you're saying. Dwarf Fortress does not do that on my computer. Operating system, perhaps? By the way, sign your comments using <nowiki>--~~~~</nowiki>. --[[User:GreyMario|GreyMario]] 17:24, 22 April 2008 (EDT)

:When you enter fullscreen mode with most graphics apis (such as OpenGL) you will take full control, which is why the other screen goes black. Your best bet is to run in windowed mode with the window size set to your resolution. --[[User:Shades|Shades]] 18:01, 22 April 2008 (EDT)

::I had this same thought; and did some measurement - on Windows with the "windows standard" theme and default fonts, the room needed for the chrome is 27 pixels vertical, 8 pixels horizontal. [[User:Random832|Random832]] 10:31, 14 October 2008 (EDT)

== temperature ==

From the article "" You're well-advised to stick with "warm" or "hot" fortress sites if you turn temperature off and your source of water is a stream."" --- I cannot understand that. --[[User:Catpaw|Catpaw]] 08:29, 16 September 2008 (EDT)

:If you turn temperature off, and you start on a cold location with a stream, the stream will be frozen and never thaw.[[User:DaBing|DaBing]]

So wait, it says some "rather nice lava warming effects" are turned off, but what are these exactly? Can I still dump stone in lava? What stops working? [[User:Ar-Pharazon|Ar-Pharazon]] 17:09, 18 February 2009 (EST)

:You can still dump stone in lava, it just won't melt as there is no heat transfer. --[[User:Elvang|Elvang]] 21:00, 18 February 2009 (EST)

== New 40d# releases and the Acceleration program ==

So I'm sure most of you are aware of the new 40d releases (I think it's on 40d7) that toady has been putting out that incorporate better handling of OpenGL. In so far as I understand, he is combining the acceleration program into Dwarf Fortress, so they come 'packaged' together right out of the box. Also, the thread that the wiki is linking to ( http://www.bay12games.com/forum/index.php?topic=27262.0 ) is stated to be obsolete and sends the user to the 40d# thread ( http://www.bay12games.com/forum/index.php?topic=27262.0 ). I think we should update/remove/replace the 'acceleration program' portion of this article to point users to the new 40d# releases, unless we want to wait until Toady releases something final before changing anything? If do decide to change it, we might want to make people aware that there WAS an acceleration program, but it has been superseded by the new 40d# releases. Thoughts? --[[User:Sinergistic|Sinergistic]] 00:24, 6 January 2009 (EST)

=== Turn Mouse Support Off ===

With the graphics-accelerated versions of 40d above, I've found that turning mouse support completely off ( [MOUSE:NO] in init.txt ) has had greater improvement in framerate than anything else I've tried. Can anyone else confirm this? (nammyung)

:This does not appear to be the case in 40d17 - FPS also seems unaffected with .bmp cursor enabled. [[User:Kludge|-K]] 23:51, 9 February 2010 (UTC)

== Small Worlds ==

I noticed mention of small worlds. I have no doubt that they probably reduce lag, but I will argue the creation time issue. My experience so far has been that "pocket" and "smaller" sized worlds take longer to gen than "Small" and "Medium," because of the shear volume of rejected attempts in the initial creation stage. My experience is entirely with 40d and 40d9. [[User:Burlingk|Burlingk]] 01:42, 10 February 2009 (EST)
:You don't get many rejects with the default configurations for worlds. When you start changing those, yes, rejects will happen, especially if you're trying to fit as much into a pocket sized one as you would into a small. [[User:Shardok|Shardok]] 00:06, 25 August 2009 (UTC)

== Peasant cancels Rest: Interrupted by recruit ==

This event caused my FPS to drop to <1. One of my recruits went berserk over the loss of his pet and started attacking an unlucky peasant. The peasant went unconscious and the above message was spammed on the screen thousands and thousands of times. As soon as my military had finished off the berserk recruit, the FPS jumped back to the solid 100.

40d Talk:Maximizing framerate

2010-02-09T23:51:14Z

Kludge: /* New 40d# releases and the Acceleration program */

== Using DF with Mac ==
I'm using a Powerbook G4, and DF 0.28.181.40d. I have NEVER experienced ANY lag... EVER! It's absolutely awful when I try to play on my Windows PC, it seems so chunky. I tried it an the macs at school and it works great on those as well. DF certainly is more Mac-friendly than Windows-firendly! --[[User:Darkond2100|Darkond2100]] 03:48, 27 January 2010 (UTC)

== Effect on # of dwarves, framerate calculations ==

I'm not sure how important the number of dwarves is on the framerate. I was getting about 12 to 15 with 22 dwarves, and this has fallen to 9 with 97 dwarves. I think it is more bad pathing, like animals being caught behind doors that causes more problems than the number of units themselves. The addition of 80 goblins had an impact of 1 fps as well... although again, they probably weren't having any trouble path finding to no where. --Gotthard 13:53, 3 December 2007 (EST)

:I typically see a substantial drop in framerate when new immigrants come, and afterward the game's never as fast or responsive. However, I also demand a higher framerate (not less than 40, to avoid annoying interface lagging/jerkiness) than many people seem prepared to tolerate, so our findings aren't inconsistent. You just have more load already and so don't notice a given amount of additional usage as much. [[User:Fedor|Fedor]] 05:39, 7 December 2007 (EST)

::If this is the case, then I doubt there is a linear relationship associated with the FPS values. The G_FPS might also impact this. Typically, 10-12 more dwarves lowered my FPS by 1 at max, and I have 6 masons making blocks for my castle, and 18 dwarves running around permanently putting them up. I would guess that the FPS drops off fast to begin with, so it takes a lot to go down from 10-9 fps compared to 40-39 fps. --Gotthard 08:35, 7 December 2007 (EST)

:::Yes, this is expected. Framerate changes aren't linear and here's why: Let us imagine that a given computer can process 10,000 game things per second. A framerate of 100 means that the game requires only 100 calculations per update, and therefore can update 100 times/second. A framerate of 1 means the game has to perform 10,000 calculations per update. To drop from 40 to 39 FPS, the game must require ~6 more calculations per update. To drop from 10 to 9 FPS, the game must require ~111 more calculations per update. [[User:Fedor|Fedor]] 08:51, 13 December 2007 (EST)

::Wow, I can't stand things if FPS falls under ~80! Though, running a 2.1Ghz Dual Core and 512M 8600GeForce probably has some bearing on it. Personally, I run my G_FPS at only 10, and FPS_CAP at 200. I haven't gotten to economy sized populations yet with these settings (mostly on purpose cause I also keep my POP_CAP to only 10 until I've gotten the majority of the fortress dug out and a good stock of food and bedrooms, etc. The extra dwarves end up just getting in the way any other time I've tried my play-style. With this setup, I usually average around 150 FPS. Also, I've noticed a difference in FPS if I have the map section open, either single or double pane, moreso when there are a large number of creatures on the map. Simply closing (tabbing) the map got me an increase from ~125 to ~140. Should be worth 2-3 frames at the low FPS levels you guys are talking about. I'm also curious if the FPS counter itself has a significant effect on frames... --[[User:n9103|n9103]] 11:40, 17 Dec 2007 (PST)

:::Dude... you are runnning the game displaying at 10 FPS even though it's 80~200 FPS (IE: Should be pretty damn jerky), and never got an economy sized population. Of course you have a good FPS. Hell, mine was sticking at 100 with 10 dwarves and I just have a ~2 year old straight out of the box PC. [[User:Milskidasith|Milskidasith]] 22:18, 11 November 2008 (EST)

== Weather and Trees ==

Is it just me, or with weather turned trees will not grow back. Most saplings have withered and died. The landscape is littered with them. I'm in a Mirthful area, so it's not alignment. I haven't been able to get any trees since I deforested the entire area, and yes, it has been over three years. I'm playing 33d. [[User:Klada|Klada]] 19:50, 5 December 2007 (EST)

:Well I've been playing map for 6 years now, and I've had weather on the entire time, tons of trees have grown back. I've not deforested the ENTIRE area, but from what I understand trees grow back at a proportional rate to the amount of area there was to grow, so it should be better. I think saplings randomly die, perhaps moreso with traffic on them but... I don't have an explanation. --Gotthard 19:23, 6 December 2007 (EST)

::"Is it just me, or with weather turned trees will not grow back." Turned on or turned off? Logically, if weather were turned off, trees shouldn't grow to maturity. --[[User:n9103|n9103]] 11:29, 17 Dec 2007 (PST)

:::Trees grow back just fine with weather turned off. I don't know why sometimes most or all the saplings die, but it's not turning weather off that causes it. --[[User:BurnedToast|BurnedToast]] 00:00, 4 January 2008 (EST)

::::N9103, logic has no place here. Begone! --[[User:Savok|Savok]] 15:12, 21 March 2008 (EDT)

:::::HA! Tell that to Flingify() ^.^ Most things in DF do get a logical implementation... notable exceptions exist of course, but generally speaking, things follow commonsense. ... So Nya! --[[User:N9103|Edward]] 05:55, 22 March 2008 (EDT)

:Is any part of the area you embarked at evil? If so, are they the areas that the trees could grow in? (i.e. a mirthful mountain next to haunted woods) If you're beyond doubt sure that that's not the case, then going on what else has been investigated, I see one of two things: Complete deforestation *stops* tree growth, including saplings; Or, you've got some kind of bug that hasn't been documented yet. --[[User:N9103|Edward]] 19:05, 2 April 2008 (EDT)

== Economy ==

Can we confirm/disprove the effect of the economy on framerate? --[[User:DDouble|DDouble]] 02:42, 13 December 2007 (EST)

:Not sure what you mean exactly. The economy makes several changes, any of which might potentially impact speed. Can you give more detail on what specifically might potentially be causing a slowdown (or speed boost)? Is there a discussion on the forum that you have in mind? [[User:Fedor|Fedor]] 08:51, 13 December 2007 (EST)

::I'm pretty sure he's talking about the init setting and turning it off. The 'potentially' part you mentioned is what he wanted clarification on. Does turning the setting off before the economy activates improve pre-economy performance? There might indeed be people out there that are willing to lose one of the cooler features for a much improved framerate. A good question is does turning that setting off prevent you from ever gaining an economy (when you decide to turn the option back on) should you pass the point where it should have activated? --[[User:n9103|n9103]] 11:27, 17 Dec 2007 (PST)

== One Way Stairs ==

"Use ...multiple one-way stairways to connect any two spots where lots of dwarves will want to be"

How do you make a one way stair? I tried searching here, and on the forum, but didn't find it. [[User:Calculus|Calculus]]

:I mean to use paired up and down staircases instead of up/down ones. This suggestion is now removed because I'm not sure it actually makes a difference (it's safer for your dwarves, but I don't see a difference in game speed) [[User:Fedor|Fedor]] 14:50, 2 January 2008 (EST)

::How is a single-floor staircase (down+up) any safer than using a multiple-floor staircase (down+down/up+up)?

::Or for that matter, how is it different than making all your staircases down/up (minus bottom level of course)? --[[User:N9103|Edward]] 22:40, 3 January 2008 (EST)

:::If a dwarf falls down a multi-level up/down staircase, he may die or be badly injured.[[User:Fedor|Fedor]] 22:52, 3 January 2008 (EST)

::::What would cause a dwarf to fall down stairs aside from combat?--[[User:Maximus|Maximus]] 01:59, 4 January 2008 (EST)

:::::Haven't a clue. I just know that several people have reported their dwarves getting killed or maimed that way.[[User:Fedor|Fedor]] 15:17, 5 January 2008 (EST)

::::I used to use the up/down staircases for a central mineshaft until I had multiple dwarves become maimed/die when fighting on the stairs. I now use a spiral staircase design instead. I don't think anything BUT combat makes them fall, but if they charge a goblin snatcher and miss, there's no promise they won't end up 15 levels down missing all their limbs. --Gotthard 11:08, 7 January 2008 (EST)

:::::How about using floor hatches every level? -- Digger

::::::Those cause annoying blinkage. --[[User:Silfir|Silfir]] 07:17, 5 November 2008 (EST)

:::::::Don't use stairs at all. Use ramps, the distance to travel a ramp is only 1, compared to a stair, which is two. (ramps, step on it, your down auto; stairs, you step on it, then you step down.) – [[template:unsigned|unsigned]] comment by [[User:Zchris13|Zchris13]]

::::::::Please, please, ''please'' sign your comments (use four tildes). Anyway, I haven't had any significant problems with dwarves dodging and falling down stairs, because my levels don't span in a way that allows it to happen in the first place. Personally, I find that it's easier to lock down things that way, but others will probably disagree. ~ [[User:Midna|Midna]] 02:11, 9 December 2009 (UTC)

== Weather and windmills ==

To BurnedToast: You seem to be right that turning weather off doesn't stop windmills from working. I wasn't sure where I got that impression, but after looking it up, it was from several instances on IRC where people came in, said "The windmill isn't making power :(", were told to "turn weather on", went "Ah ha!", and never said that it didn't make them start working. (After I while I started suggesting it too since nobody had reported it not working, until recently.) So, hmm. I just switched a fort that had weather to not having it, and yeah, the windmills all still work. So I built a new one - also works. Then I generated a new world with weather off, started a new fort in it, built a windmill, and it produced 20 power. Oh well. --[[User:SL|SL]] 13:24, 9 January 2008 (EST)

== Multiple CPUs/Cores ==

As far as I have tested, DF uses 3 threads. It seems to put all its efforts in a single one, but even so, the other two still take cpu time, so having a dual-core machine still helps even if the threads are synchronized (and it isn't such a huge difference). I assume one of the threads link the display to the game core while the other runs the input buffer. I'd have to do more testing. [[User:Soulwynd|Soulwynd]] 23:37, 17 March 2008 (EDT)

== Bulging Histories ==

Any chance history plays a role in framerates? I have a fairly beefy machine and was regularly getting 100FPS in my first few forts, but after about 15 forts and 30 adventure modes (I'm quite suicidal), I can't get my FPS above 35 even on initial embark and a 3x3 fortress plot. [[User:Weasello|Weasello]] 12:43, 21 March 2008 (EDT)

:Well... from that data, that's likely. Personally, I play all my forts on separate worlds. --[[User:Savok|Savok]] 15:12, 21 March 2008 (EDT)

:I think I have to second the idea of (small histories == higher framerates) I've been playing a lot of small and smaller worlds, and even when I pick larger than normal sites, my frames seem to stay up better than on standard worlds. I'll test at some point just how well a Full Local map holds up in a Pocket world. --[[User:N9103|Edward]] 19:04, 2 April 2008 (EDT)

== Disconnection ==

I've found it '''VERY''' important, in terms of framerates, not to block all paths between your fortress and the outside world, either with raised bridges, or with forbidden doors. I'm not certain about walls, as I haven't desired "permanent" blocking, but temporary, to prevent thives and the like. Infact, pathfinding errors from those I desire to keep out are exactly what crashes the framerate. 
 
I'm talking about '''50% loss''', and that's just to start. If you continue to block the pathfinding, It's possible to have it completely crawl to a stop, as in 0-1 FPS! 
It's a shame that such a primitive defense results in such a catastrophic failure of the pathing system. :( 
 
As I didn't see it mentioned anywhere, I'm adding it here, and will eventually add it to the main article if no one else feels like pretty-ing it up for display. 
--[[User:N9103|Edward]] 17:42, 29 March 2008 (EDT)

:That's happening for you? I've been setting up an elaborate set of bridges and floodgates that serves as the only entrance to my fortress, and have closed my dwarves off inside on numerable occasions and it caused little more than make them cancel tasks that required them to leave the fortress.--[[User:Eurytus|Eurytus]] 15:57, 2 April 2008 (EST)

::Have you turned off invasions as well? I used to do that when I played with invasions off to develop my management abilities. I did it now in three different worlds (smaller) and have had it happen every time. The framerate loss began as soon as a goblin/kobold tried to do mischief and pull a lever, as determined in the error log. I would assume that thieves/snatchers would likely cause similar frame-crashes, but that much isn't verified on my part. --[[User:N9103|Edward]] 04:04, 4 April 2008 (EDT)

:::I have invasions on, although any attackers have died rather quickly.--[[User:Eurytus|Eurytus]] 21:48, 2 April 2008 (EST)

::::Hey look! invaders! I closed the gates and lowered the bridge, but my framerate didn't drop. In fact, just as the invaders got there my framerate went back up from a puzzlingly low 40 back up to a regular 90.--[[User:Eurytus|Eurytus]] 22:19, 2 April 2008 (EST)

::::I've tested it again with a couple more waves of goblins, and I've come to the conclusion that the preceding immense slowdown is while the goblins are on the map but not in view. This makes me think that either hidden units contribute to lag more, or the difficult terrain in my area causes their pathfinding to temporarily "freak out."--[[User:Eurytus|Eurytus]] 1:03, 3 April 2008 (EST)

:::::Well, it would seem obvious that invaders have glitches that have direct effects on framerates... just not well defined effects :-/ The "not in view" part seems true enough since the 'mischief-makers' are always invisible until discovered, and my forts generally have been rather far from invasion points. Looks like this is gonna be on hold for the page until someone does some '''extensive''' testing. --[[User:N9103|Edward]] 04:04, 4 April 2008 (EDT)

::::::I'll be happy to start testing it as soon as I start establishing some more long-term fortresses.--[[User:Eurytus|Eurytus]] 11:23, 4 April 2008 (EST)

:[[User_talk:Squirrelloid#Animals_try_to_path_through_tightly_closed_doors|Squirrelloid]]'s done some tests that end up proving the same point, but with animals instead of thieves/snatchers. Both of those groups use flawed pathfinding that doesn't properly account for created obstacles that are passable under certain conditions that aren't true at the time of the pathfind. (Doors being forbidden, or bridges raised for the thieves, and doors being designated as pet forbidden for the animals.) I still say that failed pathfinds cause 90% of framerate loss. --[[User:N9103|Edward]] 06:24, 1 May 2008 (EDT)

:I've uploaded a zip of my errorlog.txt that encompasses a decent, but not overly long amount of time. The unzipped file is 22MB! Thankfully, text compresses very well, and the zip is only 387K. <99% of the file is failed mischief from either goblins or kobolds. [http://dffd.wimbli.com/file.php?id=167] --[[User:N9103|Edward]] 02:29, 11 May 2008 (EDT)

: At some point the article on Maximizing Framerate should include a section that deals with player actions that can have an impact. Things like connecting a large open pipe system to a running water source, mass-designating stone for dumping, and closing off your fortress should all be listed as cons. I'm doing some research right now into the benefits of intelligent [[traffic area]] designations as well. For example, rooms larger than 11x11 with only two doors should have a high-traffic line linking the two doors, and two low-traffic "curbs" on either edge, to prevent the Dijkstra half of A* from spending extra cycles looking in dumb places. --[[User:Jurph|Jurph]] 18:01, 8 April 2009 (UTC)

== Dual Screens ==

I just put a second monitor on my computer, partly so I could fullscreen DF with the wiki in another screen. However, running DF in fullscreen make sit take up one screen like normal, and the other goes black. Ckciking the black monitor causes DF to stretch across the monitors. Since there is info here about running DF in one monitor to save CPU cycles, I was wondering is anyone could help. – [[template:unsigned|unsigned]] comment by [[User:Ilmmad|Ilmmad]]

:I don't understand what you're saying. Dwarf Fortress does not do that on my computer. Operating system, perhaps? By the way, sign your comments using <nowiki>--~~~~</nowiki>. --[[User:GreyMario|GreyMario]] 17:24, 22 April 2008 (EDT)

:When you enter fullscreen mode with most graphics apis (such as OpenGL) you will take full control, which is why the other screen goes black. Your best bet is to run in windowed mode with the window size set to your resolution. --[[User:Shades|Shades]] 18:01, 22 April 2008 (EDT)

::I had this same thought; and did some measurement - on Windows with the "windows standard" theme and default fonts, the room needed for the chrome is 27 pixels vertical, 8 pixels horizontal. [[User:Random832|Random832]] 10:31, 14 October 2008 (EDT)

== temperature ==

From the article "" You're well-advised to stick with "warm" or "hot" fortress sites if you turn temperature off and your source of water is a stream."" --- I cannot understand that. --[[User:Catpaw|Catpaw]] 08:29, 16 September 2008 (EDT)

:If you turn temperature off, and you start on a cold location with a stream, the stream will be frozen and never thaw.[[User:DaBing|DaBing]]

So wait, it says some "rather nice lava warming effects" are turned off, but what are these exactly? Can I still dump stone in lava? What stops working? [[User:Ar-Pharazon|Ar-Pharazon]] 17:09, 18 February 2009 (EST)

:You can still dump stone in lava, it just won't melt as there is no heat transfer. --[[User:Elvang|Elvang]] 21:00, 18 February 2009 (EST)

== New 40d# releases and the Acceleration program ==

So I'm sure most of you are aware of the new 40d releases (I think it's on 40d7) that toady has been putting out that incorporate better handling of OpenGL. In so far as I understand, he is combining the acceleration program into Dwarf Fortress, so they come 'packaged' together right out of the box. Also, the thread that the wiki is linking to ( http://www.bay12games.com/forum/index.php?topic=27262.0 ) is stated to be obsolete and sends the user to the 40d# thread ( http://www.bay12games.com/forum/index.php?topic=27262.0 ). I think we should update/remove/replace the 'acceleration program' portion of this article to point users to the new 40d# releases, unless we want to wait until Toady releases something final before changing anything? If do decide to change it, we might want to make people aware that there WAS an acceleration program, but it has been superseded by the new 40d# releases. Thoughts? --[[User:Sinergistic|Sinergistic]] 00:24, 6 January 2009 (EST)

=== Turn Mouse Support Off ===

With the graphics-accelerated versions of 40d above, I've found that turning mouse support completely off ( [MOUSE:NO] in init.txt ) has had greater improvement in framerate than anything else I've tried. Can anyone else confirm this? (nammyung)

This does not appear to be the case in 40d17 - FPS also seems unaffected with .bmp cursor enabled. [[User:Kludge|-K]] 23:51, 9 February 2010 (UTC)

== Small Worlds ==

I noticed mention of small worlds. I have no doubt that they probably reduce lag, but I will argue the creation time issue. My experience so far has been that "pocket" and "smaller" sized worlds take longer to gen than "Small" and "Medium," because of the shear volume of rejected attempts in the initial creation stage. My experience is entirely with 40d and 40d9. [[User:Burlingk|Burlingk]] 01:42, 10 February 2009 (EST)
:You don't get many rejects with the default configurations for worlds. When you start changing those, yes, rejects will happen, especially if you're trying to fit as much into a pocket sized one as you would into a small. [[User:Shardok|Shardok]] 00:06, 25 August 2009 (UTC)

== Peasant cancels Rest: Interrupted by recruit ==

This event caused my FPS to drop to <1. One of my recruits went berserk over the loss of his pet and started attacking an unlucky peasant. The peasant went unconscious and the above message was spammed on the screen thousands and thousands of times. As soon as my military had finished off the berserk recruit, the FPS jumped back to the solid 100.

40d Talk:System requirements

2010-02-07T03:39:17Z

Kludge: /* Benchmarks */

== DF Doesn't Need a Fancy GPU ==

Even considering how DF uses OpenGL for graphics, an integrated card should have absolutely no problem displaying 2000 quads on screen.

I threw together a quick and dirty test app to render 2000 dwarf faces, and it can manage 100 FPS with just 18% CPU load. Without throttling I get 600 FPS with 80% CPU. That's on an integrated (GMA x3100) card. So, at least for Intel's GMA cards going back at least two years, the graphics should perform just fine.

So that's why I don't think it should be necessary to recommend a powerful discrete GPU, especially when the screen isn't updated very often.

--[[User:Jcromartie|Jcromartie]] 13:31, 9 May 2008 (EDT)

:It's specifically stated that an old GPU will work just fine. Just a bargain bin 25$ card would be sufficient for the purpose. A '''BIG''' reason for using a separate GPU is the fact that they will share resources, (Shared Memory *and* CPU Cycles,) which will quickly affect performance of the CPU, which DF is quite power-hungry for at this stage, (and many future stages as well I'm sure.) --[[User:N9103|Edward]] 19:39, 9 May 2008 (EDT)

::Not to mention a seperate GPU takes ALL those 2000 quads off the processor. --[[User:Darkone|Darkone]] 20:35, 12 May 2008 (EDT)

== General Performance ==

I may be talking out of my butt here, and as a developer I can understand the challenges of (and reasons to avoid) optimization, but might it be time to start tuning DF? It uses 99% CPU on a 2.2GHz Core 2 Duo ''all the time''. This is even the case when displaying the main menu or when paused.

Maybe [http://www.artima.com/cppsource/how_to_go_slow.html this article] can shed some light on why it uses so much CPU when it doesn't need to?

--[[User:Jcromartie|Jcromartie]] 13:31, 9 May 2008 (EDT)

:I can see where you're coming from, but being that the majority of the game has yet to even be programmed, it's far too early to begin real optimizations. Toady's made a few tweaks to do minor optimizations, so he's got it in mind, so far as it won't interfere with the many core and other items that still need to be added. Over half of the [[http://www.bay12games.com/dwarves/dev_core_1-20.html Core Components]] are still missing, and it's even farther from completion when looking at the [[http://www.bay12games.com/dwarves/dev_req_1-50.html Non-Core Required Components]], a good number of which deal directly with optimization. --[[User:N9103|Edward]] 19:33, 9 May 2008 (EDT)

== Dual Core ==

I believe it may be right to add back in a recommendation, but not for multiple cores but the processor itself. Someone made an erroneous edit in the history stating that a single core is usually faster then a dual- this is wrong, as the Core 2 architecture is ''Far'' more powerful then Pentium, though I do not have data for AMD processors. A Core running at a mere 1.86 gigahertz pulls in a 3000+ benchmark (cinebench) versus the lowly 1800-2000 of a 3 gigahertz pentium 4. Not to mention running DF on its own private core is probably the best thing you could do with it.--[[User:Darkone|Darkone]] 10:45, 12 May 2008 (EDT)

Someone please check if DF might be multi-threaded after all. At least on my machine (q6600) DF quite beautifully
utilizes all four cores with individual loads usually not maxing out (110 dwarves). 1 February 2010

== Small Edit ==

I changed the Mac OsX portion of the page to a more current update.

== init.txt ==

I think there should be some mentions of init.txt here and on [[Maximizing Framerate]]. I found that there was a considerable difference when I changed the init.txt.

I found that, by changing [SOUND], [PARTIAL_PRINT], and [PRIORITY], I was able to significantly increase performance.

While running 66 processes (DF as well), including iTunes, Firefox, Desktop Sidebar, and Last.fm, the game's default init.txt was very poor. It lagged frequently, very much so in Adventure mode. I changed the aforementioned values in init.txt and it now runs wonderfully, with the exception of world creation, entering towns, and a very small lag when placing buildings.

My FPS before was only at 100 FPS when paused, usually around 50-65 when playing. Now, I seldom see it anything other than 99 or 100.

My system is as follows:

* Windows XP SP3
* Hard Disk: 83.2 GB free, 140 GB total
* AMD Sempron 3300+ processor
* 448 MB RAM
* In short, [http://h10025.www1.hp.com/ewfrf/wc/document?docname=c00796371&lc=en&dlc=en&cc=us&lang=en&product=3304167 This], bought Dec 15 2006.

== Linux system Requirements? ==
If you run Linux over Windows, does it enhance your FPS any?[[User:Kenji 03|Kenji 03]] 12:30, 2 August 2009 (UTC)

== Benchmarks ==

It would be really useful to use one or more specific fortresses for benchmarking purposes and post them all on DFFD, rather than just including various details which don't include certain vital statistics such as the number of objects, amount of revealed tiles, mid-air Z-levels which have been "allocated" by building into them (such that using "k" actually shows them as "open space" rather than nothing at all), and actual fortress layout (and thus how much CPU time is spent pathfinding). For example, a 2.4GHz Core 2 Duo is listed as handling a minimalist 6x6 site with 95 dwarves at ~20fps, while my 2.4GHz Core 2 Quad was able to support an 8x4 site with magma + pit + underground river + HFS and 200 dwarves and get 20fps with everything turned '''on''' because I had taken care to organize the fortress in such a way as to minimize pathfinding load. --[[User:Quietust|Quietust]] 18:40, 20 January 2010 (UTC)

:I like this idea overall. I don´t think it would be possible to assume what an "average" person builds their fortress like or if they even take pathfinding into account, but a standardized fortress, set of options, DF version, and t/f on use of OpenGL "accelerator" would make this list much more insightful. Unfortunately, it would throw out all previous data collected. If someone has the will and time, I think it would benefit readers, but I think the section does already serve its purpose in giving people a very rough idea of what to expect. In the data I personally posted, I did use the same fort (which paid no attention to optimizing the layout for minimizing pathfinding calculations) but I didn´t think to upload the save and no longer have it.[[User:Kludge|-K]] 03:37, 7 February 2010 (UTC) (a post-post thought -- It´d also be nice to have standardized data since the data could be merged into a pretty table!)

== Where do I get the Linux port? ==

Well, the headline basically says it all. It's not linked on the official download page... it took quite a bit of searching until I found anything -- which I don't want to post here, as I don't know whether what I found is in any way recommendable. In a nutshell: the section about the linux port should probably start with '''where to get it'''. --[[Special:Contributions/93.104.144.228|93.104.144.228]] 16:33, 4 February 2010 (UTC)

40d Talk:System requirements

2010-02-07T03:39:04Z

Kludge: Undo revision 62627 by Kludge (Talk)

== DF Doesn't Need a Fancy GPU ==

Even considering how DF uses OpenGL for graphics, an integrated card should have absolutely no problem displaying 2000 quads on screen.

I threw together a quick and dirty test app to render 2000 dwarf faces, and it can manage 100 FPS with just 18% CPU load. Without throttling I get 600 FPS with 80% CPU. That's on an integrated (GMA x3100) card. So, at least for Intel's GMA cards going back at least two years, the graphics should perform just fine.

So that's why I don't think it should be necessary to recommend a powerful discrete GPU, especially when the screen isn't updated very often.

--[[User:Jcromartie|Jcromartie]] 13:31, 9 May 2008 (EDT)

:It's specifically stated that an old GPU will work just fine. Just a bargain bin 25$ card would be sufficient for the purpose. A '''BIG''' reason for using a separate GPU is the fact that they will share resources, (Shared Memory *and* CPU Cycles,) which will quickly affect performance of the CPU, which DF is quite power-hungry for at this stage, (and many future stages as well I'm sure.) --[[User:N9103|Edward]] 19:39, 9 May 2008 (EDT)

::Not to mention a seperate GPU takes ALL those 2000 quads off the processor. --[[User:Darkone|Darkone]] 20:35, 12 May 2008 (EDT)

== General Performance ==

I may be talking out of my butt here, and as a developer I can understand the challenges of (and reasons to avoid) optimization, but might it be time to start tuning DF? It uses 99% CPU on a 2.2GHz Core 2 Duo ''all the time''. This is even the case when displaying the main menu or when paused.

Maybe [http://www.artima.com/cppsource/how_to_go_slow.html this article] can shed some light on why it uses so much CPU when it doesn't need to?

--[[User:Jcromartie|Jcromartie]] 13:31, 9 May 2008 (EDT)

:I can see where you're coming from, but being that the majority of the game has yet to even be programmed, it's far too early to begin real optimizations. Toady's made a few tweaks to do minor optimizations, so he's got it in mind, so far as it won't interfere with the many core and other items that still need to be added. Over half of the [[http://www.bay12games.com/dwarves/dev_core_1-20.html Core Components]] are still missing, and it's even farther from completion when looking at the [[http://www.bay12games.com/dwarves/dev_req_1-50.html Non-Core Required Components]], a good number of which deal directly with optimization. --[[User:N9103|Edward]] 19:33, 9 May 2008 (EDT)

== Dual Core ==

I believe it may be right to add back in a recommendation, but not for multiple cores but the processor itself. Someone made an erroneous edit in the history stating that a single core is usually faster then a dual- this is wrong, as the Core 2 architecture is ''Far'' more powerful then Pentium, though I do not have data for AMD processors. A Core running at a mere 1.86 gigahertz pulls in a 3000+ benchmark (cinebench) versus the lowly 1800-2000 of a 3 gigahertz pentium 4. Not to mention running DF on its own private core is probably the best thing you could do with it.--[[User:Darkone|Darkone]] 10:45, 12 May 2008 (EDT)

Someone please check if DF might be multi-threaded after all. At least on my machine (q6600) DF quite beautifully
utilizes all four cores with individual loads usually not maxing out (110 dwarves). 1 February 2010

== Small Edit ==

I changed the Mac OsX portion of the page to a more current update.

== init.txt ==

I think there should be some mentions of init.txt here and on [[Maximizing Framerate]]. I found that there was a considerable difference when I changed the init.txt.

I found that, by changing [SOUND], [PARTIAL_PRINT], and [PRIORITY], I was able to significantly increase performance.

While running 66 processes (DF as well), including iTunes, Firefox, Desktop Sidebar, and Last.fm, the game's default init.txt was very poor. It lagged frequently, very much so in Adventure mode. I changed the aforementioned values in init.txt and it now runs wonderfully, with the exception of world creation, entering towns, and a very small lag when placing buildings.

My FPS before was only at 100 FPS when paused, usually around 50-65 when playing. Now, I seldom see it anything other than 99 or 100.

My system is as follows:

* Windows XP SP3
* Hard Disk: 83.2 GB free, 140 GB total
* AMD Sempron 3300+ processor
* 448 MB RAM
* In short, [http://h10025.www1.hp.com/ewfrf/wc/document?docname=c00796371&lc=en&dlc=en&cc=us&lang=en&product=3304167 This], bought Dec 15 2006.

== Linux system Requirements? ==
If you run Linux over Windows, does it enhance your FPS any?[[User:Kenji 03|Kenji 03]] 12:30, 2 August 2009 (UTC)

== Benchmarks ==

It would be really useful to use one or more specific fortresses for benchmarking purposes and post them all on DFFD, rather than just including various details which don't include certain vital statistics such as the number of objects, amount of revealed tiles, mid-air Z-levels which have been "allocated" by building into them (such that using "k" actually shows them as "open space" rather than nothing at all), and actual fortress layout (and thus how much CPU time is spent pathfinding). For example, a 2.4GHz Core 2 Duo is listed as handling a minimalist 6x6 site with 95 dwarves at ~20fps, while my 2.4GHz Core 2 Quad was able to support an 8x4 site with magma + pit + underground river + HFS and 200 dwarves and get 20fps with everything turned '''on''' because I had taken care to organize the fortress in such a way as to minimize pathfinding load. --[[User:Quietust|Quietust]] 18:40, 20 January 2010 (UTC)

:I like this idea overall. I don´t think it would be possible to assume what an "average" person builds their fortress like or if they even take pathfinding into account, but a standardized fortress, set of options, DF version, and t/f on use of OpenGL "accelerator" would make this list much more insightful. Unfortunately, it would throw out all previous data collected. If someone has the will and time, I think it would benefit readers, but I think the section does already serve its purpose in giving people a very rough idea of what to expect. In the data I personally posted, I did use the same fort (which paid no attention to optimizing the layout for minimizing pathfinding calculations) but I didn´t think to upload the save and no longer have it.[[User:Kludge|-K]] 03:37, 7 February 2010 (UTC)

== Where do I get the Linux port? ==

Well, the headline basically says it all. It's not linked on the official download page... it took quite a bit of searching until I found anything -- which I don't want to post here, as I don't know whether what I found is in any way recommendable. In a nutshell: the section about the linux port should probably start with '''where to get it'''. --[[Special:Contributions/93.104.144.228|93.104.144.228]] 16:33, 4 February 2010 (UTC)

40d Talk:System requirements

2010-02-07T03:38:42Z

Kludge: /* Where do I get the Linux port? */

== DF Doesn't Need a Fancy GPU ==

Even considering how DF uses OpenGL for graphics, an integrated card should have absolutely no problem displaying 2000 quads on screen.

I threw together a quick and dirty test app to render 2000 dwarf faces, and it can manage 100 FPS with just 18% CPU load. Without throttling I get 600 FPS with 80% CPU. That's on an integrated (GMA x3100) card. So, at least for Intel's GMA cards going back at least two years, the graphics should perform just fine.

So that's why I don't think it should be necessary to recommend a powerful discrete GPU, especially when the screen isn't updated very often.

--[[User:Jcromartie|Jcromartie]] 13:31, 9 May 2008 (EDT)

:It's specifically stated that an old GPU will work just fine. Just a bargain bin 25$ card would be sufficient for the purpose. A '''BIG''' reason for using a separate GPU is the fact that they will share resources, (Shared Memory *and* CPU Cycles,) which will quickly affect performance of the CPU, which DF is quite power-hungry for at this stage, (and many future stages as well I'm sure.) --[[User:N9103|Edward]] 19:39, 9 May 2008 (EDT)

::Not to mention a seperate GPU takes ALL those 2000 quads off the processor. --[[User:Darkone|Darkone]] 20:35, 12 May 2008 (EDT)

== General Performance ==

I may be talking out of my butt here, and as a developer I can understand the challenges of (and reasons to avoid) optimization, but might it be time to start tuning DF? It uses 99% CPU on a 2.2GHz Core 2 Duo ''all the time''. This is even the case when displaying the main menu or when paused.

Maybe [http://www.artima.com/cppsource/how_to_go_slow.html this article] can shed some light on why it uses so much CPU when it doesn't need to?

--[[User:Jcromartie|Jcromartie]] 13:31, 9 May 2008 (EDT)

:I can see where you're coming from, but being that the majority of the game has yet to even be programmed, it's far too early to begin real optimizations. Toady's made a few tweaks to do minor optimizations, so he's got it in mind, so far as it won't interfere with the many core and other items that still need to be added. Over half of the [[http://www.bay12games.com/dwarves/dev_core_1-20.html Core Components]] are still missing, and it's even farther from completion when looking at the [[http://www.bay12games.com/dwarves/dev_req_1-50.html Non-Core Required Components]], a good number of which deal directly with optimization. --[[User:N9103|Edward]] 19:33, 9 May 2008 (EDT)

== Dual Core ==

I believe it may be right to add back in a recommendation, but not for multiple cores but the processor itself. Someone made an erroneous edit in the history stating that a single core is usually faster then a dual- this is wrong, as the Core 2 architecture is ''Far'' more powerful then Pentium, though I do not have data for AMD processors. A Core running at a mere 1.86 gigahertz pulls in a 3000+ benchmark (cinebench) versus the lowly 1800-2000 of a 3 gigahertz pentium 4. Not to mention running DF on its own private core is probably the best thing you could do with it.--[[User:Darkone|Darkone]] 10:45, 12 May 2008 (EDT)

Someone please check if DF might be multi-threaded after all. At least on my machine (q6600) DF quite beautifully
utilizes all four cores with individual loads usually not maxing out (110 dwarves). 1 February 2010

== Small Edit ==

I changed the Mac OsX portion of the page to a more current update.

== init.txt ==

I think there should be some mentions of init.txt here and on [[Maximizing Framerate]]. I found that there was a considerable difference when I changed the init.txt.

I found that, by changing [SOUND], [PARTIAL_PRINT], and [PRIORITY], I was able to significantly increase performance.

While running 66 processes (DF as well), including iTunes, Firefox, Desktop Sidebar, and Last.fm, the game's default init.txt was very poor. It lagged frequently, very much so in Adventure mode. I changed the aforementioned values in init.txt and it now runs wonderfully, with the exception of world creation, entering towns, and a very small lag when placing buildings.

My FPS before was only at 100 FPS when paused, usually around 50-65 when playing. Now, I seldom see it anything other than 99 or 100.

My system is as follows:

* Windows XP SP3
* Hard Disk: 83.2 GB free, 140 GB total
* AMD Sempron 3300+ processor
* 448 MB RAM
* In short, [http://h10025.www1.hp.com/ewfrf/wc/document?docname=c00796371&lc=en&dlc=en&cc=us&lang=en&product=3304167 This], bought Dec 15 2006.

== Linux system Requirements? ==
If you run Linux over Windows, does it enhance your FPS any?[[User:Kenji 03|Kenji 03]] 12:30, 2 August 2009 (UTC)

== Benchmarks ==

It would be really useful to use one or more specific fortresses for benchmarking purposes and post them all on DFFD, rather than just including various details which don't include certain vital statistics such as the number of objects, amount of revealed tiles, mid-air Z-levels which have been "allocated" by building into them (such that using "k" actually shows them as "open space" rather than nothing at all), and actual fortress layout (and thus how much CPU time is spent pathfinding). For example, a 2.4GHz Core 2 Duo is listed as handling a minimalist 6x6 site with 95 dwarves at ~20fps, while my 2.4GHz Core 2 Quad was able to support an 8x4 site with magma + pit + underground river + HFS and 200 dwarves and get 20fps with everything turned '''on''' because I had taken care to organize the fortress in such a way as to minimize pathfinding load. --[[User:Quietust|Quietust]] 18:40, 20 January 2010 (UTC)

:I like this idea overall. I don´t think it would be possible to assume what an "average" person builds their fortress like or if they even take pathfinding into account, but a standardized fortress, set of options, DF version, and t/f on use of OpenGL "accelerator" would make this list much more insightful. Unfortunately, it would throw out all previous data collected. If someone has the will and time, I think it would benefit readers, but I think the section does already serve its purpose in giving people a very rough idea of what to expect. In the data I personally posted, I did use the same fort (which paid no attention to optimizing the layout for minimizing pathfinding calculations) but I didn´t think to upload the save and no longer have it.[[User:Kludge|-K]] 03:37, 7 February 2010 (UTC)

== Where do I get the Linux port? ==

Well, the headline basically says it all. It's not linked on the official download page... it took quite a bit of searching until I found anything -- which I don't want to post here, as I don't know whether what I found is in any way recommendable. In a nutshell: the section about the linux port should probably start with '''where to get it'''. --[[Special:Contributions/93.104.144.228|93.104.144.228]] 16:33, 4 February 2010 (UTC) (a post-post thought -- It´d also be nice to have standardized data since the data could be merged into a pretty table!)

40d Talk:System requirements

2010-02-07T03:37:33Z

Kludge: /* Benchmarks */

== DF Doesn't Need a Fancy GPU ==

Even considering how DF uses OpenGL for graphics, an integrated card should have absolutely no problem displaying 2000 quads on screen.

I threw together a quick and dirty test app to render 2000 dwarf faces, and it can manage 100 FPS with just 18% CPU load. Without throttling I get 600 FPS with 80% CPU. That's on an integrated (GMA x3100) card. So, at least for Intel's GMA cards going back at least two years, the graphics should perform just fine.

So that's why I don't think it should be necessary to recommend a powerful discrete GPU, especially when the screen isn't updated very often.

--[[User:Jcromartie|Jcromartie]] 13:31, 9 May 2008 (EDT)

:It's specifically stated that an old GPU will work just fine. Just a bargain bin 25$ card would be sufficient for the purpose. A '''BIG''' reason for using a separate GPU is the fact that they will share resources, (Shared Memory *and* CPU Cycles,) which will quickly affect performance of the CPU, which DF is quite power-hungry for at this stage, (and many future stages as well I'm sure.) --[[User:N9103|Edward]] 19:39, 9 May 2008 (EDT)

::Not to mention a seperate GPU takes ALL those 2000 quads off the processor. --[[User:Darkone|Darkone]] 20:35, 12 May 2008 (EDT)

== General Performance ==

I may be talking out of my butt here, and as a developer I can understand the challenges of (and reasons to avoid) optimization, but might it be time to start tuning DF? It uses 99% CPU on a 2.2GHz Core 2 Duo ''all the time''. This is even the case when displaying the main menu or when paused.

Maybe [http://www.artima.com/cppsource/how_to_go_slow.html this article] can shed some light on why it uses so much CPU when it doesn't need to?

--[[User:Jcromartie|Jcromartie]] 13:31, 9 May 2008 (EDT)

:I can see where you're coming from, but being that the majority of the game has yet to even be programmed, it's far too early to begin real optimizations. Toady's made a few tweaks to do minor optimizations, so he's got it in mind, so far as it won't interfere with the many core and other items that still need to be added. Over half of the [[http://www.bay12games.com/dwarves/dev_core_1-20.html Core Components]] are still missing, and it's even farther from completion when looking at the [[http://www.bay12games.com/dwarves/dev_req_1-50.html Non-Core Required Components]], a good number of which deal directly with optimization. --[[User:N9103|Edward]] 19:33, 9 May 2008 (EDT)

== Dual Core ==

I believe it may be right to add back in a recommendation, but not for multiple cores but the processor itself. Someone made an erroneous edit in the history stating that a single core is usually faster then a dual- this is wrong, as the Core 2 architecture is ''Far'' more powerful then Pentium, though I do not have data for AMD processors. A Core running at a mere 1.86 gigahertz pulls in a 3000+ benchmark (cinebench) versus the lowly 1800-2000 of a 3 gigahertz pentium 4. Not to mention running DF on its own private core is probably the best thing you could do with it.--[[User:Darkone|Darkone]] 10:45, 12 May 2008 (EDT)

Someone please check if DF might be multi-threaded after all. At least on my machine (q6600) DF quite beautifully
utilizes all four cores with individual loads usually not maxing out (110 dwarves). 1 February 2010

== Small Edit ==

I changed the Mac OsX portion of the page to a more current update.

== init.txt ==

I think there should be some mentions of init.txt here and on [[Maximizing Framerate]]. I found that there was a considerable difference when I changed the init.txt.

I found that, by changing [SOUND], [PARTIAL_PRINT], and [PRIORITY], I was able to significantly increase performance.

While running 66 processes (DF as well), including iTunes, Firefox, Desktop Sidebar, and Last.fm, the game's default init.txt was very poor. It lagged frequently, very much so in Adventure mode. I changed the aforementioned values in init.txt and it now runs wonderfully, with the exception of world creation, entering towns, and a very small lag when placing buildings.

My FPS before was only at 100 FPS when paused, usually around 50-65 when playing. Now, I seldom see it anything other than 99 or 100.

My system is as follows:

* Windows XP SP3
* Hard Disk: 83.2 GB free, 140 GB total
* AMD Sempron 3300+ processor
* 448 MB RAM
* In short, [http://h10025.www1.hp.com/ewfrf/wc/document?docname=c00796371&lc=en&dlc=en&cc=us&lang=en&product=3304167 This], bought Dec 15 2006.

== Linux system Requirements? ==
If you run Linux over Windows, does it enhance your FPS any?[[User:Kenji 03|Kenji 03]] 12:30, 2 August 2009 (UTC)

== Benchmarks ==

It would be really useful to use one or more specific fortresses for benchmarking purposes and post them all on DFFD, rather than just including various details which don't include certain vital statistics such as the number of objects, amount of revealed tiles, mid-air Z-levels which have been "allocated" by building into them (such that using "k" actually shows them as "open space" rather than nothing at all), and actual fortress layout (and thus how much CPU time is spent pathfinding). For example, a 2.4GHz Core 2 Duo is listed as handling a minimalist 6x6 site with 95 dwarves at ~20fps, while my 2.4GHz Core 2 Quad was able to support an 8x4 site with magma + pit + underground river + HFS and 200 dwarves and get 20fps with everything turned '''on''' because I had taken care to organize the fortress in such a way as to minimize pathfinding load. --[[User:Quietust|Quietust]] 18:40, 20 January 2010 (UTC)

:I like this idea overall. I don´t think it would be possible to assume what an "average" person builds their fortress like or if they even take pathfinding into account, but a standardized fortress, set of options, DF version, and t/f on use of OpenGL "accelerator" would make this list much more insightful. Unfortunately, it would throw out all previous data collected. If someone has the will and time, I think it would benefit readers, but I think the section does already serve its purpose in giving people a very rough idea of what to expect. In the data I personally posted, I did use the same fort (which paid no attention to optimizing the layout for minimizing pathfinding calculations) but I didn´t think to upload the save and no longer have it.[[User:Kludge|-K]] 03:37, 7 February 2010 (UTC)

== Where do I get the Linux port? ==

Well, the headline basically says it all. It's not linked on the official download page... it took quite a bit of searching until I found anything -- which I don't want to post here, as I don't know whether what I found is in any way recommendable. In a nutshell: the section about the linux port should probably start with '''where to get it'''. --[[Special:Contributions/93.104.144.228|93.104.144.228]] 16:33, 4 February 2010 (UTC)

40d Talk:System requirements

2010-02-07T03:37:18Z

Kludge: /* Benchmarks */

== DF Doesn't Need a Fancy GPU ==

Even considering how DF uses OpenGL for graphics, an integrated card should have absolutely no problem displaying 2000 quads on screen.

I threw together a quick and dirty test app to render 2000 dwarf faces, and it can manage 100 FPS with just 18% CPU load. Without throttling I get 600 FPS with 80% CPU. That's on an integrated (GMA x3100) card. So, at least for Intel's GMA cards going back at least two years, the graphics should perform just fine.

So that's why I don't think it should be necessary to recommend a powerful discrete GPU, especially when the screen isn't updated very often.

--[[User:Jcromartie|Jcromartie]] 13:31, 9 May 2008 (EDT)

:It's specifically stated that an old GPU will work just fine. Just a bargain bin 25$ card would be sufficient for the purpose. A '''BIG''' reason for using a separate GPU is the fact that they will share resources, (Shared Memory *and* CPU Cycles,) which will quickly affect performance of the CPU, which DF is quite power-hungry for at this stage, (and many future stages as well I'm sure.) --[[User:N9103|Edward]] 19:39, 9 May 2008 (EDT)

::Not to mention a seperate GPU takes ALL those 2000 quads off the processor. --[[User:Darkone|Darkone]] 20:35, 12 May 2008 (EDT)

== General Performance ==

I may be talking out of my butt here, and as a developer I can understand the challenges of (and reasons to avoid) optimization, but might it be time to start tuning DF? It uses 99% CPU on a 2.2GHz Core 2 Duo ''all the time''. This is even the case when displaying the main menu or when paused.

Maybe [http://www.artima.com/cppsource/how_to_go_slow.html this article] can shed some light on why it uses so much CPU when it doesn't need to?

--[[User:Jcromartie|Jcromartie]] 13:31, 9 May 2008 (EDT)

:I can see where you're coming from, but being that the majority of the game has yet to even be programmed, it's far too early to begin real optimizations. Toady's made a few tweaks to do minor optimizations, so he's got it in mind, so far as it won't interfere with the many core and other items that still need to be added. Over half of the [[http://www.bay12games.com/dwarves/dev_core_1-20.html Core Components]] are still missing, and it's even farther from completion when looking at the [[http://www.bay12games.com/dwarves/dev_req_1-50.html Non-Core Required Components]], a good number of which deal directly with optimization. --[[User:N9103|Edward]] 19:33, 9 May 2008 (EDT)

== Dual Core ==

I believe it may be right to add back in a recommendation, but not for multiple cores but the processor itself. Someone made an erroneous edit in the history stating that a single core is usually faster then a dual- this is wrong, as the Core 2 architecture is ''Far'' more powerful then Pentium, though I do not have data for AMD processors. A Core running at a mere 1.86 gigahertz pulls in a 3000+ benchmark (cinebench) versus the lowly 1800-2000 of a 3 gigahertz pentium 4. Not to mention running DF on its own private core is probably the best thing you could do with it.--[[User:Darkone|Darkone]] 10:45, 12 May 2008 (EDT)

Someone please check if DF might be multi-threaded after all. At least on my machine (q6600) DF quite beautifully
utilizes all four cores with individual loads usually not maxing out (110 dwarves). 1 February 2010

== Small Edit ==

I changed the Mac OsX portion of the page to a more current update.

== init.txt ==

I think there should be some mentions of init.txt here and on [[Maximizing Framerate]]. I found that there was a considerable difference when I changed the init.txt.

I found that, by changing [SOUND], [PARTIAL_PRINT], and [PRIORITY], I was able to significantly increase performance.

While running 66 processes (DF as well), including iTunes, Firefox, Desktop Sidebar, and Last.fm, the game's default init.txt was very poor. It lagged frequently, very much so in Adventure mode. I changed the aforementioned values in init.txt and it now runs wonderfully, with the exception of world creation, entering towns, and a very small lag when placing buildings.

My FPS before was only at 100 FPS when paused, usually around 50-65 when playing. Now, I seldom see it anything other than 99 or 100.

My system is as follows:

* Windows XP SP3
* Hard Disk: 83.2 GB free, 140 GB total
* AMD Sempron 3300+ processor
* 448 MB RAM
* In short, [http://h10025.www1.hp.com/ewfrf/wc/document?docname=c00796371&lc=en&dlc=en&cc=us&lang=en&product=3304167 This], bought Dec 15 2006.

== Linux system Requirements? ==
If you run Linux over Windows, does it enhance your FPS any?[[User:Kenji 03|Kenji 03]] 12:30, 2 August 2009 (UTC)

== Benchmarks ==

It would be really useful to use one or more specific fortresses for benchmarking purposes and post them all on DFFD, rather than just including various details which don't include certain vital statistics such as the number of objects, amount of revealed tiles, mid-air Z-levels which have been "allocated" by building into them (such that using "k" actually shows them as "open space" rather than nothing at all), and actual fortress layout (and thus how much CPU time is spent pathfinding). For example, a 2.4GHz Core 2 Duo is listed as handling a minimalist 6x6 site with 95 dwarves at ~20fps, while my 2.4GHz Core 2 Quad was able to support an 8x4 site with magma + pit + underground river + HFS and 200 dwarves and get 20fps with everything turned '''on''' because I had taken care to organize the fortress in such a way as to minimize pathfinding load. --[[User:Quietust|Quietust]] 18:40, 20 January 2010 (UTC)

:I like this idea overall. I don´t think it would be possible to assume what an "average" person builds their fortress like or if they even take pathfinding into account, but a standardized fortress, set of options, DF version, and t/f on use of OpenGL "accelerator" would make this list much more insightful. Unfortunately, it would throw out all previous data collected. If someone has the will and time, I think it would benefit readers, but I think the section does already serve its purpose in giving people a very rough idea of what to expect. In the data I personally posted, I did use the same fort (which paid no attention to optimizing the layout for minimizing pathfinding calculations) but I didn´t think to upload the save and no longer have it.

== Where do I get the Linux port? ==

Well, the headline basically says it all. It's not linked on the official download page... it took quite a bit of searching until I found anything -- which I don't want to post here, as I don't know whether what I found is in any way recommendable. In a nutshell: the section about the linux port should probably start with '''where to get it'''. --[[Special:Contributions/93.104.144.228|93.104.144.228]] 16:33, 4 February 2010 (UTC)

40d:System requirements

2009-12-05T22:49:10Z

Kludge: Removed "Recommended" section. Comparing a 1.4 ghz Core 2 to a 3 ghz Pentium is absurd. Changed wording around to veil the article's 2006 status. Some false/misleading info removed.

''If you're looking for information on improving the performance of Dwarf Fortress on your computer, see [[Maximizing Framerate]].''

General Requirements:

:* Operating System: Requires Windows NT 4.0, Windows 98, or newer ''(If on a non-Windows OS, see [[System requirements#Other Operating Systems]] for information on how to install Dwarf Fortress)''

:* Disk Space: ~100MB. The game itself takes only about 20MB, but savegames and screenshots (if you take them) use considerable amounts of disk space. It is possible to use over a gigabyte of disk space with Dwarf Fortress.

:* RAM: 256MB. The game uses 150+ MB memory while running (more if you select a local grid larger than 6x6). The more creatures, objects, and explored space on your map, the more memory you will need. Most of this can be kept in virtual memory (page file), but be sure to have at least 500MB total (physical + virtual) memory available. [[World generation]] requires 400MB at its peak.

:* CPU: Dwarf Fortress is able to use as much CPU power as you can provide it with. While a Pentium II at 500Mhz is initially sufficient, your frame-rate will substantially decrease as your population increases, among other factors. Keep in mind that Dwarf Fortress will only run on one CPU at a time. There doesn't appear to be any indication that Dwarf Fortress will support multi-threading in the near future.

The larger your map and the more units on it, the harder your computer will need to work. The speed of the simulation depends on the size of the map, the number of entities (dwarves, pets, etc.), the number of levels (mountainous maps have more depth levels), the number of objects and other factors. Modern computers should be able to run 3x3 maps with medium-sized fortresses at 80-100 FPS. Particularly fast processors may be able to handle much larger maps at the same speed.

==Other Operating Systems==
===Linux===
Although DF is a Windows game, it works perfectly in Linux using Wine, as long as you have video drivers with working OpenGL acceleration – for all NVIDIA and newer ATI cards, this means using the vendor's closed source driver. Without 2D acceleration the game runs slow as [[Dwarven syrup]]. Most distributions provide Wine, so consult your distribution-specific documentation for help.

See [http://www.bay12games.com/cgi-local/ultimatebb.cgi?ubb=get_topic&f=2&t=000448 this thread] for tips about Ubuntu and other distributions.

On 24 December, 2008 Toady released the first native Linux version of Dwarf Fortress. It is compiled for 32-bit environments, however, and may not run under 64-bit environments without additional libraries, depending on the Linux distribution.

====Ubuntu/Kubuntu====
Under an Ubuntu/Kubuntu installation one first of all needs the ia32-libs package installed. This is a standard Ubuntu package that contains 32-bit versions of many common libraries. Unfortunately, while it includes 32-bit versions of some SDL libaries, older versions of this package lack SDL_image, which Dwarf Fortress needs.
'''''In Jaunty Jackalope''' (Ubuntu 9.04) this shared library is included in the ia32-libs package and '''you can skip the other steps in this section.'''''

The 32-bit package can be downloaded directly from [http://packages.ubuntu.com/intrepid/i386/libsdl-image1.2/download Ubuntu's package repository]. Once the download is complete, open a console window and navigate to the directory containing the file. Extract the contents by typing:

dpkg-deb -x libsdl-image1.2_1.2.6-3_i386.deb ./libsdl-image

Copy the files from libsdl-image/usr/lib into the df_linux/libs directory and the game should now work.
:If you have extremely low FPS make sure you have turned on your graphics card enabled in the ''Hardware Drivers''.

====Ubuntu/Kubuntu - Using getlibs====
The other way to get the require SDL_image library is to use getlibs, which will get the correct 32bit library when run on 64bit Ubuntu and create all the required links.

At a command prompt:
sudo apt-get install ia32-libs getlibs
sudo getlibs -l libSDL_image-1.2.so.0

The game can now be run from the df_linux folder (or wherever you extracted it to) using the df bash script.

==== Gentoo ====

The required libraries can be pulled from portage before running DF.

For x86, you will need the basic GTK/OpenGL/SDL stuff, plus sdl-image, which means the following packages:

* x11-libs/gtk+:2
* media-libs/libsdl
* media-libs/sdl-image
* virtual/opengl
* virtual/glu

For amd64, you will need the 32-bit emulation libraries instead. Note that sdl-image is already included in the sdl emulation package, so you need:

* app-emulation/emul-linux-x86-sdl
* >=app-emulation/emul-linux-x86-baselibs-20081109 (earlier versions may not provide a 32-bit libgio-2.0.so)
* app-emulation/emul-linux-x86-xlibs
* app-emulation/emul-linux-x86-gtklibs

==== Arch ====

The required libs can be pulled from pacman before running.

If using Gnome, or KDE with some Gnome applications, the following will most likely be installed already:

* gtk2
* libgl
* sdl
* sdl_image

In addition, libtiff (<= 4, to be exact) is also required. Libtiff 4 is not available on Arch. Linking or copying /usr/lib/libtiff.so.3.8.2 to /usr/lib/libtiff.so.4 is sufficient.

The Dwarf Fortress files can be installed with an AUR frontend, or from the AUR itself if so inclined. The current files are at [http://aur.archlinux.org/packages.php?ID=22795 this page.]

At a command prompt:
wget http://aur.archlinux.org/packages/dwarffortress/dwarffortress.tar.gz
tar xvzf dwarffortress.tar.gz
cd dwarffortress
makepkg -s
su
pacman -U dwarffortress-v0.28.181.40d11-5-i686.pkg.tar.gz

===OS X===
A port of Dwarf Fortress to Mac OS X has been completed, and runs on both Intel and PPC based macs. According to the [http://www.bay12games.com/dwarves/ Website]
it requires system 10.3 or later, 100mb of hard drive space, and a minimum of 512mb of ram.

==Optimizing Dwarf Fortress==
You can greatly increase game speed on all systems; details at [[Maximizing framerate]].

==Example results: What you can expect with various machines==

=== Intel Processors ===
'''Celeron M 353 @ 630 mhz, Windows XP(custom optimized), DF v0.27.176.38c:'''
* smallest map possible with the smallest site (2x2, assuming no modding),
* 7 dwarves,
* 12 revealed creatures,
* flatland only 1z above ground, 15z underground, volcano, some lakes, no underground water, speed boosting edits in init.txt,
* 10FPS on fullscreen mode and 20 on window mode,
* play it on a desktop or a better EEE PC. :-(

'''Celeron M @ 900 MHz, Ubuntu-eee 8.04, DF .40d11'''
* 4x4 site,
* 150 dwarves,
* some beginners mistakes in logistics,
* ~5 FPS (Dwarven Syrup)

''' Atom @ 1.6 GHz, Windows XP, DF 40d11'''
* 6x6 site
* 70 ('''non-laboring''') dwarves
* 76 misc (revealed) creatures
* brook, magma pipe, bottomless pit, chasm, HFS, underground river
* HFS & UR are unbreached
* ~70 fps

'''Pentium 4 @ 2.2 GHz, (unknown OS), DF 0.27.169.33g:'''
* 3x3 site,
* ~80 dwarves
* relatively hilly (ten z-levels of elevation change), without magma but with unfrozen brook, no caves, lakes, or monsters; virtually all possible speed-boosting edits in init.txt applied,
* 30-45 FPS (varies) and occasional interface jerkiness is becoming noticeable

'''Core Duo 4400 @ 2 ghz, Windows Vista, DF .38c'''
* 3x3 site,
* 120 dwarves
* <10 roaming animals
* pretty cliffy, volcano, part of river and pretty big artificial pool,
* ~50 fps (~30 when merchants arrive or many hauling jobs start)

'''Core 2 Duo E6600 @ 2.4 ghz, Windows XP SP2, DF 0.28.181.40d16'''
* 6x6 site
* 95 (laboring) dwarves
* cave-ins, temp., weather disabled, no elevation changes at ground-level, no special sites
* 5-40 fps (play capped @ 30 fps, dips frequent, avg @ ~20 fps)

'''Intel Core 2 Duo T5800 @ 2 Ghz, Windows 7 RC, (unknown DF version #)'''
* medium-sized site (assumed ~4x4)
* 151 dwarves
* 170 animals
* around 400 creatures (dwarves + animals + merchants + wildlife)
* brook, magma pipe, HFS, chasm
* 22 z-levels
* 15-25 FPS, (avg @ 20-21 fps)

'''Pentium D 940 @ 3.17 ghz, Windows XP SP2, DF 0.28.181.40d16'''
* 6x6 site
* 95 (laboring) dwarves
* cave-ins, temp., weather disabled, no elevation changes at ground-level, no special sites
* 30-65 fps (play capped @ 50 fps, dips occasionally, avg @ ~40 fps)

=== AMD Processors ===

'''Athlon XP 2200 @ 1.8 ghz, Windows XP, DF .38c'''
* 6x6 site,
* A/V software & Dwarf Foreman running in background,
* slightly upwards slanted hill, human town,
* 35-40 FPS with 17 humans, 38-48 FPS with 7 (Drops to 30-35 with alot of hauling or when viewing 1 z level up)

'''Phenom 9600 @ 2.4 ghz, Windows XP SP2, DF 0.28.181.40d16'''
* 6x6 site
* 95 (laboring) dwarves
* cave-ins, temp., weather disabled, no elevation changes at ground-level, no special sites
* 10-50 fps (play capped @ 40 fps, dips frequent, avg @ ~25 fps)

'''Athlon64X2 5600 @ 2.8GHz, Ubuntu 9.04, DF .40d11'''
* 6x6 site
* 32 dwarves
* lava, wildfires, and flowing water.
* ~100 FPS

'''Phenom II 955 @ 3.5 ghz, Windows XP SP2, DF 0.28.181.40d16'''
* 6x6 site
* 95 (laboring) dwarves
* cave-ins, temp., weather disabled, no elevation changes at ground-level, no special sites
* 45-90 fps (play capped @ 60, rarely dips below max, avg @ ~55 fps)

==See also==
*[[Maximizing framerate]]

[[Category:FAQ]]

40d:System requirements

2009-12-05T22:23:01Z

Kludge: /* Example results: What you can expect with various machines */ -- cleaned (removed irrelevant and/or insignificant data), sorted results, homogenized results, & added my own test results

:* Operating System: Requires Windows NT 4.0, Windows 98, or newer ''(for other OS, see below)''

:* Disk Space: ~100MB. The game itself takes only about 20MB, but savegames and screenshots (if you take them) use considerable amounts of harddisk space. Some users spend over a gigabyte of space with dwarf fortress.

:* RAM: 256MB. The game uses 150+ MB memory while running (more if you select a local grid larger than 6x6). The more creatures, objects, and explored space on your map, the more memory you will need. Most of this can be kept in virtual memory (disk swap), but be sure to have at least 500MB total (physical + virtual) memory available. [[World generation]] requires 400MB at its peak.

:* CPU: Dwarf Fortress loves as much raw CPU power as you can provide it with. A Pentium II 500Mhz is sufficient, but you will not have much fun in late game stages with a lot of population.

Recommended:

::* Core2: 1.4GHz or higher
::* Pentium 4: 3.0GHz or higher
::* Athlon: 3000+ or higher

The larger your map and the more units on it, the harder your computer will need to work (see "optimization", below). Dwarf Fortress will take all the (single-)CPU power it is given. The speed of the simulation depends on the size of the map, the number of entities (dwarves, pets, etc.), the number of levels (mountainous maps have more depth levels), the number of objects and other factors. Modern computers should be able to run 3x3 maps with medium-sized fortresses at 80-100 FPS. Particularly fast processors may be able to handle much larger maps at the same speed.

You'll also want a decent video card to keep up with the CPU, but even a video card that's several years old will satisfy DF under most circumstances.

===Dual-core machines===

If you're running a lot of things at once while playing Dwarf Fortress, open Task Manager and set DF to Core1 and everything else to Core0. You will now have an entire core dedicated to running DF, which should give slightly better performance. Multi-threading support isn't currently implemented.

==Other Operating Systems==
===Linux===
Although DF is a Windows game, it works perfectly in Linux using Wine, as long as you have video drivers with working OpenGL acceleration – for all NVIDIA and newer ATI cards, this means using the vendor's closed source driver. Without 2D acceleration the game runs slow as [[Dwarven syrup]]. Most distributions provide Wine, so consult your distribution-specific documentation for help.

See [http://www.bay12games.com/cgi-local/ultimatebb.cgi?ubb=get_topic&f=2&t=000448 this thread] for tips about Ubuntu and other distributions.

On 24 December, 2008 Toady released the first native Linux version of '''Dwarf Fortress'''. It is compiled for 32-bit environments, however, and may not run under 64-bit environments without additional libraries, depending on the Linux distribution.

====Ubuntu/Kubuntu====
Under an Ubuntu/Kubuntu installation one first of all needs the ia32-libs package installed. This is a standard Ubuntu package that contains 32-bit versions of many common libraries. Unfortunately, while it includes 32-bit versions of some SDL libaries, older versions of this package lack SDL_image, which Dwarf Fortress needs.
'''''In Jaunty Jackalope''' (Ubuntu 9.04) this shared library is included in the ia32-libs package and '''you can skip the other steps in this section.'''''

The 32-bit package can be downloaded directly from [http://packages.ubuntu.com/intrepid/i386/libsdl-image1.2/download Ubuntu's package repository]. Once the download is complete, open a console window and navigate to the directory containing the file. Extract the contents by typing:

dpkg-deb -x libsdl-image1.2_1.2.6-3_i386.deb ./libsdl-image

Copy the files from libsdl-image/usr/lib into the df_linux/libs directory and the game should now work.
:If you have extremely low FPS make sure you have turned on your graphics card enabled in the ''Hardware Drivers''.

====Ubuntu/Kubuntu - Using getlibs====
The other way to get the require SDL_image library is to use getlibs, which will get the correct 32bit library when run on 64bit Ubuntu and create all the required links.

At a command prompt:
sudo apt-get install ia32-libs getlibs
sudo getlibs -l libSDL_image-1.2.so.0

The game can now be run from the df_linux folder (or wherever you extracted it to) using the df bash script.

==== Gentoo ====

The required libraries can be pulled from portage before running DF.

For x86, you will need the basic GTK/OpenGL/SDL stuff, plus sdl-image, which means the following packages:

* x11-libs/gtk+:2
* media-libs/libsdl
* media-libs/sdl-image
* virtual/opengl
* virtual/glu

For amd64, you will need the 32-bit emulation libraries instead. Note that sdl-image is already included in the sdl emulation package, so you need:

* app-emulation/emul-linux-x86-sdl
* >=app-emulation/emul-linux-x86-baselibs-20081109 (earlier versions may not provide a 32-bit libgio-2.0.so)
* app-emulation/emul-linux-x86-xlibs
* app-emulation/emul-linux-x86-gtklibs

==== Arch ====

The required libs can be pulled from pacman before running.

If using Gnome, or KDE with some Gnome applications, the following will most likely be installed already:

* gtk2
* libgl
* sdl
* sdl_image

In addition, libtiff (<= 4, to be exact) is also required. Libtiff 4 is not available on Arch. Linking or copying /usr/lib/libtiff.so.3.8.2 to /usr/lib/libtiff.so.4 is sufficient.

The Dwarf Fortress files can be installed with an AUR frontend, or from the AUR itself if so inclined. The current files are at [http://aur.archlinux.org/packages.php?ID=22795 this page.]

At a command prompt:
wget http://aur.archlinux.org/packages/dwarffortress/dwarffortress.tar.gz
tar xvzf dwarffortress.tar.gz
cd dwarffortress
makepkg -s
su
pacman -U dwarffortress-v0.28.181.40d11-5-i686.pkg.tar.gz

===OS X===
A port of Dwarf Fortress to Mac OS X has been completed, and runs on both Intel and PPC based macs. According to the [http://www.bay12games.com/dwarves/ Website]
it requires system 10.3 or later, 100mb of hard drive space, and a minimum of 512mb of ram.

==Optimizing Dwarf Fortress==
You can greatly increase game speed on all systems; details at [[Maximizing framerate]].

==Example results: What you can expect with various machines==

=== Intel Processors ===
'''Celeron M 353 @ 630 mhz, Windows XP(custom optimized), DF v0.27.176.38c:'''
* smallest map possible with the smallest site (2x2, assuming no modding),
* 7 dwarves,
* 12 revealed creatures,
* flatland only 1z above ground, 15z underground, volcano, some lakes, no underground water, speed boosting edits in init.txt,
* 10FPS on fullscreen mode and 20 on window mode,
* play it on a desktop or a better EEE PC. :-(

'''Celeron M @ 900 MHz, Ubuntu-eee 8.04, DF .40d11'''
* 4x4 site,
* 150 dwarves,
* some beginners mistakes in logistics,
* ~5 FPS (Dwarven Syrup)

''' Atom @ 1.6 GHz, Windows XP, DF 40d11'''
* 6x6 site
* 70 ('''non-laboring''') dwarves
* 76 misc (revealed) creatures
* brook, magma pipe, bottomless pit, chasm, HFS, underground river
* HFS & UR are unbreached
* ~70 fps

'''Pentium 4 @ 2.2 GHz, (unknown OS), DF 0.27.169.33g:'''
* 3x3 site,
* ~80 dwarves
* relatively hilly (ten z-levels of elevation change), without magma but with unfrozen brook, no caves, lakes, or monsters; virtually all possible speed-boosting edits in init.txt applied,
* 30-45 FPS (varies) and occasional interface jerkiness is becoming noticeable

'''Core Duo 4400 @ 2 ghz, Windows Vista, DF .38c'''
* 3x3 site,
* 120 dwarves
* <10 roaming animals
* pretty cliffy, volcano, part of river and pretty big artificial pool,
* ~50 fps (~30 when merchants arrive or many hauling jobs start)

'''Core 2 Duo E6600 @ 2.4 ghz, Windows XP SP2, DF 0.28.181.40d16'''
* 6x6 site
* 95 (laboring) dwarves
* cave-ins, temp., weather disabled, no elevation changes at ground-level, no special sites
* 5-40 fps (play capped @ 30 fps, dips frequent, avg @ ~20 fps)

'''Intel Core 2 Duo T5800 @ 2 Ghz, Windows 7 RC, (unknown DF version #)'''
* medium-sized site (assumed ~4x4)
* 151 dwarves
* 170 animals
* around 400 creatures (dwarves + animals + merchants + wildlife)
* brook, magma pipe, HFS, chasm
* 22 z-levels
* 15-25 FPS, (avg @ 20-21 fps)

'''Pentium D 940 @ 3.17 ghz, Windows XP SP2, DF 0.28.181.40d16'''
* 6x6 site
* 95 (laboring) dwarves
* cave-ins, temp., weather disabled, no elevation changes at ground-level, no special sites
* 30-65 fps (play capped @ 50 fps, dips occasionally, avg @ ~40 fps)

=== AMD Processors ===

'''Athlon XP 2200 @ 1.8 ghz, Windows XP, DF .38c'''
* 6x6 site,
* A/V software & Dwarf Foreman running in background,
* slightly upwards slanted hill, human town,
* 35-40 FPS with 17 humans, 38-48 FPS with 7 (Drops to 30-35 with alot of hauling or when viewing 1 z level up)

'''Phenom 9600 @ 2.4 ghz, Windows XP SP2, DF 0.28.181.40d16'''
* 6x6 site
* 95 (laboring) dwarves
* cave-ins, temp., weather disabled, no elevation changes at ground-level, no special sites
* 10-50 fps (play capped @ 40 fps, dips frequent, avg @ ~25 fps)

'''Athlon64X2 5600 @ 2.8GHz, Ubuntu 9.04, DF .40d11'''
* 6x6 site
* 32 dwarves
* lava, wildfires, and flowing water.
* ~100 FPS

'''Phenom II 955 @ 3.5 ghz, Windows XP SP2, DF 0.28.181.40d16'''
* 6x6 site
* 95 (laboring) dwarves
* cave-ins, temp., weather disabled, no elevation changes at ground-level, no special sites
* 45-90 fps (play capped @ 60, rarely dips below max, avg @ ~55 fps)

==See also==
*[[Maximizing framerate]]

[[Category:FAQ]]