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

[Baughn]

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

And I'm not. I don't get it.. what circumstances cause that?

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.

..aagh.
That ||1 was not supposed to be there. Well, there we go then. *sigh*

[Grimlocke]

Ok, after some buggering around I got a smashing 6 fps added to my previous 130 fps (which I got from the d-less df), using [PRINT_MODE:PARTIAL:1], [SINGLE_BUFFER:NO] and [VSYNC:ON].

The 2D modes all gave abyssmal framerates, while standart, frame_buffer and accum_buffer were 10~20 percent behind on partial. VBO just crashed, as it seems to do in all d# for me.

Setting the number behind partial higher than 1 didnt seem to change anything, while setting it to 0 made it do about the same as standart.

SINGLE_BUFFER:YES cost me a percent or 2 from all the faster modes.

VSYNC didnt make any noticable change in fps.

While the 6 fps may not be a huge boost, im still happy with the better keyboard input repeat time setting.

Edit: adventurer mode is pretty broken. Dying makes you get stuck in the menu, and theres some cases of it ignoring keyboard inputs after some announcements show up.

Nother edit: [KEY_REPEAT_MS] and [KEY_HOLD_MS] dont seem to do anything. It just sticks around 250ms. Noticably slower than what I set it to.

[Veroule]

Testing speeds at the main menu gave results of STANDARD and PP:0 as the fastest. 

VBO crashed and I took some time to look into it.  It seems that the crash is an exception being raised at line 1196 of enabler_sdl.cpp when attempting to reference ptr_bg_color.  Looking further down at line 1679, "if (!vbo_refs[0]) { // We don't need these in VBO mode", it skips initializing the vectors to anything.  This is why "&ptr_bg_color[0]" is crashing.  If you add the appropiate if around those references at 1196 we should be able to test and use VBO.

[Veroule]

Just for giggles I nop'ed out the "if (!vbo_refs[0]) { // We don't need these in VBO mode" to avoid the crash.  For the adventurous Win users with hex editors the ofset in the .exe is 1399a7, values of 75 65 change to 90 90.

VBO resulted in no display but was responsive.  FPS indeterminate.

[Baughn]

Actually, the problem was that it was trying to use those vectors even in VBO mode, which it isn't supposed to. I fixed that instead.

Then I decided to fix the fallback mechanism so it won't crash, and then I decided to drop glMapBuffer in favor of glSubData as suggested elsewhere. And now it works. Not uploaded yet, though.

[zagibu]

Text mode is very cool, but why is the black not completely black? It seems to be a dark gray instead...

[slink]

Fortress: Icywaters

40d
PARTIAL_PRINT:NO => 20 - 23 FPS

40d18
STANDARD => 18 FPS
PARTIAL:2 => 19 - 22 FPS
ACCUM_BUFFER => 16 - 18 FPS
FRAME_BUFFER => 18 - 19 FPS
VBO => crash on running

[WINDOWEDX:960]
[WINDOWEDY:600]
[FONT:Tileset_unknown_960x300_02.bmp]

WIN XP SP3
NVIDIA GeForce 9800 GTX+, resolution 1024 x 768
Pentium 4 3.80GHz
2.00GB Ram

[Vince]

Just for giggles I nop'ed out the "if (!vbo_refs[0]) { // We don't need these in VBO mode" to avoid the crash.  For the adventurous Win users with hex editors the ofset in the .exe is 1399a7, values of 75 65 change to 90 90.

VBO resulted in no display but was responsive.  FPS indeterminate.

It works for the first time ever!
Well, at least it doesn't crash anymore.
Now I have a black screen instead (with music).

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.

You donate to Toady, for the game itself, so to say, not for the programmers of the 40d#-versions.
And believe me, ATI should do it's best to follow the standards, not the other way around.
Don't get me started on their handling of non-quadratic textures in OpenGL...
Baughn and co are doing their very best to make DF perform equally well on all types of graphic cards, but don't think a new renderer especially for ATI would get you 50 fps with 150 dwarves, because this:

Wait, is this why I read about people having 150-dorf forts and getting 50FPS or more, while I hit rock bottom at around 80 dorfs and can't crawl my way above 20 FPS? Because I run ATI?

is a matter of processing power, not the renderer (IMHO).
The pathfinding, the number of stones in a fort, SO MANY things have a big impact on the pathfinder (and thus on the performance) that I don't think a ATI-optimized renderer would help you at all.
What processor do you have? How many stones are in your fort? Maybe there is a way it can run a lot faster on your system.

[Baughn]

VBOs should now /actually work/, in d18-head at least. Veroule's solution amounts to disabling them, I'm afraid.

The fallback works too, so if VBOs fail you should get Standard output instead.

..I don't think the VBOs help much, but it might for someone.

[Baughn]

Text mode is very cool, but why is the black not completely black? It seems to be a dark gray instead...

Mapping colors to text mode is annoyingly hard, and not at all helped by different terminals showing them differently. It's a work in progress; I don't think it'll ever be perfect, but playable should be achievable.

[cbpye]

Text mode is very cool, but why is the black not completely black? It seems to be a dark gray instead...

If your terminal emulator supports themes or profiles (such as Konsole) you might want to check to make sure yours is using a white-on-black theme.

[Baughn]

Let's see.. there, that should make 2DASYNC a bit faster.

[Krythorne]

I apologize if this if known information (I searched through previous pages but I'm aware it may have been in a previous thread) but ATI is terrible with VBO's unless the information for each vertex is padded/aligned to 32 bytes or 64 bytes.

I'm only bringing it up as reading of people having ATI crashes/poor performance is giving me terrible flashbacks when I found a small demo I did worked great on my main machine with an Nvidia card, had terrible performance on my older machine with an ATI card and wouldn't run at all on a friend's machine with an even older ATI card. It worked fine once I'd padded the data to leave the step between vertices at 32 bytes.

I briefly checked the source code and the steps between vertices are 8 bytes for the two buffers handling drawing and texture coords (vbo_refs[0] and vbo_refs[3]) and 16 bytes for the two buffers handling colour(vbo_refs[1] and vbo_refs[2]). You could try changing them all to be 32 bytes, add the extra padding to each array and add the stride value manually to the pointers to them so they're on the lines of  'glVertexPointer(2, GL_FLOAT, 8*sizeof(GLfloat), 0);'. I know at the moment they're all in their own arrays instead of an interleaved one and it's in the OpenGL spec that having a stride value of '0' for those pointers should be supported but it's my guess ATI ignored that.

The good news is this brought an improvement even on Nvidia cards for me and I've filed it away as just one of those little quirks to remember.

[guebstrike]

Autohotkey works great with 40d18.

I've been digging diagonal tunnels using the ctrl-alt-keypad mining script from the wiki (plus the recommended delay), and it performs well on d18. Even though it is not very fast, it never has an error. With all other 40d versions I had problems with scripts missing a beat and screwing up, which no amount of init.txt finagling could totally fix. Now it never screws up. Yay!

Also the keys don't get stuck when scrolling. I've always had problems, with previous versions, when mining or scrolling around. The scrolling would stick and I'd have to mash some combination of keys to make it stop.

I do have the double click error that was mentioned previously. It is especially noticeable in world gen, menus, and when naming ssaavveess.

 Update: I just dug 1375 up/down staircases using A.N.Other's Link and Dive staircase mining scripts with zero errors. It does not require any key delay (either in the script or in init.txt). It always works.

[Diamond]

Never mind, problem solved, move along.