Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[KaelGotDwarves]

People are obviously playing the game, which isn't to say that it wouldn't be nice if DF ran faster.

I think he didn't mean literally unplayable, but if a game runs at 20-30 fps on most modern or semi-modern rigs, then it's a disaster.

unpaused (rubberbands quite a bit, can be higher)

paused (max fps eliminated, rubberbands a lot, can be higher)

This was research I did on a previous thread testing fps performance in base DF, that is, no init performance boosts. Granted my computer is better than most, but some people would do well to choose a smaller map, limit the amount of dwarves, and tweak their init file. There's running water and magma on the map as well. To note, 600+ fps is unplayable, because DF cycles way too fast and you can't tell what's going on and the season's already changed.

I run the rather large Halltraded succession game from the DFFD at 120ish fps standard. This goes higher if dwarves are doing nothing and drops if there's a siege or ambush. There are hundreds of creatures involved.

Does fps slow down with old fortresses with 500k rock and if you cheat to embark with 30+ wagons, 300+ dwarves, have a catplosion... yes it does.

Toady does not have a computer like mine, in fact, it's closer to lower-mid range. Be secure with the knowledge that if DF were truly "unplayable" he would know.

I guess the point I'm trying to make keeping in mind that other forums like SA and facepunch say Bay12 doesn't tolerate criticism of DF or Toady- Well, as much as all of you we wish DF ran faster so we can embark on 20x20 spaces and build epic city-state fortresses of 1000+ dwarves. The d# series is a triumph of the community working with Toady to address the shortfalls of the openGL display.

But keeping in mind constructive criticism and achievable results -sticking to my first posts in this thread - why don't you change your embark habits and init if the game is running slow? http://dwarffortresswiki.net/index.php/Maximizing_framerate Instead of just throwing out examples of FUSION and CUDA, why not attempt to work with the 'pathfinder project', those that have had the experience of working with Toady? I'm rather astounded by the amount of people that keep suggesting something as inviable as multi-threading at this moment, or what appears to be the snobby elitism of a few programmers either demanding that this free game paid by donations should be open-source or the code is horribly unoptimized without:
1. having seen the code.
2. programming anything nearly as complex as DF

When I've read parts of the threads on SA, 4chan, Penny Arcade, Facepunch (probably more I'm forgetting) and someone invariably posts with that attitude and I'm struck by how concern-trollish it is.

[assimilateur]

Does fps slow down with old fortresses with 500k rock and if you cheat to embark with 30+ wagons, 300+ dwarves, have a catplosion... yes it does.

Does fps slow down with 2- or 3-year fortresses, with 10k rock and if you don't cheat, have no cats, and embark on a 4x4 site... yes it does. Not for you perhaps, but for a great number of people.

Toady does not have a computer like mine, in fact, it's closer to lower-mid range. Be secure with the knowledge that if DF were truly "unplayable" he would know.

One lower-mid range computer is not like the other. On mine, it's bordering on the unplayable (I said bordering, because I'm ultimately able to put up with 20-25 fps, but that will change if it goes any lower); if it runs well on his, then I guess I can congratulate him.


You see, I can understand that this game runs as slow as it does. It's a very complicated one-man project. What I do have a problem is with people sugarcoating this fact. I mean, you made it sound as though it were possible for everyone to get reasonable speeds, while being able to enjoy DF (I mean, I probably would get better FPS if I embarked on a 2x2 wasteland with no water or magma, and never produced more than a couple of beds and basic food, but why would I want to play such a game?), when clearly the performance of this game is ridiculous on most machines.

[KaelGotDwarves]

If you post a copy of your init file in spoiler codes here, I'd be happy to take the time to go through it and see where we can help your fps. I used to play DF on my laptop which rumbled at 15 fps on large forts, so I feel your pain.

[assimilateur]

I appreciate the offer. You might be able to figure something out, but I'm not holding my breath. Two things:

1. I've experimented with different print modes. It seems to run a bit better with what I've got there, namely partial print:5 with single buffer (IIRC I had experienced flickering without said single buffer enabled).

2. I know weather and temperature are supposed to be resource hogs, but the last time my fort slumped to around 20 fps, disabling them made little difference. In the case of temperature, I had a very choppy or stuttering experience where it would rubberband between like 20 and 50 fps constantly, being even more irritating that a constantly low framerate.

Spoiler (click to show/hide)

Change this to turn sound off.

[SOUND:OFF]

The sound volume runs from 0 (off) to 255 (full).  You can set the volume from the ESC options menu as well.

[VOLUME:255]

Change this to skip the wonderful intro movies.

[INTRO:OFF]

This lets you set the starting windowed/fullscreen setting.  Can be YES, NO or PROMPT.

[WINDOWED:NO]

This is the size and font for windowed mode.  Changing to 800x600 and the 800x600 font might make you happier.

[WINDOWEDX:640]
[WINDOWEDY:300]
[FONT:curses_640x300.png]

Full screen info.  The 0s below mean that the game will choose a resolution for you, but you can set it yourself as well.

