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]

If anyone using the linux version has multiple soundcards and the wrong soundcard is getting played through, I am happy to report that it's not my fault (which is clearly the most important thing to take away here ) but a bug in fmod (I don't think it effects all multi-sound card set ups). So it'll get fixed at some point in the future ('next release' of FMOD). Until then, just install alsa-oss and use 'aoss df -sound_output OSS' to start DF.

Though, I don't expect anyone has had this problem, as no one has complained.

[chucks]

I think I just had a mild joy-induced panic attack to find that df(bc) has a public git repo!

[Petr Ga]

I've compared DwarfFortress++: original vs switched to 40d11. Result is awesome - 4x framerate for SDL (40d11) version!

See here, SDL on background

[Volfram]

OK, not sure if this has to do with the game, faulty hardware, or a comprimised security system, but I'm getting random keypresses while not touching my keyboard.

[edit]
Not bein' hacked, it persisted after I turned off my internet

don't think it's hardware, left Notepad up for several minutes and got nothing.

[chucks]

Thanks for posting the unstable builds!  Here's some feedback from a linux user.  I always just run df in wine, but it's nice to be able to contribute a quick test report.


-- edit: this part was added later

Ok, fired up the df in wine and going to give it a spin for about a week.  Runs just fine (as usual), and I'll give a playability report as quickly as I can get into a game on this one.

Code: [Select]

$ uname -a
Linux ares.<no need to know that> 2.6.28-gentoo-r4 #5 SMP PREEMPT Thu Apr 2 00:15:43 EDT 2009 i686 AMD Phenom(tm) 9950 Quad-Core Processor AuthenticAMD GNU/Linux
The first time I ran native linux df on my system I got this:

Code: [Select]

$ ./df
./dwarfort.exe: error while loading shared libraries: libtiff.so.4: cannot open shared object file: No such file or directory
libSDL_image-1.2.so.0 requires libtiff.so.4.  My system only has libtiff.so.4.  Time to go scour my package manager for updates.  I'm not sure about the licensing of libtiff, but you might want to include the specific library files from your linux installation on the build server the way you provide the SDL libs.  If you can do this and perhaps any of the potentially nasty and complex tree of library requirements, that would be really cool.

-- edit: Ok, messed with my package manager and tiff-3.8.2 is currently the highest version in there.  I have a lot going on right now, so I'll go further down this path later.


I cloned the public bare repository you have posted at git://brage.info/bc.git and took a poke at it.  I haven't worked with scons before, but I have heard of it.  The scons.py and SConstruct files in the src tree clued me into what to look for, so I did successfully get the executables to build against my native system libraries.

Unfortunately, I was able to get very far with battlechamps.  The keybindings for the up and down arrow keys on my system doesn't register properly with bc.exe, and I can't even navigate the startup menu.  I partially suspect my recent update to Xorg 1.5 and the way it handles keyboard and mouse interfaces (bye bye keyboard and mouse X11 drivers, hello "Generic input layer -> Event Interface" driver) because it has been a little bit whacky with my keyboard at times.  Plus, this is also probably a df_linux newb problem.

-- edit:  Nevermind, I got this working.  Somehow the top row 2 & 3 are mapped to up and down.  I'll fix that in the keybindings.

I also get some diagnostic messages on the console while bc is runnning.  Here you go:

Code: [Select]

$ ./runscript.linux
Using OpenGL output path with client-side arrays and off-screen framebuffer
Ideal catalog size: 368x368
Mouse reset; this should not happen
^C^\./runscript.linux: line 5: 26313 Quit                    ./bc.exe $*
I haven't dug very deeply into the source tree, but I'm thinking of adding some code prior to the SDL keyboard event switch statement that outputs the int and char * keycode data (if there's an API to decode the int into char *, I haven't messed with SDL in a while).

-- edit: I got all of the keybindings sorted out and I am now messing with battle champs.  It's very strange and very much unlike anything df related I've messed with.  The start of the interface is familiar, but I'm not sure exactly what's going on after that.  Seems like something neat to mess with for now.

-- edit: Ok, played some more with this, and it's neat.  Reminds me of Romance of the Seven Kingdoms style games.  Still needs some more playing.

[bhelyer]

libSDL_image-1.2.so.0 requires libtiff.so.4.  My system only has libtiff.so.4.  Time to go scour my package manager for updates.  I'm not sure about the licensing of libtiff, but you might want to include the specific library files from your linux installation on the build server the way you provide the SDL libs.  If you can do this and perhaps any of the potentially nasty and complex tree of library requirements, that would be really cool.

-- edit: Ok, messed with my package manager and tiff-3.8.2 is currently the highest version in there.  I have a lot going on right now, so I'll go further down this path later.

Just symlink 4 to 3. SDL_image should only call upon it if it has to load a tiff image, which it shouldn't.

[chucks]

Doh!  I'm so spacy after spend all day at work on issues and bugs and lifecycle requirements and customer tickets, it sometimes dulls me at home.  Works just fine after the symlinking.  Crazy to think I can run df natively now.  I definitely have plans to begin experimenting with the dwarfs that are ready to be abused.

[Baughn]

Also, libtiff.so.4 is the same library as libtiff.so.3. As in, most likely the same version.

The libtiff developers did an API-breaking change without changing major version. Some distributors (including toady's) decided to bump the version number anyway. Some didn't. It's a mess. I'll make sure to ask Toady to bundle libtiff next time.

[chucks]

So, the only real difference between 40d and 4011 is the rendering engine?

[Mr Tk]

Yip. 40D uses SDL for its graphics, while the 40Dx versions are using OpenGL (with some SDL for non-graphics things).

The goal is to be able to dump the graphics processing to the GPU so it can free up the CPU.

[Veroule]

All versions of DF use OpenGL for the rendering.  The 40d# versions introduced the use of SDL to provide platform support for Linux and Mac.  These numbered versions also have major optimisations to the rendering routines.

As of the 40d10 version the mid-level keyboard routines were rewritten to a nearly optimal state.  I am still working on the keyboard stuff to improve support for different layouts and languages.

[nirodragon]

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?

[Andir]

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...

[nirodragon]

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...

Hmm, that's an interesting setup, then.  I suppose I'll just test it, eh?  That would probably have answered my question for me anyway.

If it is something weird like that, I would have to say it's intentional somehow, since it should be easy enough to write the code using a different extension that doesn't make my OS panic when it runs.

[Andir]

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...

Hmm, that's an interesting setup, then.  I suppose I'll just test it, eh?  That would probably have answered my question for me anyway.

If it is something weird like that, I would have to say it's intentional somehow, since it should be easy enough to write the code using a different extension that doesn't make my OS panic when it runs.

You should just be able to rename it to whatever you like in OSX/Linux.  This means you'll have to update the dwarfort script/batch file that comes with it (and is used to launch it) to point to the new binary file.  Windows, however, requires that extension to work properly.  You could possibly have both binaries in the folder and have them work properly.  I know the Linux version keeps it's libraries in the libs folder and they aren't named like Windows dll files... you'd have to rename the dwarfort.exe on your mac version, change the script that launches it (should just be called "dwarfort" or "df" and should be editable in any text editor), then copy the windows binaries into place.  I'm 99.99% sure DF doesn't refer to it's executable file by name at any time, so this should cause no issues.  I haven't looked into it though, so I may be wrong.  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)