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

[kutulu]

Is there a reason for nearly every single file in the linux tarball to be marked executable? Seems like a security issue to me.

EDIT: Ok right off the bat I'm getting this error:

Code: [Select]

$ ./df
./dwarfort.exe: error while loading shared libraries: libSDL-1.2.so.0: cannot open shared object file: No such file or directoryRunning locate tells me it's at /usr/lib64/libSDL-1.2.so.0

Currently installing the 32-bit version to see if it'll find that. Will edit again with results.

The binary is 32-bit, so your dynamic loader isn't going to pay any attention to 64-bit libraries.  You'll need 32-bit copies of everything that's not already in the tarball.

[Baughn]

They shouldn't all be marked executable, but it's a cleanliness issue, not a security issue.

I'll look into it, I guess.

[Toksyuryel]

Ok it's no longer complaining about libsdl now that I got the 32bit version installed. However, now it is complaining about libtiff, which I DO have a 32bit version installed.

Code: [Select]

$ ./df
./dwarfort.exe: error while loading shared libraries: libtiff.so.4: cannot open shared object file: No such file or directory
$ locate libtiff.so
/usr/lib64/libtiff.so
/usr/lib64/libtiff.so.3
/usr/lib64/libtiff.so.3.8.2
/usr/lib32/libtiff.so
/usr/lib32/libtiff.so.3
/usr/lib32/libtiff.so.3.8.2
I believe it is looking for version 4 of libtiff... which only currently has an alpha release. 3.8.2 is the last stable release of it. Are you requiring the alpha version of libtiff, or is this a mistake?

[brainfire]

If you symlink libtiff.so.4 to .3 then it works just fine. I did it in <df directory>/libs, for minimal potential for breakage.

I think the reason for this is explained earlier in the thread. IIRC it's related to some Debian weirdness.

[Toksyuryel]

HOLY MOTHER OF ARMOK THAT IS FAST. I think I may actually need FPS limiting for the intro because it went so fast the sounds overlapped... WOW. That was amazing. Toady, you rock hardcore.

[Baughn]

I'm the one who actually wrote that code, though. 

[Toksyuryel]

Oh, ok. Baughn you rock hardcore.

^_^

[Baughn]

Hehe. Anyway..

At http://brage.info/~svein/df40d11-resizing.tar.bz2 is a not-so-experimental build that allows you to resize the DF window while it's running. I've already submitted a patch to toady, but I figured someone might like to try it.

Which reminds me, I was supposed to make the initial grid-size calculation automatic too.

[Fieari]

What's the chance your tinkering will enable smaller grid sizes than currently allowed (to support things like 32x32 tiles)?

[Baughn]

Zero.

However, interestingly, this build does allows larger grid sizes than 200x200.

Actually using them would probably result in disaster, though it didn't in my test.

[Footkerchief]

Does the auto-resizer increase the grid size, or just stretch the current grid?

[Baughn]

It increases the grid size. To beyond 200x200 if asked, which *does* crash the game eventually.

I've fixed that, and added a zoom function. You can now zoom the game by using the mouse wheel; it should of course be a rebindable function, but toady will have to do that part.

So, http://brage.info/~svein/df40d11-zoom.tar.bz2 now.

[Footkerchief]

Wait, so you can... zoom out to see the whole map?  Like Supreme Commander or something?  Or is it some other kind of zooming?

[Baughn]

Subject to the 200x200 grid limit, but if it fits in that, then sure.

[brainfire]

The zoom is awesome. Is there/will there be a way to 'reset' to the original zoom level?