Don't build such large farm plots and don't go overboard with multiple workshops constantly queued or set on perpetual repeat. The obvious solution is not to generate so many items in the first place.Fewer items inside a fort means fewer items to be stockpiled, checked for wear, and so on and so forth.You need at least 1 cavern layer to get underground plants, and 2 caverns to get all the underground trees. World size probably doesn't matter except for the size of the save files, but reducing the number of cavern layers (default of 3) will help.
The Nano Fortress utility will let you play on a 1x1 title, which will result in exceptionally improved frame rate. Keep in mind that a 2x2 embark is only 25% of the size of a 4x4. Reducing the size of your embark site from the default 4x4 squares to 3x3 or even 2x2 will have an enormous impact on FPS. Larger embark sites dramatically increase the amount of terrain which DF needs to keep track of and path through. The below lists separate ways to improve FPS into two categories: things that don't change the game in any fundamental way, and things that do.įortress design is specific ways of building and planning, game setting changes are changes mostly in the init and init_d files that don't actually change how the game plays out. So, reducing the amount of stuff active keeps your game running fast. It is also worth noting that the actuall thread/process switch is QUITE COSTLY operation.In general, the more stuff the game has to keep track of, the slower the game will run. I'm not sure how well that will work, given that system processes probably don't care about user settings anyway (might vary on UNIX based OS). The only "reasonable" way would be to set ALL processes to CPU 0, and ONLY DF to CPU 1. By limiting scheduler to one core only, it might fuck up the algorithms and make it in fact slower. So there's no guarantee in which order, if ever, will given process run. Now, the schedulers do all crazy stuff predicting what application should run in order to satisfy you the best (as in, it has some priorities, pick recently used apps more often or whatever). Even if CPU 1 is idle, it will wait for CPU 0 to finish the job and possibly switch over. But there will still be 29 other processes sharing the core. If you set affinity of one process (DF) to CPU 0, the only thing you'll acomplish is, it will always be scheduled on CPU 0. So now you have 60 processes, so that's 30 per core, say 20 switches per second (depends highly on architecture and OS). The processes switch so fast you can't even notice it, that's why it works well with humans :P The program wouldn't care if it was given one second every minute, but you'd be quite uncomfortable with that. :no_upscale()/cdn.vox-cdn.com/uploads/chorus_asset/file/24253537/Dwarf_Fortress_embark_location.png "dwarf fortress embark size not changing paramaters")
The way processor sharing work is, each process gets some time on the CPU, say, 50 ms (miliseconds). Assuming you run windows, there might be around 30 to 60 processes running on your machine (mine have usually about 75). Well, you can try it yourself, so rumors should not be problem. Kitfox Discord #modding-discussion channelīronzemurder and Oilfurnace (illustrated)
#Dwarf fortress embark size not changing paramaters install#
A three step guide:ĭownload DF Classic or install the premium version from Steam or Itch.ioįollow the quickstart guide on the wiki, or see other learning resources (below)Īsk any questions in the ☼Bi-weekly DF Questions Thread☼ - it's always active See the reasons for our rules here, and please report any problems!ĭF can be intimidating, but we're dedicated to helping new players. Updates and releases will still be posted, as will the questions thread for those needing help. Please note, the subreddit is currently closed to new user submissions, as part of the ongoing Reddit fiasco. Want to start playing? Read this sidebar!
0 kommentar(er)
