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

[Footkerchief]

You don't need to generate a new world.  Some newer graphics cards are capable of optimizing the output themselves, so if you're not seeing an increase, yours is probably one of them.

[Baughn]

There are some memory corruption issues in DF which magically go away if you run a world on the same version you generated it on, that have all sorts of odd effects. Burning alunite instead of charcoal, for example...

At any rate, yes, generating a new world can be a good idea.

Oh, and since Toady is now aware of the issue, and has a working linux version (Valgrind beats the memory debugger he used on windows hands-down), there's a good chance it'll eventually be fixed. One hopes.

[tsen]

Oddly enough, I didn't used to be able to use anything other than the default 80:25 setting despite careful shifting around of tilesets and options, but it works with 40d9.  Thanks!

[Moddington]

Is that in fullscreen? Hmm. I'll try this out when I get a chance. I don't think I've noticed it, but I don't play in fullscreen that often.

No, it was in windowed mode actually.  And it still has this tendency when the dialog box isn't there, though now it only happens when the cursor is moved on and off of the DF window, while before it would happen when moving the cursor on and off of the prompt too.
Might be my settings, I might mess around with a bit to see if it is.

[Kazindir]

You don't need to generate a new world.  Some newer graphics cards are capable of optimizing the output themselves, so if you're not seeing an increase, yours is probably one of them.

I have an ATI 4870, which I guess is capable of performing the required automagical rites by itself then.

The version that that fortress was generated in is a couple of versions old now which is why I wondered.

[burlingk]

I just have two comments.  I will give the important one first.

fmodex, or libfmodex, or the equivelent is needed for the Linux version to run.  I found that out pretty quick, but it should probably be included along side the list of dependencies.

Second, and this is more a preference thing.  In the Linux and OSX packages, dwarfort.exe should probably just be dwarfort.  This is a stylistic thing that is somewhat big in the Unix and Linux world.  It has no real effect at the command line level except for looks of course.  HOWEVER, if you have Wine installed and your window manager supports extention based applications, you can get bad results.

:-)  Other than that, this is awesome!

[Baughn]

Well, yeah, but you're supposed to run the scripts, not dwarfort.exe directly.

I named it that specifically *because* unix users tend to assume executables shouldn't really be named .exe. Perhaps I should put it in a libexec subdirectory instead.

[Gertack]

Oh, and since Toady is now aware of the issue, and has a working linux version (Valgrind beats the memory debugger he used on windows hands-down), there's a good chance it'll eventually be fixed. One hopes.

There's also the no-recompile-necessary option:

Another possibility to check for and guard against bugs in the use of malloc, realloc and free is to set the environment variable MALLOC_CHECK_. When MALLOC_CHECK_ is set, a special (less efficient) implementation is used which is designed to be tolerant against simple errors, such as double calls of free with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be protected against, however, and memory leaks can result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic is printed on stderr; if set to 2, abort is called immediately. This can be useful because otherwise a crash may happen much later, and the true cause for the problem is then very hard to track down.

MALLOC_CHECK_=2 ./df

[numerobis]

valgrind doesn't require a recompile, and catches a lot more than the malloc checkers.  It's a tiny bit slow, is the only thing.

[Cerdo Guerrero]

To the people who has the problem where you try to start the game in XP but when you run Dwarf Fortress.exe nothing happens and there is a running process that clogs 100% of the CPU, I found a solution.

It happened to me too, until I tried this: Just right click Dwarf Fortress.exe, select "Run as". Now make sure "actual user" is selected and click OK. It works every time for me. I hope this also helps find the origin of the problem.

PS: English isnīt my native language so some of the menus and options Iīve mentioned may have different names.

[Baughn]

I'll test that on an actual windows XP install tomorrow, but that seems very odd to me.

When you just double-click on an executable, it'll run with your privileges. When you right-click, run as, actual user... it'll still run with your privileges. I don't see how it could change anything.

[WCG]

This version doesn't work on Windows 98, apparently (I tried to run it, but immediately got a message that it needed a newer version of Windows).

No big deal, for me. My usual computer is down, so I'm using my old one, but only temporarily (I hope). Just thought I'd mention it.

[Footkerchief]

PTTG posted a bug report that might be related to 40d# stuff: http://www.bay12games.com/forum/index.php?topic=30746.0

[bhelyer]

This version doesn't work on Windows 98, apparently (I tried to run it, but immediately got a message that it needed a newer version of Windows).

No big deal, for me. My usual computer is down, so I'm using my old one, but only temporarily (I hope). Just thought I'd mention it.

We are aware, but thanks for taking the time to report. If, theoretically speaking, you were stuck on a Windows 98 computer (heaven forbid ), you could install a Linux distro and run DF on that.

[burlingk]

Well, yeah, but you're supposed to run the scripts, not dwarfort.exe directly.

I named it that specifically *because* unix users tend to assume executables shouldn't really be named .exe. Perhaps I should put it in a libexec subdirectory instead.

I am running the Linux version nothte OS X Version.  There is no script.  Again though, the .exe was kind of a stylistic issue.  The fmodex issue is the real potential bug.