[FULLSCREENX:1280]
[FULLSCREENY:1024]
[FULLFONT:curses_640x300.png]

If this is set to NO, tiles will be stretched to fit the screen if there is a resolution mismatch.
If this is set to YES, the tiles will not be stretched, but rather the game view will be centralized, surrounded by black space.  Tiles that are too large will always be compressed rather than running off the screen.

[BLACK_SPACE:YES]

Graphics info, most of it as above.  Set GRAPHICS to YES to turn it all on.  This will use the "raw/graphics" folder for tile information.  Currently this is limited to whatever creature graphics you have downloaded.  The game comes with a few pictures to demonstrate.  As of September 2008, the Dwarf Fortress Wiki has graphical tilesets available at http://www.dwarffortresswiki.net/index.php/List_of_user_graphics_sets.

[GRAPHICS:YES]
[GRAPHICS_WINDOWEDX:1280]
[GRAPHICS_WINDOWEDY:400]
[GRAPHICS_FONT:mayday.png]
[GRAPHICS_FULLSCREENX:1280]
[GRAPHICS_FULLSCREENY:1024]
[GRAPHICS_FULLFONT:mayday.png]
[GRAPHICS_BLACK_SPACE:YES]

These settings can have a significant impact on frame rate, especially for people that have slow frame rates on the title screen.  Available modes are STANDARD, PARTIAL:<number>, ACCUM_BUFFER, FRAME_BUFFER and VBO.  The number after PARTIAL refers to how many frames it will redo a printed tile before skipping it, so you might try increasing it a bit if you have flickering when PARTIAL is set.  Please note that any of these combinations might cause frame rates to drop significantly or cause unpleasant side effects like flickering.

[PRINT_MODE:PARTIAL:5]
[SINGLE_BUFFER:YES]

Change this to YES to keep the DF window on top of your other windows.

[TOPMOST:NO]

Change this to YES if you want to see an FPS counter at the top left.

[FPS:YES]

Use this to set the maximum frame rate during play.  The movies are always capped at 100.  A frame in this case is not graphical but related to the movement speed of a creature.  A healthy, unencumbered dwarven peasant takes one step every 10 frames.

[FPS_CAP:100]

Use this to set the maximum graphical frame refresh rate during play.

[G_FPS_CAP:20]

This sets the applications vertical synchronization behavior.  Changing this to ON can impact your FPS if your G_FPS is high.  The other options are ON and DEFAULT.  DEFAULT uses whatever settings you have your system at in general.

[VSYNC:OFF]

Change this to NEAREST if you want the texture values to use the nearest pixel without averaging.
Change this to LINEAR if you want the texture values to be averaged over the adjacent pixels.

[TEXTURE_PARAM:NEAREST]

Change this to make the dwarfort.exe process have a different priority.  From highest to lowest, the options are REALTIME, HIGH, ABOVE_NORMAL, NORMAL, BELOW_NORMAL and IDLE.

[PRIORITY:NORMAL]

Use this to set how fast the game zooms.  The default corresponds to multiplying by a factor of 1.1 each time the zoom action occurs.  You can set it anywhere from 1.001 to 1.999.

[ZOOM_FACTOR:1.999]

Change this to NO if you don't want to have the mouse involved at all.

[MOUSE:YES]

Change this to YES if you'd like to use a BMP for the mouse cursor.  The image currently lags when the game is lagging however.

[MOUSE_PICTURE:NO]

Use these to control the automatic saving behavior in the dwarf fortress mode of game.  AUTOSAVE can be set to NONE, SEASONAL or YEARLY.  This updates your save at these intervals, so that some of your progress will be saved in case of system instability.  You can set AUTOBACKUP to YES if you want the updated save to be copied to another folder so that you'll have several copies of your world at different times.  Set AUTOSAVE_PAUSE to YES if you want the game to pause every time it autosaves.

[AUTOSAVE:SEASONAL]
[AUTOBACKUP:YES]
[AUTOSAVE_PAUSE:NO]

Set this to YES if you want it to save the game when you start a new fortress.  If AUTOBACKUP above is set to YES, it will also create a copy of this new save.

[INITIAL_SAVE:YES]

Set this to YES to make Dwarf Fortress start paused whenever you load an active game.

[PAUSE_ON_LOAD:YES]

Set this to YES if you want Dwarf Fortress to show the warning window on embark as a confirmation even if there are no issues.

[EMBARK_WARNING_ALWAYS:YES]

