Print

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

[Durin]

After perusing the forum and getting into one rather involved conversation about it, I find myself curious as to what the actual, factual issue is with processor usage in DF.  People state it has to do with pathing and perhaps fluid flow, but what I notice as I watch the processor it appears that it ramps up even when I am looking at the menu, and does not appreciably increase as my fortress has grown to about 100 dwarves.  The issue is that it just sits there, leaning on the processor, forever, no matter what it is doing.

This is just a curiosity to me.  I do not say this is something "wrong", nor am I trying to get any advice about not buying HP laptops in the future due to poor heat management, or anything else.  :-)  It just seems as if something about how this sucker works pulls constantly on the processor as a matter of course rather than as a function of what it is doing.  If you run out of processor to feed it, apparently the frame rate suffers, but right now I am noting no particular problems with framerate.  I just don't get why even when it is paused, or waiting at the initial menu, it instantly starts jamming my processor, and curiosity forces me to wonder why, so I thought I would ask.

[Fieari]

Are you using the 40d## versions, or the official plain 40d?  If you're using the official version, your problem is the OpenGL renderer, and you'll find a massive speed increase by going 40d##.

[Shiv]

It's pathing, no doubt.  Even fluid flowing isn't an issue unless there're critters living in the river. 

Whenever I pause the game I get about a 60 frame increase.  Also when I have a lot of idlers, I get good frame rate, but when I do a massive dump of stone it sucks my FPS dry. 

Even more so, if I dump out of a room with a single door way, my FPS goes to shit.

[corvvs]

It's because it gets input the same way most old DOS games did - it makes a tight loop polling the keyboard "didanythingnewhappen?didanythingnewhappen?didanythingnewhappen?" End result is it uses a lot of CPU.

I think this is changed in the 40dxx versions because of using SDL for input, but they could still be polling, I don't know.

When people talk about how the CPU cycles are spent (pathing, flows) they're talking about what actually delays frame calculations - input polling is simple and instantaneous, so it doesn't delay anything, just makes sure that your CPU is producing as much waste heat as it can.

[Greiger]

I think the game is constantly checking something or another, maybe keyboard input or something.

Whatever it is it pretty much means it's always using up a full CPU, but whatever it's done doesn't slow anything down or stops doing what it's doing once there is actual processing going on.

Framerate is yer best bet for gauging CPU capability IMO.

EDIT: Beaten

[ArkDelgato]

I read the title of this thread as "Professor Grind"

I thought it was a good WOWGOLD spam account topic or some adventuremode trainer macro.
But it turned out to be serious

[Durin]

I read the title of this thread as "Professor Grind"

I thought it was a good WOWGOLD spam account topic or some adventuremode trainer macro.
But it turned out to be serious

LOL!

As to the rest, just for the sake of settling my mind, I am going to go with polling the keyboard, although I think I will try 40d## OpenGL version just to see if it makes a difference.

Polling the keyboard is the only thing that explains why it goes berserk even when in opening menu mode.

Just for kicks I went ahead and started a fortress at the max size, and the processor churns almost at the same rate.  It's just that when I am perusing the map or occasionally just because it's busy, I get a little lag.  So there's the distinction.

Thanks for the info folks.

[Dakk]

Its mostly pathing. DF checks best path for a dwarf, calculates his average speed (agile, very agile, etc), and chooses a path, i don't know how the algorithm works, but toady mentioned something about it being inefective and wanting to rewrite it. As mentioned above, DF seems to use the old DOS game method of pooling through the keyboard keys to check if anything's happening. Fluid flow is only a problem when you're doing some megaproject-ish thing like moving tons of water/magma around.

The 40dxx releases increased OpenGL support plus some other stuff, so you might wanna try that. But we won't get a revolution in FPS increase until the pathing rewrite comes, and it won't be anytime soon, me thinks.

[Kardos]

Its mostly pathing. DF checks best path for a dwarf, calculates his average speed (agile, very agile, etc), and chooses a path, i don't know how the algorithm works, but toady mentioned something about it being inefective and wanting to rewrite it. As mentioned above, DF seems to use the old DOS game method of pooling through the keyboard keys to check if anything's happening. Fluid flow is only a problem when you're doing some megaproject-ish thing like moving tons of water/magma around.

The 40dxx releases increased OpenGL support plus some other stuff, so you might wanna try that. But we won't get a revolution in FPS increase until the pathing rewrite comes, and it won't be anytime soon, me thinks.

Pathing rewrite will either come soon after this release, or in a year or two.  (Based off of the last talk show's plan for army arc and siege mechanics)  The rewrite will be needed to properly support multi-tile mobile objects such as siege engines or boats.  And stationary ones such as trees.  So in my opinion, when either of those come in, the pathing upgrade comes with it.

[random51]

The lag from presumably pathing of invisible creatures is the worst.  I can tell when the game spawns a few ambush squads around the map long before I actually uncover them because of how the game slows downs.

[Grax]

After perusing the forum and getting into one rather involved conversation about it, I find myself curious as to what the actual, factual issue is with processor usage in DF.  People state it has to do with pathing and perhaps fluid flow, but what I notice as I watch the processor it appears that it ramps up even when I am looking at the menu, and does not appreciably increase as my fortress has grown to about 100 dwarves.  The issue is that it just sits there, leaning on the processor, forever, no matter what it is doing.

Same thought come to me last night. ;-)

But. DF just trying to maximize FPS cap. Mine set to 900, and at the menu it consumes 48% of processor time (the whole core of two) and gives ~500-600 FPS.
If i resize the window to be less - FPS simply rises to 1000, stops then - and with further resizing makes the processor usage fall to 40-30%.

So i think there's not only pathfinding but a screenwriting "handbrake"s (at least on my working comp with integrated video).

[Toady One]

Last time I checked this on my own computer, which was for 40d, I was at 0% in the title screen, for example, so it's not a keyboard polling problem (that situation is handled in the main loop), but something more specific to the computer in question.  It is a common problem though, and people that have had this problem have had a lot of progress with the 40d# versions if I remember.  For problems in menus, it pretty much comes down to how the OpenGL code is implemented and that some newer cards no longer support how 40d does things (again, if I remember).

[Neruz]

DF will quite happily use as much of the processor as it can, it's eerily efficient like that. I once set FPS to 10,000 so as to just get maximum FPS at any given time, and the result caused my system to freak out as DF promptly rammed one core up to 100% and left it there (getting something like 7000 FPS on the menu or something rediculous, i don't remember.)

I've left FPS at 100 ever since.

[Tack]

Well mine's about 10 - 15 when paused, 55% when running, and around 80% if i run it in the background while browsing forum. I'm on D11, but I'm using no frame_buffer. Don't even know how that stuff works.

[Neruz]

Try D16, see if it helps any.