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

[bhelyer]

I'm in a situation where I end up bouncing between a Mac and a PC rather often, so I had a question.

I've noticed that the Dwarf Fortress .exe file is in the Mac version download.  Will it still work normally if I use that on the PC, or do I need to download the Windows version specifically?

I assume this is the same as the Linux version.  The EXE is not truly a Windows Executable.  It's an OS specific binary that's named just like Windows Executables.  It's confusing...

This keeps coming up. I think the extension should be changed to .bin or .x86 or something to avoid confusion.

I rename it anyway, as I see a .exe in the process list and think "hmm, why is wine running?" 

I kind of wish they would pack all the versions together and create 3 binaries with script/batch files to run the specific one, but this is fairly experimental right now.  (ie: Dwarf_Windows.bat, Dwarf_Linux, and Dwarf_Mac)

This should be fairly trivial to do for yourself. Just give it a try, and be sure not to overwrite anything (you'll have to change the OS X or Linux script and executable's name I think, but the libraries have different extensions (I think, OS X is .dylib, right?), so it should be fine to have both sets in the ./libs directory.

EDIT:

script/batch files to run the specific one

Never mind, I can't read apparently.

[Baughn]

The versions are never going to be bundled in one package.

Apart from the potential confusion and increased disk usage, Toady's wallet would start crying from the increased server bandwidth usage.

[Random832]

Apart from the potential confusion and increased disk usage, Toady's wallet would start crying from the increased server bandwidth usage.

From that perspective, what about a "platform"/"runtime" split - like vim - so you download a "runtime" package that has all the raws etc, and a "platform" package that includes just the binary and e.g. support scripts for the linux version. That'd make the bandwidth usage less for people who want to download the versions for more than one platform.

A thought about the libtiff issue - is it possible avoid linking against libtiff - either by loading it at runtime with dlopen() or by simply not supporting the tiff format (which no existing graphics sets or tilesets use) at all?

[Baughn]

I don't think there are sufficiently many people who'll want packages for multiple platforms, but it's worth a look.

And no, no unbundling libtiff without recompiling sdl_image. Which probably *is* a good idea.

[Random832]

I don't think there are sufficiently many people who'll want packages for multiple platforms, but it's worth a look.

And no, no unbundling libtiff without recompiling sdl_image. Which probably *is* a good idea.

Wait - if it's not linked _directly_ to libtiff (rather than as a dependency of sdl_image), why is it (rather than the system installed sdl_image) saying what version of libtiff to use?

[kutulu]

I don't think there are sufficiently many people who'll want packages for multiple platforms, but it's worth a look.

And no, no unbundling libtiff without recompiling sdl_image. Which probably *is* a good idea.

Wait - if it's not linked _directly_ to libtiff (rather than as a dependency of sdl_image), why is it (rather than the system installed sdl_image) saying what version of libtiff to use?

Most Linux distributions do not include SDL_image with their SDL packages.  Gentoo, for example, requires you to install a separate SDL_image package -- but oddly enough, SDL_image is in their 32-bit compat library for amd64.  Sometimes I don't ask questions.

Toady ships the linked libSDL_image-1.2.so.0 in the libs directly, which is the one from whatever distribution he uses to build the binary, which uses the .so.4 name instead of the .so.3.  If you have libSDL_image.so already on your system, you can mv the one in the df/libs/ folder out of the way and it will use your system SDL_image, which uses the system libtiff.  My ebuild does this now, since it has a hard dependency on SDL_image.

Here are all of the libs shipped with the official Linux package, and where you can get them for yourself:

libSDL_image.so -> SDL Image package v1.2
libstdc++.so.6 -> GNU gcc C++ compiler
libgcc.so -> GNU gcc compiler
libfmodex.so -> fmod

If you have all of those things installed on your system then you shouldn't need any of the libs/ folder, or really the startup script for that matter.  The gcc libraries appear to be from v4.3.x... I'm using the stock 4.3.3 ones with no problem; I have no idea if dwarfort.exe will use earlier or later versions successfully.

--K


I

[Baughn]

Later versions of libgcc/stdc++ should be fine.

Earlier versions cause trouble, which is why they're bundled. If you're lucky it'll just fail to launch, but I've seen outright corruption happen.

[Random832]

Later versions of libgcc/stdc++ should be fine.

Earlier versions cause trouble, which is why they're bundled. If you're lucky it'll just fail to launch, but I've seen outright corruption happen.

I thought incompatible changes get a major version bump? (but, then, that was what started this whole libtiff mess, so best not to assume?)

[bhelyer]

Later versions of libgcc/stdc++ should be fine.

Earlier versions cause trouble, which is why they're bundled. If you're lucky it'll just fail to launch, but I've seen outright corruption happen.


Debian did, libtiff devs didn't, as far as I can seer from smarter people here than I.

I thought incompatible changes get a major version bump? (but, then, that was what started this whole libtiff mess, so best not to assume?)

[kg333]

Hello all,

I've been attempting to get Dwarf Fortress 40d11 to run natively under 32-bit Ubuntu Intrepid with little success.  I did follow the readme and at least attempt to install the necessary libraries, but wasn't quite sure which versions of some of these libraries I needed.

My current issue is that DF runs when started from the "df" script, and frequently the splash screen and intro will play as well before displaying the menu. However, as soon as the window is clicked on, it goes completely black.  The sound continues playing and if you remembered where you were on the menu, you can still scroll down and hit exit blind, so it's not freezing up.

Any ideas as to what could be causing my problem?  I'd be happy to post any system info you guys need if you can tell me where to find it.

My apologies if a solution to this particular problem was already posted...I've searching for a while here and via Google, and wasn't up for going through 90 pages.

KG

[Andir]

Hello all,

I've been attempting to get Dwarf Fortress 40d11 to run natively under 32-bit Ubuntu Intrepid with little success.  I did follow the readme and at least attempt to install the necessary libraries, but wasn't quite sure which versions of some of these libraries I needed.

My current issue is that DF runs when started from the "df" script, and frequently the splash screen and intro will play as well before displaying the menu. However, as soon as the window is clicked on, it goes completely black.  The sound continues playing and if you remembered where you were on the menu, you can still scroll down and hit exit blind, so it's not freezing up.

Any ideas as to what could be causing my problem?  I'd be happy to post any system info you guys need if you can tell me where to find it.

My apologies if a solution to this particular problem was already posted...I've searching for a while here and via Google, and wasn't up for going through 90 pages.

KG

Turn off the desktop effects and see if that solves it.  System / Preferences / Appearance (?) then click on the Effects tab is I remember right.  Some of those effects don't mesh well with accelerated games.

[kg333]

Turn off the desktop effects and see if that solves it.  System / Preferences / Appearance (?) then click on the Effects tab is I remember right.  Some of those effects don't mesh well with accelerated games.

That did it, thank you very much!

[JohnQMetro]

I'm having a similar problem on Linux : namely, the menu showing up and then everything going blank (there is actually a screenshot of this on page 84 of this thread from mattyb3). In my case, visual effects are *not* turned on. The linux version is a custon ubuntu variant, eeebuntu.

Does anyone have any tips?

[Behrooz Wolf]

I've noticed some odd control effects in 40d11 when dealing with rapid series of keypress inputs.

Specifically, when multiple keypresses are entered rapidly while moving through different areas of the interface, some of the commands appear to be either lost, or delayed.  This causes things like an autohotkey script that digs a pattern of 30 detailed rooms to go absolutely haywire.

I thought I was just being slipshod entering my scripts, but I reverted back to 40d and the scripts work normally, so something is getting into the queueing or interpreting of commands in 40d11.

This issue also affects very rapid manual entry of specific things, such as building a string of tables-- example of b-t-enter-enter-enter-right-t-enter-enter-enter and so on.

Any guesses?

[chucks]

There were past issues with double tapping a key in 40d, and it appears that some mechanism was added in 40d11 to de-bounce the keyboard buttons.  It's probably that the keypress repeat delay within SDL was increased or something similar, but you're going to want to increase the delay for your autohotkey macro program.  Since its sending events too fast, try increasing your delay between keystrokes if that's an option.