Print

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

[Lightman]

I'm having this problem, too. I've upgraded the drivers and switched everything to high performance. It didn't help. With or without vsync, DF takes 40-50 CPU at the menu.

[koitsu]

Alright, this bug should really be at the top of the 300 Toady is trying to diminish.  If I have to, I will bust out a profiler and figure out what this thing is doing with all the CPU time it chews.  I've said for years now that the program acts like it's wrapped in a while(1) loop, and that's really proving to be true.  This mentality was used when developing applications for DOS, on old Apple II systems, and so on -- absolutely NO present-day application should be written in such a way.

Additionally, for users: the reason it takes up 50% CPU for some of you and 100% CPU for others is because many of you are using dual-core systems (50% load == 100% of one single CPU, and DF is *not* threaded), or Intel systems which use HyperThreading (which in most cases are 1 physical processor, with 2 logical processors -- in this case, 50% actually means 100%.  :-) ).

Toady, if you want hardware donated to you to work on this, I will *gladly* buy you new hardware (including a full system if need be), free of charge.  As it stands, DF is wasting quite a lot of electricity for no justified reason.

[axus]

Haha you could sell your integrity and use Windows for less than it costs to buy Toady a new system  

[Jifodus]

The game is wrapped in a while(!quit) {}, and uses PeekMessage() to handle messages.

Imo, Dwarf Fortress should be designed this way (I don't think you'll ever meet a real-time game not designed like this)

Sure at menus instead of PeekMessage() it could be GetMessage(), but that would make redrawing much harder. Take a look at Kobold Quest's source code to see how the engine is designed.