Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Faster, no problems

Faster, problematic

Same speed, no problems

Same speed, problematic

Slower, no other problems

Slower, problematic

Doesn't work at all

[John Keel]

I use a semi-old Macintosh laptop, and F9 is set to either show all windows at once or lower the lighting of the keyboard. This means that I'm completely unable to access the worldgen screen.

EDIT: Never mind. For some strange reason, cmd+f9 works perfectly (and cmd+q won't quit...)

EDIT EDIT: How do I set laptop keybindings now?
EDIT EDIT EDIT: Oh, there's a screen. I should really stop asking stuff.

[Baughn]

I did change how the FPS counter works in d18. It should be more accurate, but unfortunately the old one tended to exaggerate a fair bit.. makes it hard to know if reports of FPS decreases are real or not. However, if you set FPS to 200 or so, d17 will show ~220-240FPS, while d18 shows exactly 200. In both cases it's running at 200. I am unsure how strong the effect is at lower rates; if it's 10% across the board, it makes up for the noted framerate reduction.

However, the timer it uses has a one-millisecond resolution. I might be able to deal with that; meanwhile, it'll mess up dramatically if you set FPS over a few hundred, though it'll still give the correct rate when the game is actually running; it just can't deal with four-digit framerates.

The FPS counter reacting more slowly is deliberate. It uses a ten-second rolling average.

guebstrike, is that "8/8" framerate for the 2D modes supposed to be an actual framerate? Does the game actually seem that slow to react?

Darkdragon, my experience is that nvidia's drivers are far better for anything written to standards, while ATI does a lot of work making theirs work with particular games. Seeing as ATI is never going to check them against DF, you're out of luck there. I prefer to stay away from them.

[Noble Digger]

Heya Baughn,

Due to the aforementioned I'm not sure if my framerate has improved in 40d18. I did notice that the bug described at http://www.bay12games.com/forum/index.php?topic=49617.0 is still occurring though.

I'm playing using frame_buffer right now and I'll try accum_buffer later. I get a steady 20-21 FPS with FPS_CAP 100 and G_FPS_CAP 20

[Malicus]

Edit 4: For me, 40d18 seems to be slower across the board than 40d17.  When loading a fortress from 40d17, PARTIAL:0 and STANDARD are seem slower (though this could be because the FPS is recorded differently between the versions), but the FPS in 2D modes in 40d18 is less than half what it is in 40d17.

The other stuff in my post didn't seem extremely important to the 40d# branch, but this DOES, and it doesn't seem to have been addressed.  Why would the 2D modes in 40d18 be significantly slower for me than the 2D modes in 40d17?  My OS is Windows XP Pro SP3, my processor is an Intel Core2 Quad Q8400, and my graphics card is an nvidia GeForce 9400 GT.

[Totaku]

Ok I gave 40d18 a test drive with the frame rates....

Here's what I can say for it right now.....

I use a Mac OS X Tiger version 10.4.11
2 GHz Intel Core 2 Duo Processor
1GB 667MHz DDR2 SDRAM Memory

I've tested both the PC and Mac version.

To play the PC version I used Crossover Emulator V.8.0.

For the test I set Prority on HIGH and Texture to NEAREST

Here's the results of the frame rates...

STANDARD: 50-60 FPS
PARTIAL:0: 60-70 FPS (this is exactly the same as d16)
ACCUM_BUFFER: 40-60 FPS
FRAME_BUFFER: Crashes my whole computer, forced to restart computer
VBO: crashes Dwarf Fortress
changing the numbers in PARTIAL didn't change all that much, but this is a good summary.

Now for the Mac version which I ran via Terminal

Sames settings as the PC

STANDARD: 30-40 FPS
PARTIAL:0: 35-45 FPS
ACCUM_BUFFER: 35-45 FPS
FRAME_BUFFER: Crashes my whole computer, forced to restart computer
VBO: crashes Dwarf Fortress

Roughly the same result but the strange things that I noticed is that when I run DF through the emulator for the PC version...

It runs a whole lots faster compared to the mac version. It makes me wonder if the mac version isn't quite as stable as the PC version.

Plus the fact that my computer crashes entirely when I use FRAME_BUFFER really baffles me.

Course another thing I find strange is that one dwarf's death made the frame rate perform a massive jump in the PC version. Jumping from 60-70 all the way to 80-90.

Really strange if you ask me.

Any idea what would cause one dwarf (note this was a 13 population fortress BTW) to make a jump like that?

Otherwise as of this point, the PC version pretty much runs roughly the same as d16. the mac version is far more sluggish.

[Baughn]

Malicus: First off, please check if that's still the case on a fresh embark.
Also, can you post the slow save somewhere so I can take a look?

Totaku: Not a clue about the one dwarf. The game being that much slower is surprising; MSVC++ is a better compiler than the ancient gcc on toady's mac, but it shouldn't be by that much.

It would take some work, but is there any chance you could run callgrind (a valgrind tool) on it and send me the result file?

[Malicus]

A fresh embark in 40d18 at that site (7x7, lots of fish and water) stabilizes to about 83 FPS in 2D mode.
The same embark in 40d17 in 2D mode is usually at 99 FPS (my FPS_CAP is at 100), so I think it reaches the cap.

The same site in 40d18 2D, reduced to 6x6, seems to stabilize at ~91 FPS.

A fresh embark at a flat, forested 6x6 seems to reach the cap in 40d18 2D.

I could upload the save somewhere, but I wouldn't really know where to do so, so I'd need to be told to what site to upload it. Save uploaded, link below.

Edit: Oh, I should also mention this.  I am running it in a window, with [WINDOWEDX:1270], [WINDOWEDY:736], [FONT:curses_800x300.png] -- curses_800x300.png is the old (unstretched) curses_800x600.bmp converted to .png (and renamed, since it is half as tall as 800x600 was made).  Reducing the size of the window seems to significantly improve the framerate, but d17 did not have this problem.

[DarkDragon]

Darkdragon, my experience is that nvidia's drivers are far better for anything written to standards, while ATI does a lot of work making theirs work with particular games. Seeing as ATI is never going to check them against DF, you're out of luck there. I prefer to stay away from them.

Regardless of your opinion toward a company, it's best to work on ways to make a game perform on both types of graphics cards available.

But if that's your opinion I guess I won't be donating any time soon.

[Untelligent]

Malicus, try this thing. You'll need to archive the world folder to upload it, google search winrar if you don't have that.


Myself, I'm getting a reading of 2-3 FPS with PARTIAL:0, which I assume is the fastest setting and what I was using on 40d9, the version I've been using until now. I was hovering between 5 and 15 on that (on account of having 180 dwarves and a 100 z-level mountain in a 37-year fort).

My graphics card is stuck in my laptop, I don't know what brand it is or if laptop graphics processors have brands.



Also, is there any way to move the FPS counter back to the corner? It's annoying where it is now. It would also be helpful to have an init option to get rid of the new second number so I could see if my game was paused or not, which I probably wouldn't be able to do if it was moved back to the corner.

[Veroule]

I am still noticing 99% CPU usage with the FPS set intentionally low.

It would seem that Toady is setting the ENABLERFLAG_MAXFPS when he shouldn't.  I did a quick hack changing line 687 of enabled_sdl.cpp to remove the if and was able to get the CPU usage to drop sometimes.  It didn't stay down though.  Toady should review his usage of that flag during the final merge.  Perhaps only setting it when DwarfMode is actively running and clearing it in all menus and when paused.

The flag isn't the only problem leading to it not sleeping, but I can't seem to find the exact cause.  The only line I see that looks odd is 637 "if (flag & ENABLERFLAG_RENDER || 1) {".  This is optomized out by the compiler as the "|| 1" makes it always true.

I know it is a little late to suggest a large change here, but I think it would be more efficient to make that section look at relative time in terms of the performance counter directly.  What I mean is remove the division on the QueryPerformanceFrequency in enabler's constructor.  When the FPS and GFPS are set do a division to get the interval between each frame.  Then the enabler::do_frame would look something like:

Spoiler (click to show/hide)

Uint64 qpnow;QueryPerformanceCounter(&qpnow);
if ((qpnow>=nextframe)||(flag&ENABLERFLAG_MAXFPS)) {
 is_program_looping=!mainloop();
 update_fps();
 nextframe=qpnow+qprate.QuadPart;
}
if (qpnow>=nextGframe) {
 if (gps.force_full_display_count > 0) render(setup);
 render(complete);
 nextGframe=qpnow+g_qprate.QuadPart;
 udate_gfps();
}
//now the really smart thing check to see how much time passed while the game ran a frame
if !(flag & ENABLERFLAG_MAXFPS) {
 QueryPerformanceCounter(&qpnow);
 if (qpnow<nextframe) SDL_CondWait(timer_cond, dummy_mutex);
 //really should allow for minimum sleep time in that if, windows minimum is 10ms
}

[Janus]

Regardless of your opinion toward a company, it's best to work on ways to make a game perform on both types of graphics cards available.

But if that's your opinion I guess I won't be donating any time soon.

What's with the attitude? I also don't understand how you expect Baughn to somehow fix or work around ATI's poor OpenGL support.

[Xgamer4]

Darkdragon, my experience is that nvidia's drivers are far better for anything written to standards, while ATI does a lot of work making theirs work with particular games. Seeing as ATI is never going to check them against DF, you're out of luck there. I prefer to stay away from them.

Regardless of your opinion toward a company, it's best to work on ways to make a game perform on both types of graphics cards available.

But if that's your opinion I guess I won't be donating any time soon.

I kinda get the sense you're jumping to conclusions. As it stands, you're the only person with an ATI card, that I'm aware of, that has complained, so that immediately points to some form of problem on your end. And complaining that the game doesn't work on ATI cards isn't accurate, either. It runs, just not as well. And you can't really fault Baughn for using OpenGL's standard, or at least I'm assuming he is. It's not his fault if ATI cards don't have great support for OpenGL. And changing engines isn't really an option. DirectX limits the game to Windows.

Outta curiosity, what are your system specs, anyway?

[Malicus]

Okay, I uploaded the save that runs significantly slower in 2D mode in d18 here.

[Porpoisepower]

Has anyone else noticed that if you try to cursor to stone in the stocks menu it skips it? Is this:

Weird and needs reporting(Bug),
Weird and needs reporting(Blessing),
Planned feature I missed.
Not planned feature, that should be setable in dinit.txt?

[CobaltKobold]

- After pressing V(isualizer), the Tab key has no effect, but the screen isn't garbled anymore.

Wait, it was garbled before?

In several 40d# versions, probably since it's ...well, the only thing in DF that explicitly does not print characters to part of the screen, so it takes the top and bottom rows as the only things, and not skipping over the middle pane as it should, resulting in smashing the entire "This is not supposed to be useful at this point" into a few columns.
d16(linux) here: http://img682.imageshack.us/img682/3770/screenshotdwarffortress.png . Using...uh...ACCUM_BUFFER/SINGLEBUFFER:YES.
d17 did not do this in 2d modes.

Has anyone else noticed that if you try to cursor to stone in the stocks menu it skips it? Is this:

Weird and needs reporting(Bug),
Weird and needs reporting(Blessing),
Planned feature I missed.
Not planned feature, that should be setable in dinit.txt?

>Bug, already reported.