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]

Hm, I knew that problem would bite *someone* eventually. Bhelyer's code, but I'll take a look.

Meanwhile, since the crash is in gtk/glib.. a likely workaround is to avoid having any dialog boxes pop up, by setting the windows/fullscreen mode explicitly in init.txt

Unless it crashes when we call gtk_main. Sounds like some kind of versioning error/ABI incompatibility at first glance. What Debian Tycho? Stable/Testing/Unstable or what? I have a debian testing box, and it works fine on that.

[Tycho451]

EDIT: Also, the "pthread_db/pthread versions do not match" errors are very suspicious. Exactly what system are you running?

You might just need to upgrade.

I thought that too and googled it. Turns out it's likely the

Code: [Select]

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:"./libs"
command that makes the debugger look for libraries in the wrong place.
I'm running a fully updated Kubuntu 8.10 with KDE 4.2 beta.


You are right! Setting windowed mode in the init.txt lets me start the game.
Thanks a lot!

Edit:
Here's the link that makes me think the debugger error is because of LD_LIBRARY_PATH:
http://returntojava.blogspot.com/2008/11/overcome-java-jni-gdb-errors-on.html

[I3erent]

invalid handle error upon trying to start the game in.d2.....................ideas?

[Baughn]

That's too little information. You didn't even tell me what OS you're on, much less what happens other than getting that message.

[Greiger]

I think I saw somebody else mention this but I'm posting for completeness.  I also crash when I skip the movies, and I'm actually showing a drop in performance with 40d-2.

I get ~600 fps title screen with 40d
I get ~320 fps title screen with 40d-2

200 fps in a 4x4 flat waterless fresh embark on medium world in 40d
and 80 fps in a similar 4x4 flat waterless fresh embark on medium world in 40d-2

both worlds have 50 years of history generated.

1000x600 screen size with 800x600 curses.png (125:50 grid) no graphics, partial print off. GFPS cap 30.

Perhaps the code has to do so many loops and barrel rolls to work with my kind of system that it's slowed down?  I donno.

[I3erent]

invalid handle error upon trying to start the game in.d2.....................ideas?

Yeah its the win version, i double click the icon to start and then it says invalid handle error and doesnt start thats it.

[Baughn]

Perhaps the code has to do so many loops and barrel rolls to work with my kind of system that it's slowed down?  I donno.

Entirely possible.

I'm working on streamlining it, but I'm a bit stuck, what with not having the DF source to test with. Still, not giving up yet.

[Jurph]

I have several WinXP machines on which I run DF.  I use the Mike Mayday tilesets (thanks, Mike!) and I've noticed a few improvements:

• Worldgen is screaming fast!  I can put together a new world much faster than I ever could previously.
• The opening movie is ridiculously fast.
• Finder is still fairly slow, and still limited to 129 sites on the default size... but with larger worlds generating so quickly, it might be worthwhile to increase the default to a larger world so that the finder has a better chance of stumbling on an ideal site.
• Gameplay seems faster overall, starting out with maximum framerate (regardless of graphics options) and staying high until major lag activities begin, like tapping into running water for some of my plumbing, or draining the magma pipe.
  
• Hey, look, cats have a grasping mouth!

I like it!  Great work Baughn.

[Baughn]

Partial-printing is actually *broken* in 40d2, which is why some of you have seen performance decrease.

I'll fix this.

[fourthgeek]

I have an ATI 4870 on XP64 with 4 gigs of RAM and a 3.17Ghz Core 2 Duo. All tests were done on 1680x1050 w/ Graphics:NO
Here are my results:

Dwarf mode, Maximum Embark, (32x20?) 200x200 grid
Gameplay:            ~40fps
Paused:               ~120fps
Game menu:         ~440fps

Dwarf mode, Default Embark, (6x5?) 200x200 grid
Same as above

Dwarf mode, Maximum Embark, 100x100grid
Gameplay:             ~60fps
Paused:                ~900fps
Game menu:          ~2600fps

Adventure mode, 200x200 grid
Gameplay:            ~120fps
Game menu:          ~440fps

Dwarf mode, Maximum embark, Default grid
Gameplay:            ~80fps
Paused:               ~1200fps
Game menu:          ~4800fps

The game speeds up by about 20% when viewing unexplored vs. explored territory (eg, underground vs surface).

In the previous version of 40d, I get an average of 16 fps during gameplay, when paused, and in the game menu at 200x200 grid size.

[Radtoo]

Gentoo Linux x86_64 here - Works perfectly fine as shipped (I already had libstdc++.so.6), and it is definitely more constant in performance.

Comments regarding the df build: The "sdl" folder seems surplus.

Comments regarding both df and bc: I'll eagerly await the partial-printing fix - ATM the frame rate numbers aren't so easy to interpret with regards to how much faster this is as compared to running an older version in wine.

Meanwhile, would a 64 bit build be possible? Sure, even us 64 bit users can play without much of a hassle (that is, as long as we have multilib), but having to ship the 32 bit fmod library as part of df might still be one side-effect that could be avoided. And I'm sure a 64 bit integer sized stone/coin stockpile could be fun, as well. Or perhaps there'd be some performance benefits from the additional cpu registers. Anyhow, it would appeal to my sense of orderliness, at the very least.

[Baughn]

You're right that 64-bit DF would be good, but I can't do it. There are a lot of 32-bitisms in the code, and even if I fixed BC (a much larger job than the opengl stuff), there'd still be 32-bitisms in *DF*.

It would be faster, though; the doubled register count more than makes up for the doubled pointer sizes.

[Radtoo]

You're right that 64-bit DF would be good, but I can't do it. There are a lot of 32-bitisms in the code, and even if I fixed BC (a much larger job than the opengl stuff), there'd still be 32-bitisms in *DF*.

It would be faster, though; the doubled register count more than makes up for the doubled pointer sizes.

I see - thanks for the info. Well, even though I can't do a proper benchmark yet, it would seem that the improvement at hand "dwarfs" the performance that might be gained from a 64bit version, anyhow. You're doing us a great favour, here!

[Baughn]

I should have you shot for that pun.

[bhelyer]

Okay, talking with Toady, I think I've found the source of the music bug. A fix will be forthcoming.
 

And that was an awful pun.