Print

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

Faster than 40d, no problems

42 (26.1%)

Faster than 40d, problems

72 (44.7%)

No slower than 40d, no problems

14 (8.7%)

No slower than 40d, problems

16 (9.9%)

Slower than 40d, no problems

2 (1.2%)

Slower than 40d, problems

3 (1.9%)

Doesn't work (please explain)

12 (7.5%)

Total Members Voted: 160

[The13thRonin]

Can someone tell me a suitable grid size and resolution that should equate to roughly 1.25-1.5x the size of vanilla Dwarf Fortress? I'm doing something wrong and my grid keeps bunching up in the top left hand corner of my screen...

[Baughn]

Vanilla DF is 80x25; any grid size smaller than this will be ignored.

The resolution required depends on the tileset used, of course.

[Baughn]

(However, for a 16x16 tileset, 80x50 is 1280x800. I find that to be a useful windowed resolution.

[Davion]

40d6 is faster than 40d until I resize my window to what I usually have it at which is something like 1200x960/150:80.

Edit to add: Getting 80 FPS in 40d6 on embark and get around 150-200 on the same map on embark in regular 40d, with the above window/grid size.

If I change my window/gird size back to the default then I get around 150-200 in 40d6. I'm guessing I might have to scale back my grid and window size with these updates.

[Baughn]

Nah, it should be fine once we get to d7. What you're seeing is almost certainly a bug.

[takaratiki]

Small bug report on 40d6 in Linux (Ubuntu 8.10). My FPS seems crisp, ~320 with fresh fort, ~60 on a mature, which represents a 50% increase over previous version in WINE. My problem is that the game suddenly drops out of fullscreen mode several minutes into playing a fortress and the controls go unresponsive. Inevitably the screen resizes and I can enter commands again, but then it drops out several minutes later. Let me know if there is additional data required for this and I will provide. Thanks for the great work, my sluggish city-states can thrive again.

[Gertack]

Sadly my 230-pop fort gets 1 FPS no matter if it is 40d or 40d5, but then I had assumed it to be pathfinding/flow-limited prior to trying so I'm not particularly surprised.

[Ostsol]

The only problem with using the Wubi installer is that it will automatically install the AMD64 version of Linux if you have a 64 bit processor, which includes the Intel Core2 line, which is fairly common around now, and I'm not sure if Dwarf Fortress will work in it. I can't get it to function in Ubuntu at the moment, but I have a feeling it's dependency issues more than anything else.

The problem is that the ia32-libs package does not include a 32-bit version of the libsdl-image library.  You can solve this dependency by downloading the i386 version and extracting the library manually:

Code: [Select]

dpkg-deb -x libsdl-image1.2_1.2.6-3_i386.deb ./libsdl-image
Copy the two files from ./libsdl-image/usr/lib into the libs/ directory of Dwarf Fortress.  This is what worked for me.

[PolliMatrix]

I just did some tests with with version d6 using the default init file. Most of the suggested PARTIAL_PRINT, FRAME_BUFFER and SINGLE_BUFFER settings seem to work in windowed mode except (YES,NO,YES). Using this the game itself seems to run, but it just shows some random junk.
In full screen mode it always runs with the same fps as my display's refresh rate (unless i set the fps cap lower than that) when I use the first three settings. If I use (YES,NO,YES) it runs at full speed but with flickering.

Next I did some speed comparisons using the three working settings in windowed mode, a fps cap of 10000 and basically the same fortress. While it's a little slower on menus, the actual game is much faster:

Spoiler (click to show/hide)

The original version did flicker with partial print and especially with maxed frame rate.
not using partial print there is ~2350 fps on menus, when paused it fluctuates somewhere between 200 and 480. When the game is running there are only 50-60 fps.

Here are the results with the new version:
(NO,NO,NO) : 300 on most menus, 220 during a paused game, 105 while the game is running
(YES,YES,NO) : 1700 on menus, 750 during a pause, 150 while the game is running
(YES,NO,NO) : 1700 on menus, 750-800 during pause, 160 while the game is running

While doing those tests I also noticed that there's a slowdown on the loading screen where it runs slower than most other menus (about the same as a paused game).
Also the mouse cursor image looks upside down for me when I enable it.

[vins]

Aaaargh this version is way faster but i have a problem.
I have an azerty keyboard not a qwerty one!
When i press "a" for the game it's a "q"... and it's already hard to play dwarf fortress with a portable computer's keyboard without that :p.

[Baughn]

Only thing I can suggest is that you rebind all the keys in the input menu. Sorry, but I'm not going to start reworking the input system at this late date.. source code is online, though, if someone else wants to pick it up.

EDIT: Darn it, apparently I'm going to do just that. *pout*
It might be pretty simple. I'll give it a shot, at any rate.

[Ostsol]

Only thing I can suggest is that you rebind all the keys in the input menu. Sorry, but I'm not going to start reworking the input system at this late date.. source code is online, though, if someone else wants to pick it up.

EDIT: Darn it, apparently I'm going to do just that. *pout*
It might be pretty simple. I'll give it a shot, at any rate.

Heheh. . . I was just thinking that you could have a keyboard layout file in the init directory that would map the internal layout to the desired layout.  In this case the file would begin:

[Q:A]
[W:Z]
[E:E]
[R:R]
[T:T]
[Y:Y]
etc. . .

You could even have multiple files, named based on the keyboard they represent, and have an option in init.txt to select the desired layout file.

[Baughn]

No need for that, SDL gives me the unicode letters the keys translate to according to your OS's keyboard map.

Only problem is, DF has a built-in assumption that the set of symbols bound to a given key (eg. a and A for a, 1 and ! for 1, etc.) is always the same, so I can't just pass in the unicode symbols; it doesn't read !, it reads shift-1. Unfortunate. So, I'm just translating the a-z keys.

That should still be better than it used to be; there aren't many other keys that need some form of rebinding.

[vins]

Yeah but if i rebind there is things like
"up : w"
And i must press "a"....

HS
(It's funny but with unreal world i was a beta tester and i had the same problem so i couldn't use my registeration code to play the game... he used a program who recorded 3 keys if i remember well.....
Funny result :

SDLK_m 109
----------------
processed_keysym(32)
scancode: 57
unicode: 32
unicode: 0 & 0xFF80
unicode: 32 & 0x7F
keysym: 32 unicode: 32
  return keysym: 32
SDLK_m 109
----------------
processed_keysym(59)
scancode: 39
unicode: 109
unicode: 0 & 0xFF80
unicode: 109 & 0x7F
keysym: 59 unicode: 109
; return keysym: 59
SDLK_m 109
----------------
processed_keysym(44)
scancode: 51
unicode: 59
unicode: 0 & 0xFF80
unicode: 59 & 0x7F
keysym: 59 unicode: 0
; return keysym: 59

/HS

[Footkerchief]

The 40d6 init.txt seems to indicate that you shouldn't use FRAME_BUFFER and SINGLE_BUFFER at the same time.  If this is the case, maybe the options could be turned into a single parametrized option, like this: [BUFFER:FRAME], where FRAME could be replaced with SINGLE or OFF.  This would make things a bit clearer.