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

[Rift]

Heres some tests with using a higher resolution and grid size.

2.8ghz hyperthreaded p4, 1 gig of ram, geforce 7600GS fullscreen with 1240:1024 resolution and fullgrid 80:64, with 7 dwarves busy about tasks. [All settings like temperature/weather are ON and using a graphics set]
I tested a bunch of different partial print/G_fps caps with a 500fps cap.

Using regular 40d: [The old standard]
14 G_fps/4 PP:
outside with cliff: 320fps
outside: 335fps
inside with quarter explored: 354fps
inside with tiny explored: 360fps

Testing the new stuff:

Spoiler (click to show/hide)

for the "frame buffer" option.
With Yes:0:yes:no, and the f_gps did not change the fps very much. 14 was only a few fps faster then 50.
outside with cliff: 75fps
outside: 90fps
inside with quarter explored: 100fps
inside with tiny explored: 120fps

Comparitively, it ran in the middle of all my results [but a hella lot less optimized when there is unexplored space]. The others, using just partial print/gfps cap manipulation.

G_fps/PP format.
15/NONE:
outside with cliff: 58fps
outside: 68fps
inside with quarter explored: 87fps
inside with tiny explored: 93fps
15/20:
outside with cliff: 80fps
outside: 95fps
inside with quarter explored: 130fps
inside with tiny explored: 140fps
50/55:
outside with cliff: 73fps
outside: 90fps
inside with quarter explored: 124fps
inside with tiny explored: 130fps
1/2:
outside with cliff:73fps
outside: 90fps
inside with quarter explored: 124fps
inside with tiny explored: 130fps
15/4:
outside with cliff: 83fps
outside: 98fps
inside with quarter explored: 133fps
inside with tiny explored: 145fps
15/2:
outside with cliff: 77fps
outside: 92fps
inside with quarter explored: 128fps
inside with tiny explored: 140fps
10/4:
outside with cliff: 77fps
outside: 93fps
inside with quarter explored: 127fps
inside with tiny explored: 140fps
15/3:
outside with cliff: 75fps
outside: 90fps
inside with quarter explored: 120fps
inside with tiny explored: 130fps
14/4: [BEST FOUND]
outside with cliff: 87fps
outside: 104fps
inside with quarter explored: 139fps
inside with tiny explored: 151fps
13/4:
outside with cliff: 81fps
outside: 96fps
inside with quarter explored: 134fps
inside with tiny explored: 144fps

In the end, it seems 14 g_fps and 4 PP works best for me, way better then the frame buffer. I would guess any lower causes them to skip or something, but i have no graphical issues at all with 14g_fps and 4PP so its fine to use... I don't know if this is "good" or "bad" comparitevly. But at 7 dwarves it's certainly playable.

All in all, while 40d6 is "playable" with 7 dwarfs for me.. comparing it to just 40d, the preformance is very very sad.

[Baughn]

To the ones who've gotten bad performance:
Yes. There is a problem. I'll quote verbatim the mail I just sent to Toady; feel free to check the CPU usage on the main menu for yourself, as that seems to be the source of the malaise.

There's a problem here. To wit:

My version of BC gets 230,000 FPS on the main menu. If I limit it to some reasonable framerate, it uses 0% of the cpu (of course).

I get ~7000 FPS on the main menu in 40d.
I get.. 1,500 FPS on the main menu in 40d6... also, it uses all my cpu time, no matter what.

Now, BC and 40d6 are supposed to have near-identical code as far as the main menu goes, so obviously there's something horribly wrong here. I'm sending you an up-to-date copy of enabler_sdl.cpp to compare to (it's got a few appendixes I never sent you as patches, but should otherwise be fine); could you do the same with yours?

I can't track the problem down myself, but *something* is eating that CPU time, and at this point just pausing randomly while it's running the main menu should be about enough to find it.

[Juason]

I wanted to say Thank You for trying to improve the game performance.  I will be setting up some performance comparions over the weekend and add them to your list. 

[Narmio]

OK, I've been playing with d6 for a while now and had no problems.  Speed is really, really great, although I've started a new game and don't have too much stuff or dwarves yet.

I just had a crash, though.  I walked away from my machine with DF paused and on returning I've got an error message saying "The NVIDIA OpenGL Driver encountered an unrecoverable error and must close this application.  Error 13." 

Sorry I can't give any more details, but I wasn't at the machine at the time.  My theory atm is that it could be caused by the 10 minute display sleep.  After posting this I'll test that out by setting the sleep timer to 1 minute and testing.

Specs:

Vista 64,
8800 GT,
nVidia driver version 178.13.


Edit:  OK, tested display sleepage, that didn't reproduce the bug.  I tried testing put-computer-to-sleep, but Windows didn't seem to want to do that, regardless of whether DF had window focus (which seems to halt display/computer sleep).  Other things that might have triggered after a 20-30 minute period would be HDD sleep, maybe a few other things.  I don't have any third party screensavers or anything (that I know of) scheduled or happening in the background.  Sorry Baughn, that's all the info I have.  When I next get bored of my fort I'll leave it with the exact settings I had the crash on the first time and go away for half an hour again and see if I can reproduce the crash at all.

Edit 2:  OK, I just had another random crash, identical behaviour, but while I was at the machine.  I was just designating walls when DF froze, my screen went black for a moment and then I got the error.  There's some popup from the system tray saying nvdsomethinseomthing has had a crash from which it has recovered (the precise name of the file I haven't got yet), but DF doesn't recover from freeze - just goes black and has to be exited.

Edit 3:  Forgot to say, I'm using YES:0, YES, No since I have an 8000 series and it is working great except for those crashes.

[Volfram]

