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

[vix0r]

Doesn't run for me.   On running I get "FATAL ERROR: Main index file missing/corrupted.  The file "index" must be in the "data" folder.  Make sure DF decompressed into its folders properly.".  I've verified that the index file is indeed there and dated today.  Also tried a completely clean folder with the same results.   

If I replace the index file with the one from .40d it starts to run and I hear the intro sound etc, but the screen is black.  There will be an occasional block of color but 99% of the time it's just black with no output.

Vista x64
GeForce 8800 GTS (driver version 180.48)

[e] redownloading the package seems to have fixed the problem.  Dunno why.

I'm having this problem as well. Tried redownloading both DF as well as this patch, and no matter what, it gives me that error.

If I use Dwarf Fortress.exe, however, I can play, but it doesn't seem like any sort of speed patch has been applied.

Sorry if this has been addressed, but this post is the only one that turned up in my search. I'd really like to get this working, since I'm stupid and made a perpetual waterfall into my bottomless pit.

Is there any pertinent information I can provide you with to troubleshoot this? I'd like to get this working if at all possible.

I'm running Vista x32, nVidia GeForce 9600GT. I can provide other specs as needed.

[bombcar]

I get a segfault when exiting on Mac OS X - is this normal?

macbookpro Dwarf Fortress $ ./df 
Using OpenGL output path with client-side arrays
Ideal catalog size: 384x368
Using OpenGL output path with client-side arrays
Ideal catalog size: 384x368
Ideal catalog size: 1008x1008
./df: line 4: 78570 Segmentation fault      ./dwarfort.exe

Yes, unfortunately it is. The crash is in the sound code somewhere, but I can't seem to figure out where.

Interesting, as I have sound set to off. Shall I send you the logs? Do you want me to attach a debugger to it?

[Baughn]

I don't actually have access to an OS X machine to test on right now, so it would be pretty pointless for my part.

That said, if you want to try debugging it, I'd advise you start by git-cloning the newest version of BC from the link in the thread starter. Debugging information from that would be quite valuable, as you can build it with debugging code in.

[bombcar]

I will try my best to do that and report back what I find.

[Sowelu]

If you want a game to compare DF to, compare it to SimCity 4 or something. It's doing about the same amount of work in the background running the simulation.

SimCity 4, on my very modern machine, frequently 'hangs' its calculation threads when it needs to do pathfinding.  The graphics stay perfect, but if you watch the game clock on 'very fast', it'll breeze through the game days, then sit at one day for several seconds until it is done pathfinding.  Because nothing meaningful in the simulation moves in realtime (the little car automatas, even in emergencies, aren't really part of the real simulation) this is very invisible to the user.

[bombcar]

I assume you're using the Network Addon Mod - or it would be painful.

Baughn - new information: Opening DF, and then quitting right away does not segfault. Loading a game, saving, and quitting, does.

As such, I can't get BC to segfault. I tried.

[Baughn]

Do you use a graphical tileset?
Does it happen if you don't?

[bombcar]

Yes, using a tileset (RantingRodent's). If I turn GRAPHICS to NO it does not segfault on exit.

[Soor]

Runs fast.

Crashes on save, but saves correctly.

Occasionally crashes at random, leaving it running in "not responding" mode eventually has the nvidia driver kill it.

This all with graphics on.

Vista 64 and NV 182-series drivers.

[Baughn]

Sorry?

Define "all graphics on", please. Better yet, quote your init.txt.

[Soor]

Sorry, I meant all that happening with graphics: on, I haven't got partial print or other fancy stuff enabled. Mike Mayday's sets here, 100x60.

I'm gonna try messing around with nhancer to see if there's anything that's giving DF grief - my base settings are pretty conservative, but I noticed OGL triple-buffering forcing is on, which could be the cause here.

EDIT: enabled partial print (30) and framebuffer, disabled triple-buffer forcing and enabled "high quality" texture filtering for DF (NV stock is "Quality" which does some optimizations) and its not crashing anymore.

[bhelyer]

I get a segfault when exiting on Mac OS X - is this normal?

macbookpro Dwarf Fortress $ ./df 
Using OpenGL output path with client-side arrays
Ideal catalog size: 384x368
Using OpenGL output path with client-side arrays
Ideal catalog size: 384x368
Ideal catalog size: 1008x1008
./df: line 4: 78570 Segmentation fault      ./dwarfort.exe

Yes, unfortunately it is. The crash is in the sound code somewhere, but I can't seem to figure out where.

Is that mac specific, Baughn? If not do you know how to reproduce? I'm the one that wrote the crap sound code, and I could save you the digging if I could get it to reproduce. I'll have a look tonight, regardless (I have finally re-set up my dev environment; bloody computer troubles).

If it is mac specific, would you be so kind as to give me a back trace from gdb? (This is why I shouldn't post, then read, I guess )

But if it is happening when the sound is off, that is strange because as I recall, all methods just bail straight away in that case.

(Oh, and hey bombcar! /waves)

[AmzRigh]

While I did notice things moving slightly faster, I would not say I got a significant speed boost out of this.  But hey, any improvement is worth pursuing, especially since it seemed to do wonders for so many other people.

For testing purposes, I loaded up my current late-stage fortress, first in 40d, then in 40d9, both running full-screen 1680x1050, using a 16x16 tileset (no graphics) with a 105x65 grid.  The only noticeable improvement I saw was that scrolling in the x-y plane was a little less laggy than before (though neither were particularly slow).  I feel stupid for not knowing where I look to get fps, else I'd report that, too.  The gain for me may be more significant than I realize.

System specs, for what it's worth:
Core 2 Duo 3.0GHz
4GB DDR2 800 RAM
GeForce 8800GT
WinXP x64

[Soor]

I feel stupid for not knowing where I look to get fps, else I'd report that, too.  The gain for me may be more significant than I realize.

In init.txt.

As far as performance, as far as I can tell 40d# decouples the fps from the main calculations when it comes to performance; my fps is pretty stable at all stages of the fortress - being dependant almost purely on the number of moving things on-screen - and therefore so is control lag, but the game speed is still scaling noticeably with the number of creatures pathing around the place.

[Baughn]

I feel stupid for not knowing where I look to get fps, else I'd report that, too.  The gain for me may be more significant than I realize.

In init.txt.

As far as performance, as far as I can tell 40d# decouples the fps from the main calculations when it comes to performance; my fps is pretty stable at all stages of the fortress - being dependant almost purely on the number of moving things on-screen - and therefore so is control lag, but the game speed is still scaling noticeably with the number of creatures pathing around the place.

Graphical fps, you mean?

Yeah, that will only start to fall once the simulation fps falls below the g_fps cap.