v50 Steam/Premium information for editors
  • v50 information can now be added to pages in the main namespace. v0.47 information can still be found in the DF2014 namespace. See here for more details on the new versioning policy.
  • Use this page to report any issues related to the migration.
This notice may be cached—the current version can be found here.

Difference between revisions of "40d Talk:Maximizing framerate"

From Dwarf Fortress Wiki
Jump to navigation Jump to search
(Using DF Mac)
 
(7 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== 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 ==
 
== Effect on # of dwarves, framerate calculations ==
  
Line 141: Line 138:
  
 
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)
 
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 ==
 
== Small Worlds ==
Line 146: Line 145:
 
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)
 
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)
 
: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.
 +
 +
== Random Flickering? ==
 +
 +
I've found that if the G-FPS is set to below 40 i get a severe flickering which affects the use of lists (like military and unit lists) I'm wondering if anyone else has experienced this or if its just something with my computer...[[User:Haydosss|Haydosss]]Haydosss - 20-2-2010

Latest revision as of 14:25, 3 April 2010

Effect on # of dwarves, framerate calculations[edit]

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. 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. 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... --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. Milskidasith 22:18, 11 November 2008 (EST)

Weather and Trees[edit]

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. 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. --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. --BurnedToast 00:00, 4 January 2008 (EST)
N9103, logic has no place here. Begone! --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! --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. --Edward 19:05, 2 April 2008 (EDT)

Economy[edit]

Can we confirm/disprove the effect of the economy on framerate? --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? 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? --n9103 11:27, 17 Dec 2007 (PST)

One Way Stairs[edit]

"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. 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) 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)? --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.Fedor 22:52, 3 January 2008 (EST)
What would cause a dwarf to fall down stairs aside from combat?--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.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. --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.) unsigned comment by 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. ~ Midna 02:11, 9 December 2009 (UTC)

Weather and windmills[edit]

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. --SL 13:24, 9 January 2008 (EST)

Multiple CPUs/Cores[edit]

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. Soulwynd 23:37, 17 March 2008 (EDT)

Bulging Histories[edit]

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. Weasello 12:43, 21 March 2008 (EDT)

Well... from that data, that's likely. Personally, I play all my forts on separate worlds. --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. --Edward 19:04, 2 April 2008 (EDT)

Disconnection[edit]

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.
--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.--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. --Edward 04:04, 4 April 2008 (EDT)
I have invasions on, although any attackers have died rather quickly.--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.--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."--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. --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.--Eurytus 11:23, 4 April 2008 (EST)
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. --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. [1] --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. --Jurph 18:01, 8 April 2009 (UTC)

Dual Screens[edit]

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. unsigned comment by 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 --~~~~. --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. --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. Random832 10:31, 14 October 2008 (EDT)

temperature[edit]

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. --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.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? 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. --Elvang 21:00, 18 February 2009 (EST)

New 40d# releases and the Acceleration program[edit]

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? --Sinergistic 00:24, 6 January 2009 (EST)

Turn Mouse Support Off[edit]

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. -K 23:51, 9 February 2010 (UTC)

Small Worlds[edit]

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. 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. Shardok 00:06, 25 August 2009 (UTC)

Peasant cancels Rest: Interrupted by recruit[edit]

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.

Random Flickering?[edit]

I've found that if the G-FPS is set to below 40 i get a severe flickering which affects the use of lists (like military and unit lists) I'm wondering if anyone else has experienced this or if its just something with my computer...HaydosssHaydosss - 20-2-2010