Could that mess up my comp? If it did, what would happen?

Not unless you have less than 5GB of free disk space.  The installer's practically idiot-proof, and I think it even lets you choose which OS you want to set to the default.(Usually Windows.  There's about 30 seconds while the computer's booting when you can decide manually whether you want to boot Windows or Linux.)

I'd recommend Baughn's installer, though.  It's got half as many steps as my method, and is therefore twice as idiot-proof.(All the newer Ubuntu distros come with a copy of WUBI, though, so they're both perfectly safe otherwise.)

The only reason I don't have Ubuntu installed on my laptop is because I can't afford the space, honestly.(Anime and video games take up a LOT of space!)

[schm0]

There's still one problem- if I drag the window around it leaves bits and pieces of the display lying around. But I've always gotten that problem wining it on this machine too, and I don't get it on my other linux machine, so I'm thinking it's something on my end, especially because I don't think anyone else has mentioned it that I've seen.

I'm getting that, too. Not a major bug, but something to report nonetheless. When you drop the window it runs fine.

I'm not running linux, though.

[brainfire]

Oh, no, my window contents disappear while it's moving. But after it stops, there's bits and pieces of the display all over the screen outside the window.

(screenshot from 40d5)

Spoiler (click to show/hide)

[The Doctor]

There's still one problem- if I drag the window around it leaves bits and pieces of the display lying around. But I've always gotten that problem wining it on this machine too, and I don't get it on my other linux machine, so I'm thinking it's something on my end, especially because I don't think anyone else has mentioned it that I've seen.

I'm getting that, too. Not a major bug, but something to report nonetheless. When you drop the window it runs fine.

I'm not running linux, though.

That happens to me alot with a bunch of windows, mostly games.

It's normal. I'm pretty sure it has to do with the OS, not the game.

[QuinRiva]

I still can't get this to run at all under windows.

No errors, no screens, just 100% CPU usage and nothing happens.

40d works just fine, but I have tried 40d2, 40d5 and 40d6 none have worked.

Is there any sort of debug output that I can help you with?

[LASD]

40d6 works wonders for me.

With only partial print on the game was slightly faster, but Adventure Mode was still quite choppy. I tried putting frame buffer on and it blew my socks off. Now even Adventure Mode flows like water, amazingly in 160:75 grid too, which I was scared to try out in earlier versions.

My hat's off to you Baughn, and once again to you Toady.

[Footkerchief]

I'm also getting 100% CPU usage at the main menu in 40d6.  Do you need my specs or is that bug pinned down already?

[Hardrada]

I'm getting the same crash as Narmio, the third time it happened I got a screenshot of the error message before it disappeared:
"Display driver has stopped responding and has recovered
Display driver nvlddmkm stopped responding and has successfully recovered."
It happens in full screen and windowed modes, DF stops responding and soon after a runtime error message appears twice and DF closes.  I'm also using Vista 64 and a Nvidia 8800GT.  I've got [PARTIAL_PRINT:YES:0], [FRAME_BUFFER:YES], [SINGLE_BUFFER:NO] in my init file.

[Baughn]

Yeah, nVidia's vista driver is buggy.
All I can suggest is to disable the framebuffer; it's a more advanced way of using the card, that is thus more likely to be buggy. Use pure partial-printing with more redraws instead, or just no partial-printing.. or upgrade to windows xp. That works too.

[Soralin]

d406 doesn't have the gfps slowdown problems that d405 had.  Although 40d6 seems to be a bit slower then d40 for me.  Unpaused on the old map I was running, I get about the same fps in both with partial print on in both.  Although when it is paused, there seems to oddly be a large difference.  With partial print on and set to 0, I can get around 800-900fps in 40d paused, and it used up around 20% of the cpu, but with 40d6, I'm getting around 170fps paused, and it's using 90-99% of the CPU to do so.  On a starting 6x6 map, 40d got to around 900-1000 fps, using 10% of the CPU, and 40d6 was around 300-500, again, using 90-99% of it.  In the fresh 6x6 map, I get around 200fps in 40d6 unpaused, but I get around 350fps in 40d unpaused.

Also, the
[FRAME_BUFFER:NO]
[SINGLE_BUFFER:NO]
Options don't seem to have any effect at all for me, I tried changing one or the other of them to YES, and no effect, I even tried changing both of them to YES, which you said should cause problems or such, and it had no noticeable effect in fps or visuals, but then I also don't have any flickering or such in 40d or d6 with partial print on and set to 0 in any case.  Wait, there are some subtle changes, there's some red tiles that appear outside of the movie frame when I space through the opening movies, with frame buffer off, they last one frame, but with it on, they stick around.  And with them both on, there's a very slight drop in FPS I think, so it looks like it's doing something, but doesn't make much difference.

Also in 40d6, I found that If i press down two arrow keys at the same time to move along a diagonal, sometimes when I release one of them, the cursor stops moving completely, rather then continuing on in the single arrow held direction.  I can't reproduce the same problem in 40d.  Or even more reproducible: hold down the arrow key in one direction, and then tap in a different direction and it stops moving.  So if I'm holding down the right arrow, and then tap the up arrow and release it, or hold it down for a short while then release it, it stops moving completely when I release the up arrow, even though the right arrow is still held.  It makes it a bit annoying scrolling over large distances.  Although that seems to apply in the previous versions other then 40d as well.

[Baughn]

The slowdown is a known bug, though I haven't quite figured it out yet, it'll get fixed. Considering that a lot of people get faster DF *anyway*, it should be fine.

You're right about the keys, but it was that, or risk the sticky keys bug from 40d. Which would you rather have, a requirement to re-press the scroll keys, or scrolling you can't turn off?