You can change these to ALWAYS and NO.  More restrictive world parameter settings override these.  ALWAYS lets you see the features in the Local view during embark, and NO stops you from looking for features in the site finder (though if you really want to stop the finder, it might be better for you to generate worlds that restrict the use of this feature completely, in which case you don't need to change the settings here).

[SHOW_EMBARK_RIVER:ALWAYS]
[SHOW_EMBARK_POOL:ALWAYS]
[SHOW_EMBARK_M_PIPE:ALWAYS]
[SHOW_EMBARK_M_POOL:ALWAYS]
[SHOW_EMBARK_CHASM:ALWAYS]
[SHOW_EMBARK_PIT:ALWAYS]
[SHOW_EMBARK_OTHER:ALWAYS]
[SHOW_EMBARK_TUNNEL:ALWAYS]

Use these options to remove features from the game.  Permitted values are YES and NO.  Removal might speed the game up in the case of temperature and weather.

[TEMPERATURE:YES]
[WEATHER:YES]
[ECONOMY:NO]
[INVADERS:YES]
[CAVEINS:YES]
[ARTIFACTS:YES]
[ZERO_RENT:YES]

Change this to YES to output the reasons for world map rejection into a file.

[LOG_MAP_REJECTS:NO]

Change these numbers to make the embark rectangle start at a different size.  The format is (EMBARK_RECTANGLE:<width>:<height>).  Numbers may run from 2 to 16.  The map size warning message will go by these numbers.

[EMBARK_RECTANGLE:4:4]

Change these numbers to set the default weights for traffic designations.  If you make the last numbers too large, pathfinding might lag.
The format is (PATH_COST:<high>:<normal>:<low>:<restricted>).

[PATH_COST:1:2:5:25]

Alter these options to control how aggressively your dwarves place objects in a container with like items (rather than an empty container).  The default options are very aggressive.  STORE_DIST_ITEM_DECREASE controls the cap on objects it will consider -- for each object it finds in a container, one tile is removed from its apparent distance to the dwarf, up to this cap.  The others control how many tiles are removed for each combination type for any match at all.  For instance, if ITEM_DECREASE is set to 20, and SEED_COMBINE is set to 100, a dwarf carrying seeds will see a seed bag with 15 seeds as 115 tiles closer than it actually is (and thus pass up any empties within that distance), whereas a seed bag with 30 seeds would be treated as 120 tiles closer (because it hits the ITEM_DECREASE cap).  Values from 2 to 1000 are permitted.  Before these init options, the behavior was roughly ITEM_DECREASE 2, SEED_COMBINE 2 and the rest at 1000.

[STORE_DIST_ITEM_DECREASE:20]
[STORE_DIST_SEED_COMBINE:1000]
[STORE_DIST_BUCKET_COMBINE:1000]
[STORE_DIST_BARREL_COMBINE:1000]
[STORE_DIST_BIN_COMBINE:1000]

Change this to YES to disallow pets from coffin burial as the default option.

[COFFIN_NO_PETS_DEFAULT:NO]

This controls the display of areas that are far below outside.  The format is SKY:<character>:<foreground color>:<background color>:<brightness>.  The <character> can be either an ASCII tile number or a character in quotes, like '#'.

[SKY:178:3:0:0]

As above, for inside/subterranean areas.

[CHASM:250:0:0:1]

This controls the "IDLERS: <number>" that is displayed in dwarf mode.  You can set it to TOP, BOTTOM or OFF.

[IDLERS:TOP]

You can set the maximum population of your fortress here.  Keep in mind that your population must be at least 80 to get a king and 100 to obtain the current game features.

[POPULATION_CAP:40]

This allows you to control the number of babies+children in your fortress.  The first number is an absolute cap on the number of babies+children.  The second is a percentage of the current number of adults in your fortress (the default is the essentially meaningless 1000% here).  The lower number is used as the cap.  The cap only prevents further pregancies, so migrant children, multiple births and existing pregnancies from old saves can still push you over the cap.  Setting either number to zero will disallow pregnancies in the fortress.

[BABY_CHILD_CAP:0:0]

If you don't like the ,.`' ground, try setting this to NO.  The ground will turn into periods only.

[VARIED_GROUND_TILES:YES]

If you'd like your engravings to start off looking the same (you can toggle them on individual later), set this to YES.

[ENGRAVINGS_START_OBSCURED:YES]

If you get annoyed by seeing items like *<*sword*>* you can
get rid of the outside ** by setting this to NO.

[SHOW_IMP_QUALITY:YES]

Set this to YES to display fluids as numbers indicating depth.

[SHOW_FLOW_AMOUNTS:NO]

If you'd prefer to have it show the history behind every engraving you view in dwarf mode, etc., then set this to YES.

[SHOW_ALL_HISTORY_IN_DWARF_MODE:YES]

This controls the number of milliseconds that must pass before a held key sends an initial repeat press to the game.  You might need to adjust this.

[KEY_HOLD_MS:150]

This controls the number of milliseconds that must pass before a held key sends a repeat press to the game after the repeat process has begun.

[KEY_REPEAT_MS:150]

This controls the number of milliseconds between macro instructions.

[MACRO_MS:1]

This controls the number of milliseconds that must pass before input works again after the view recenters on an event in dwarf mode.

[RECENTER_INTERFACE_SHUTDOWN_MS:0]

This controls "more" in adventure mode.  If MORE is set to NO, all announcements will be skipped.  DISPLAY_LENGTH controls how many lines are printed before it gives you the "more" prompt.

[MORE:YES]
[DISPLAY_LENGTH:23]

Set this to YES if you want traps to affect you in adventure mode.  This is not recommended -- there are lockup issues with cage traps, and you cannot disarm any of the traps yet, so they effectively stops you from exploring your old fortresses.

[ADVENTURER_TRAPS:NO]

Set this to NO if you want the game to recenter on your adventurer only when you've gotten close to the edge of the view.

[ADVENTURER_ALWAYS_CENTER:YES]

This controls the up/down views in adventure mode.  The first parameter can be OFF, UNHIDDEN, CREATURE or ON.  UNHIDDEN makes the view appear when it contains any unhidden square.  CREATURE makes the view appear when it contains a creature.  The second parameter is the size of the view.  It can be 3, 5, 7 or 9.  A smaller view lets it stack more of them in the column (3 at size 5, and 5 at size 3).

[ADVENTURER_Z_VIEWS:UNHIDDEN:9]

You can use these to say how nicknames are displayed in each mode
Options are REPLACE_FIRST, CENTRALIZE (between first and last), REPLACE_ALL
[NICKNAME_DWARF:REPLACE_FIRST]
[NICKNAME_ADVENTURE:REPLACE_FIRST]
[NICKNAME_LEGENDS:REPLACE_FIRST]

These are the display colors in RGB.  The game is actually displaying extended ASCII characters in OpenGL, so you can modify the colors.

[BLACK_R:0]
[BLACK_G:0]
[BLACK_B:0]

[BLUE_R:30]
[BLUE_G:50]
[BLUE_B:168]

[GREEN_R:96]
[GREEN_G:170]
[GREEN_B:0]

[CYAN_R:0]
[CYAN_G:128]
[CYAN_B:140]

[RED_R:200]
[RED_G:20]
[RED_B:0]

[MAGENTA_R:128]
[MAGENTA_G:50]
[MAGENTA_B:200]

[BROWN_R:140]
[BROWN_G:98]
[BROWN_B:56]

[LGRAY_R:192]
[LGRAY_G:192]
[LGRAY_B:192]

[DGRAY_R:128]
[DGRAY_G:128]
[DGRAY_B:128]

[LBLUE_R:0]
[LBLUE_G:120]
[LBLUE_B:255]

[LGREEN_R:134]
[LGREEN_G:213]
[LGREEN_B:0]

[LCYAN_R:0]
[LCYAN_G:200]
[LCYAN_B:255]

[LRED_R:255]
[LRED_G:50]
[LRED_B:0]

[LMAGENTA_R:210]
[LMAGENTA_G:10]
[LMAGENTA_B:255]

[YELLOW_R:255]
[YELLOW_G:232]
[YELLOW_B:76]

[WHITE_R:255]
[WHITE_G:250]
[WHITE_B:230]

[KaelGotDwarves]

Spoiler (click to show/hide)

Change this to turn sound off.

[SOUND:OFF]

The sound volume runs from 0 (off) to 255 (full).  You can set the volume from the ESC options menu as well.

[VOLUME:0]

Change this to skip the wonderful intro movies.

[INTRO:OFF]

This lets you set the starting windowed/fullscreen setting.  Can be YES, NO or PROMPT.

[WINDOWED:NO]

This is the size and font for windowed mode.  Changing to 800x600 and the 800x600 font might make you happier.

[WINDOWEDX:640]
[WINDOWEDY:300]
[FONT:curses_640x300.png]

Full screen info.  The 0s below mean that the game will choose a resolution for you, but you can set it yourself as well.

[FULLSCREENX:1280]
[FULLSCREENY:1024]
[FULLFONT:curses_640x300.png]

If this is set to NO, tiles will be stretched to fit the screen if there is a resolution mismatch.
If this is set to YES, the tiles will not be stretched, but rather the game view will be centralized, surrounded by black space.  Tiles that are too large will always be compressed rather than running off the screen.

[BLACK_SPACE:YES]

Graphics info, most of it as above.  Set GRAPHICS to YES to turn it all on.  This will use the "raw/graphics" folder for tile information.  Currently this is limited to whatever creature graphics you have downloaded.  The game comes with a few pictures to demonstrate.  As of September 2008, the Dwarf Fortress Wiki has graphical tilesets available at http://www.dwarffortresswiki.net/index.php/List_of_user_graphics_sets.

[GRAPHICS:YES]
[GRAPHICS_WINDOWEDX:1280]
[GRAPHICS_WINDOWEDY:400]
[GRAPHICS_FONT:mayday.png]
[GRAPHICS_FULLSCREENX:1280]
[GRAPHICS_FULLSCREENY:1024]
[GRAPHICS_FULLFONT:mayday.png]
[GRAPHICS_BLACK_SPACE:YES]

These settings can have a significant impact on frame rate, especially for people that have slow frame rates on the title screen.  Available modes are STANDARD, PARTIAL:<number>, ACCUM_BUFFER, FRAME_BUFFER and VBO.  The number after PARTIAL refers to how many frames it will redo a printed tile before skipping it, so you might try increasing it a bit if you have flickering when PARTIAL is set.  Please note that any of these combinations might cause frame rates to drop significantly or cause unpleasant side effects like flickering.

[PRINT_MODE:PARTIAL:10]
[SINGLE_BUFFER:NO]

Change this to YES to keep the DF window on top of your other windows.

[TOPMOST:NO]

Change this to YES if you want to see an FPS counter at the top left.

[FPS:YES]

Use this to set the maximum frame rate during play.  The movies are always capped at 100.  A frame in this case is not graphical but related to the movement speed of a creature.  A healthy, unencumbered dwarven peasant takes one step every 10 frames.

[FPS_CAP:100]

Use this to set the maximum graphical frame refresh rate during play.

[G_FPS_CAP:10]

This sets the applications vertical synchronization behavior.  Changing this to ON can impact your FPS if your G_FPS is high.  The other options are ON and DEFAULT.  DEFAULT uses whatever settings you have your system at in general.

[VSYNC:OFF]

Change this to NEAREST if you want the texture values to use the nearest pixel without averaging.
Change this to LINEAR if you want the texture values to be averaged over the adjacent pixels.

[TEXTURE_PARAM:NEAREST]

Change this to make the dwarfort.exe process have a different priority.  From highest to lowest, the options are REALTIME, HIGH, ABOVE_NORMAL, NORMAL, BELOW_NORMAL and IDLE.

[PRIORITY:REALTIME]

Use this to set how fast the game zooms.  The default corresponds to multiplying by a factor of 1.1 each time the zoom action occurs.  You can set it anywhere from 1.001 to 1.999.

[ZOOM_FACTOR:1.999]

Change this to NO if you don't want to have the mouse involved at all.

[MOUSE:YES]

Change this to YES if you'd like to use a BMP for the mouse cursor.  The image currently lags when the game is lagging however.

[MOUSE_PICTURE:NO]

Use these to control the automatic saving behavior in the dwarf fortress mode of game.  AUTOSAVE can be set to NONE, SEASONAL or YEARLY.  This updates your save at these intervals, so that some of your progress will be saved in case of system instability.  You can set AUTOBACKUP to YES if you want the updated save to be copied to another folder so that you'll have several copies of your world at different times.  Set AUTOSAVE_PAUSE to YES if you want the game to pause every time it autosaves.

[AUTOSAVE:SEASONAL]
[AUTOBACKUP:YES]
[AUTOSAVE_PAUSE:NO]

Set this to YES if you want it to save the game when you start a new fortress.  If AUTOBACKUP above is set to YES, it will also create a copy of this new save.

[INITIAL_SAVE:YES]

Set this to YES to make Dwarf Fortress start paused whenever you load an active game.

[PAUSE_ON_LOAD:YES]

Set this to YES if you want Dwarf Fortress to show the warning window on embark as a confirmation even if there are no issues.

[EMBARK_WARNING_ALWAYS:YES]

You can change these to ALWAYS and NO.  More restrictive world parameter settings override these.  ALWAYS lets you see the features in the Local view during embark, and NO stops you from looking for features in the site finder (though if you really want to stop the finder, it might be better for you to generate worlds that restrict the use of this feature completely, in which case you don't need to change the settings here).

[SHOW_EMBARK_RIVER:ALWAYS]
[SHOW_EMBARK_POOL:ALWAYS]
[SHOW_EMBARK_M_PIPE:ALWAYS]
[SHOW_EMBARK_M_POOL:ALWAYS]
[SHOW_EMBARK_CHASM:ALWAYS]
[SHOW_EMBARK_PIT:ALWAYS]
[SHOW_EMBARK_OTHER:ALWAYS]
[SHOW_EMBARK_TUNNEL:ALWAYS]

Use these options to remove features from the game.  Permitted values are YES and NO.  Removal might speed the game up in the case of temperature and weather.

[TEMPERATURE:NO]
[WEATHER:NO]
[ECONOMY:NO]
[INVADERS:YES]
[CAVEINS:YES]
[ARTIFACTS:YES]
[ZERO_RENT:YES]

Change this to YES to output the reasons for world map rejection into a file.

[LOG_MAP_REJECTS:NO]

Change these numbers to make the embark rectangle start at a different size.  The format is (EMBARK_RECTANGLE:<width>:<height>).  Numbers may run from 2 to 16.  The map size warning message will go by these numbers.

[EMBARK_RECTANGLE:3:3]

Change these numbers to set the default weights for traffic designations.  If you make the last numbers too large, pathfinding might lag.
The format is (PATH_COST:<high>:<normal>:<low>:<restricted>).

[PATH_COST:1:2:5:25]

Alter these options to control how aggressively your dwarves place objects in a container with like items (rather than an empty container).  The default options are very aggressive.  STORE_DIST_ITEM_DECREASE controls the cap on objects it will consider -- for each object it finds in a container, one tile is removed from its apparent distance to the dwarf, up to this cap.  The others control how many tiles are removed for each combination type for any match at all.  For instance, if ITEM_DECREASE is set to 20, and SEED_COMBINE is set to 100, a dwarf carrying seeds will see a seed bag with 15 seeds as 115 tiles closer than it actually is (and thus pass up any empties within that distance), whereas a seed bag with 30 seeds would be treated as 120 tiles closer (because it hits the ITEM_DECREASE cap).  Values from 2 to 1000 are permitted.  Before these init options, the behavior was roughly ITEM_DECREASE 2, SEED_COMBINE 2 and the rest at 1000.

[STORE_DIST_ITEM_DECREASE:20]
[STORE_DIST_SEED_COMBINE:1000]
[STORE_DIST_BUCKET_COMBINE:1000]
[STORE_DIST_BARREL_COMBINE:1000]
[STORE_DIST_BIN_COMBINE:1000]

Change this to YES to disallow pets from coffin burial as the default option.

[COFFIN_NO_PETS_DEFAULT:NO]

This controls the display of areas that are far below outside.  The format is SKY:<character>:<foreground color>:<background color>:<brightness>.  The <character> can be either an ASCII tile number or a character in quotes, like '#'.

[SKY:178:3:0:0]

As above, for inside/subterranean areas.

[CHASM:250:0:0:1]

This controls the "IDLERS: <number>" that is displayed in dwarf mode.  You can set it to TOP, BOTTOM or OFF.

[IDLERS:TOP]

You can set the maximum population of your fortress here.  Keep in mind that your population must be at least 80 to get a king and 100 to obtain the current game features.

[POPULATION_CAP:40]

This allows you to control the number of babies+children in your fortress.  The first number is an absolute cap on the number of babies+children.  The second is a percentage of the current number of adults in your fortress (the default is the essentially meaningless 1000% here).  The lower number is used as the cap.  The cap only prevents further pregancies, so migrant children, multiple births and existing pregnancies from old saves can still push you over the cap.  Setting either number to zero will disallow pregnancies in the fortress.

[BABY_CHILD_CAP:0:0]

If you don't like the ,.`' ground, try setting this to NO.  The ground will turn into periods only.

[VARIED_GROUND_TILES:YES]

If you'd like your engravings to start off looking the same (you can toggle them on individual later), set this to YES.

[ENGRAVINGS_START_OBSCURED:YES]

If you get annoyed by seeing items like *<*sword*>* you can
get rid of the outside ** by setting this to NO.

[SHOW_IMP_QUALITY:YES]

Set this to YES to display fluids as numbers indicating depth.

[SHOW_FLOW_AMOUNTS:NO]

If you'd prefer to have it show the history behind every engraving you view in dwarf mode, etc., then set this to YES.

[SHOW_ALL_HISTORY_IN_DWARF_MODE:YES]

This controls the number of milliseconds that must pass before a held key sends an initial repeat press to the game.  You might need to adjust this.

[KEY_HOLD_MS:150]

This controls the number of milliseconds that must pass before a held key sends a repeat press to the game after the repeat process has begun.

[KEY_REPEAT_MS:150]

This controls the number of milliseconds between macro instructions.

[MACRO_MS:1]

This controls the number of milliseconds that must pass before input works again after the view recenters on an event in dwarf mode.

[RECENTER_INTERFACE_SHUTDOWN_MS:0]

This controls "more" in adventure mode.  If MORE is set to NO, all announcements will be skipped.  DISPLAY_LENGTH controls how many lines are printed before it gives you the "more" prompt.

[MORE:YES]
[DISPLAY_LENGTH:23]

Set this to YES if you want traps to affect you in adventure mode.  This is not recommended -- there are lockup issues with cage traps, and you cannot disarm any of the traps yet, so they effectively stops you from exploring your old fortresses.

[ADVENTURER_TRAPS:NO]

Set this to NO if you want the game to recenter on your adventurer only when you've gotten close to the edge of the view.

[ADVENTURER_ALWAYS_CENTER:YES]

This controls the up/down views in adventure mode.  The first parameter can be OFF, UNHIDDEN, CREATURE or ON.  UNHIDDEN makes the view appear when it contains any unhidden square.  CREATURE makes the view appear when it contains a creature.  The second parameter is the size of the view.  It can be 3, 5, 7 or 9.  A smaller view lets it stack more of them in the column (3 at size 5, and 5 at size 3).

[ADVENTURER_Z_VIEWS:UNHIDDEN:9]

You can use these to say how nicknames are displayed in each mode
Options are REPLACE_FIRST, CENTRALIZE (between first and last), REPLACE_ALL
[NICKNAME_DWARF:REPLACE_FIRST]
[NICKNAME_ADVENTURE:REPLACE_FIRST]
[NICKNAME_LEGENDS:REPLACE_FIRST]

These are the display colors in RGB.  The game is actually displaying extended ASCII characters in OpenGL, so you can modify the colors.

[BLACK_R:0]
[BLACK_G:0]
[BLACK_B:0]

[BLUE_R:30]
[BLUE_G:50]
[BLUE_B:168]

[GREEN_R:96]
[GREEN_G:170]
[GREEN_B:0]

[CYAN_R:0]
[CYAN_G:128]
[CYAN_B:140]

[RED_R:200]
[RED_G:20]
[RED_B:0]

[MAGENTA_R:128]
[MAGENTA_G:50]
[MAGENTA_B:200]

[BROWN_R:140]
[BROWN_G:98]
[BROWN_B:56]

[LGRAY_R:192]
[LGRAY_G:192]
[LGRAY_B:192]

[DGRAY_R:128]
[DGRAY_G:128]
[DGRAY_B:128]

[LBLUE_R:0]
[LBLUE_G:120]
[LBLUE_B:255]

[LGREEN_R:134]
[LGREEN_G:213]
[LGREEN_B:0]

[LCYAN_R:0]
[LCYAN_G:200]
[LCYAN_B:255]

[LRED_R:255]
[LRED_G:50]
[LRED_B:0]

[LMAGENTA_R:210]
[LMAGENTA_G:10]
[LMAGENTA_B:255]

[YELLOW_R:255]
[YELLOW_G:232]
[YELLOW_B:76]

[WHITE_R:255]
[WHITE_G:250]
[WHITE_B:230]

Try this, the next thing would be to lower the partial print number or make it higher if there's flicker, or to adjust the buffer.

[assimilateur]

I'll see how that goes, thanks. It'll probably take me till tomorrow or even later to make a new fort with any kinda population, I'm just experimenting with world gens right now.

As I said earlier, I'm sorry but I don't really expect much from your adjustments. No temp and weather didn't do much for me earlier, neither did different print modes. I only hoped that you'd come up with something I hadn't thought about, and so far I didn't see anything like that in the new init.

EDIT: When changing it to realtime or high priority earlier, I was having increased lag in the interface when paused with little or no improvement in framerates when unpaused.

[Canis786]

I did my masters thesis on parallel processing and as of right now it is highly dependent on the project. It is very difficult to multi-thread some applications due to dependencies on previous tasks. In fact doing so will most likely decrease the speed of an application. Take this as an example,

Job A requires Job B
Job C requires Job A

Both B and C require A to be completed. This can have some parallel processing but there is no easy way to add this into an application. Also by doing so there are increased chances of bugs. Job B and C should not access the same data at all. Doing so could mean sync bugs popping up which are incredibly difficult to find as they are essentially random. (Due to how OS's handle mutli-threading).

There are simple tasks that can be threaded such as for loops that don't require previous input. As I don't know how the code works for DF I can only give a few examples but I believe the modified A* algorithm could be one such area. Instead of calculating the path of 10 dwarves one after the other you could thread the loop to calculate 5 dwarves and 5 dwarves. Which gives you a max speed benefit of 2x. I do not believe each dwarf gets a path calculated every time step as that would be such a waste of processing power. Most likely pathing is queue based so entities that need paths are added to a queue and every x time step some are given a path. In this case multi-threading wouldn't give much benefit (if any) and it would require a major rework of the back end.

Another would be temperature. I believe temp would be a good threaded area as it could be well separated from the main code. This means the number of variables shared between threads would be drastically reduced making the task much easier. Since temp is a huge hog of CPU cycles throwing it on another thread would be a viable solution as long as all temp information is double buffered. The reason being the temp at a location might change by 1 unit and while that memory address is being written, the other thread would read it and get some strange piece of data. This would have an extremely small chance of happening but it would be incredible strange to have a dwarf burst into flames because the main processing thread read the temp of the cell he was on as 10000 while the memory data was being changed. (though it would be comical).

However, as has been stated we don't have ANY clue what the code for DF looks like. Because of that everything I have stated is an assumption of how I would program such an application as of this moment. The actual implementation could be TOTALLY different. That said with programming anything is possible and it all depends on time and the amount of complexity you are willing to deal with.

[Gertack]

I'm rather astounded by the amount of people that keep suggesting something as inviable as multi-threading at this moment, or what appears to be the snobby elitism of a few programmers either demanding that this free game paid by donations should be open-source or the code is horribly unoptimized without:
1. having seen the code.
2. programming anything nearly as complex as DF

If you don't consider 4 hours to enumerate 500,000 objects "horribly unoptimized" even without the code, then you, sir, should be anointed sainthood for your patience.

People keep suggesting multi-threading because they see DF only using one CPU on their dual/quad-core machine and they CARE about the game because it is Fun and they want to see it get better, so they suggest what seems "obvious" to make it faster.  Algorithmic complexity is a far more subtle problem and happens more often on the old, large forts that I doubt receive as much testing from Toady.  At that point in the fortress people tend to think 200 dwarfs = pathfinding awful.  Is it? Maybe. If the pathfinder runs a lot of "impossible" path checks then that would be a good part to fix because it would be awful on large embarks, but I tend to blame the job system for the overall slowdown in fortresses.

I play a fort that gets 0 FPS. Why? It's still fun.  Would it be better it if was faster? Yes!

[assimilateur]

If you don't consider 4 hours to enumerate 500,000 objects "horribly unoptimized" even without the code, then you, sir, should be anointed sainthood for your patience.

People keep suggesting multi-threading because they see DF only using one CPU on their dual/quad-core machine and they CARE about the game because it is Fun and they want to see it get better, so they suggest what seems "obvious" to make it faster.

Amen.

[Terratoch]

Holy sh*t. Didn't mean to start a flame war. I was just asking, sorry.

[profit]

Holy sh*t. Didn't mean to start a flame war. I was just asking, sorry.

It's ok

It is not a flame war just contentious issue... No one has said they are gonna kill anyone yet or anything.

You're all good, just use search next time =)


On the subject matter, there was someone on here using a MAC who had 120FPS in a succession fort...

Can we get some other FPS numbers from the Apple camp? 

I am curious if there is a massive difference between builds...  or is the person who posted those values exaggerating significantly and adding the general noise surrounding things. I find it unlikely, but sometimes one optimization of something that is used 4 million times a second can make a massive difference.

If there was a massive difference... I am so freaking tired of FPS:1 I would consider buying a mac to play DF on if I could have 100FPS in my forts...

[cooz]

Any reason why OpenMP couldn't be use? Adding it to C++ code is as simple as adding few OpenMP Directives (no need to rewrite whole code creating client-server, emulators, etc...) and each for loop with independent elements could be divided to processor cores with almost zero effort.

[Sunday]

It's ok

It is not a flame war just contentious issue... No one has said they are gonna kill anyone yet or anything.

Oh yeah?  We'll soon fix that.


I will kill everyone!!!

OK, back to your fancy shmancy programmer-talk.

[eerr]

multi-thread what?
In-game lag comes from a few actions that all depend on the same information.

This includes Pathfinding, temprature, water-mechanics, map modifications and screen drawing(or so I've heard).

Unfortunately, the lag is always with just one of these processes at a time.
Only  with screen-drawing vs everything else could you afford multi-threading.
Anything else is a minimal gain, where you have one massive processor hog and another process which is 2% of it's size.

I know measurements of multithreading power are underconstruction by people more experienced than I, but multithreading 100%  of the game into  a 100% process and a 2% process is hardly any progress at all.
and that is ignoring the problem of syncronizing pathfinding with map-edits!

Well.. Since it is all done inside of a frame anyhow... You could break the temprature subroutine off into 100 threads or so...  They dont have to modify anything until the end of the frame.

The fluid simulation could also be broken off into discrete threads, probably one for every tile with a fluid simulation flag on it.

Every pathfinding job could each have its own thread...

At the end of the frame when it is time for an update, they all sequentially add their data to the relevant parts of memory.

It would not be easy, but just because they all depend on the same information does not mean they are all changing it at the same time. 

It is possible to do it... and if you had bothered to look at the video and read the messages stated earlier in this thread you would know IT HAS ALREADY BEEN DONE by someone else. 

Therefore.... Your statement is completely incorrect with no redeeming and useful information.   It has been done. It is possible. It did not just give 2% it gave at least a several Thousand percent increase.

The nature of Temprature is that it doesn't need to update changes very fast, with the except of stuff moving like water, magma and stone. Changes in temprature can happen at 1/16 the rate (and 16x the power?) rate of water is now and nobody will every notice. Then bear in mind that temprature doesn't require pathfinding like water does.


Exactly how will you make 100 threads of moving fluid?? Threads are not cheap to create or destroy, nor can you run more threads than the number of processors available.
Far better to make 1-5 threads and allow those threads to handle seperate bodies of water, or individually numbered tile.
I suppose that might actually work, but there is some syncronization overhead necessary.

Depending on the implementation, It might or might not be faster with just 2 processors, and would require some really impressive threading magic.



"Every pathfinding job could each have its own thread..."
The pathfinding jobs only cause lag when they start colliding with each other. Only one creature can stand up on a tile at a time! The problem is how DF handles these conditions. All paths that conflict are dumped into memory. This will invariably occur with two paths at a time, and can cause syncronization-issues. issues that are very problematic no matter how you attack them, short of revamping the whole movement system.


I know multi-threading is possible, I just don't want Tarn to destroy DF to make it support multithreading. Just because other people built the engine with multithreading from the bottom up doesn't mean it takes Tarn a mere four months to write in Multithreading.

[Silverionmox]

Does fps slow down with old fortresses with 500k rock and if you cheat to embark with 30+ wagons, 300+ dwarves, have a catplosion... yes it does.

Does fps slow down with 2- or 3-year fortresses, with 10k rock and if you don't cheat, have no cats, and embark on a 4x4 site... yes it does. Not for you perhaps, but for a great number of people.

For the record, rocks have nothing to do with pathfinding speeds... the corridors they came out of do. Workaround: place a door to seal off a large mining area that you're not currently exploiting, and lock it.