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

[jaked122]

the single buffer option would most likely be best used without partial print that is for those of you who  can support multiple frame buffers...

[Veroule]

After you manage to actually implement the things in my previous post we can then move on to this idocy of continuously looping when the app is only waiting on user input.  When sound is off the main menu, options menu, keybindings menu, stocks screen (and all of its sub screens), trade screen, relationships screen, histories, and jobslist (since it doesn't flash legenedaries) all rely solely on user input before change in the display can occur.

Why run a loop that eats CPU testing for input when there is a simple system in place that already tests for this.  In Windows that is the WaitMessage, SDL appears to have something similar so establishing multiplatform support through a single call should not be hard.

A single flag in each view (Toady would have to add it) that indicates whether the view should loop or just go to an appropiate wait.  Once that is done we can have 0 FPS and 0 CPU at all the views I listed above and still have instant user response.  Where this will actually make the most difference is in Adventure mode where everything is based on user input.

The keyhold, repeat characteristics would require adjustment for this.  The current message tracking is based off keydown and keyup messages.  It would be easiest to use looping after a keydown message then when its corresponding keyup message comes in switch back to waiting.

Just something to think about down the line.

[KaelGotDwarves]

Correcting PP to only draw when there is a change in the data or an OS request will obviously eliminate this CPU overhead.  I don't know how many I have to state it before it sinks in, if the image hasn't changed don't redraw it.

Isn't that what Partial Print does already?
I just wanted to note that my shitty laptop started a 40d7 large 6x6 fort at 300+fps, when it started at 200 with original 40d.

My settings are YES:2 NO NO - and now fps is around mid 200s with more dwarves - the old version slowed to a crawl- 50 fps or lower.

Great work.

EDIT: Veroule - my adventure mode lagged until I edited the 150 ms keystroke time in the init to 100 ms or less. Now it's fine.

[Veroule]

Correcting PP to only draw when there is a change in the data or an OS request will obviously eliminate this CPU overhead.  I don't know how many I have to state it before it sinks in, if the image hasn't changed don't redraw it.

Isn't that what Partial Print does already?

Yes and no. 

The way the PP code is now it loops through all tiles in the display area and draws those that have a redraw count count less then the PP redraw count.  It preforms this particular testing loop and orders a redraw of the window at your specified G_FPS.  This does eliminate a very large number of steps in the drawing.

What I am saying is use a more general flag to indicate whether there are any changes since the last draw.  When there are new changes then preform the testing loop and redraw the frame in the same way as the current PP.  When nothing new has occurred then we can skip looping through the display region and skip the redraw order, as the current frame contains the latest data and it is properly displayed.

In order to really see this you have to turn on an on screen display FPS in your drivers.  Once you have that you will notice that redraw orders occur at your G_FPS when nothing has changed.  It is a stupid waste of processing time.

[Baughn]

Veroule:

Believe it or not, I did consider all of your points already.
 It *would* help, an awful lot, but it's effectively impossible. You see..

- DF entirely clears the grid buffer at least once per frame, sometimes more. This means, to know whether it has really changed, you have to actually check every tile against what it was last time. This is what's done with partial-printing now.
- The code doing this exists inside DF proper, in the custom UI toolkit code. I can't touch it, Toady is still a bit paranoid about it - with good reason, I suppose; the benefits to him aren't as large as the risks.
- It would require a rewrite of much of the UI code anyway. Even if the above wasn't an issue, I don't have time for that, nor does Toady; he's busy adding gameplay.

The interface arc is still in the future; maybe, then, it'll be fixed. But not now.

[Baughn]

the single buffer option would most likely be best used without partial print that is for those of you who  can support multiple frame buffers...

Er, no. It exists solely to make partial print work better; there's no point without.

[Veroule]

Grab a copy of the Kobold Quest source.  It includes a little bit wider range of the classes used in DF to handle different displays then the BC code does.

Also I completely understand Toady's disinterest on this point.  If you dig up some very old posts my first complaint about DF was speed.  I tracked it down to my graphics drivers, then ranted about DF doing a graphical redraw with each frame.  When no one would listen I put DF into my debugger and created an assembly patch that set the graphics redraw to once per 10 game frames.  Shortly after publishing that, which included some example C code from KQ, Toady added the G_FPS option.]

I said right from the start that doing graphics display when there is nothing requiring displaying is a waste.  I am glad to hear it makes sense to you Baughn.  I am in mostly the same boat, I don't really have time to completely rebuild the code that Toady has been willing to make public.  I also do not have nearly the level of coding expertise required to do it well, I do have enough expertise in more general design areas to be able to recognize the flaws without even seeing the code.

Perhaps based on the relationship you have established with Toady during the course of working on this portion he would be willing to release a few other portions to you privately.  This was the case with one developer I worked with in a similar voluteer fashion.  My established reputation for supporting his work permitted that code I wrote could be used to replace an existing function of the program.  When I suggested that a related function could be improved in a number of ways he was willing to provide me with the code for that function so that I could ensure anything I wrote had the highest level of compatibility.

What I am suggesting is that you may have taken things as far as possible at this point.  If Toady is willing to privately provide you with some of the pieces that are DF specific then you might be able to take it farther at a liesurely pace while Toady works on the actual gameplay.

My personal view is that the Interface Arc is more meant to better present information to the player.  Basic display stuff should not be considered as part of that.  Basic display is integral to all facets of gameplay and needs to be treated with that level of priority.

[Jurph]

It is irritating and troublesome to copy all of my tilesets, graphics settings, and so forth every time you increment versions.  Can I replace only the EXE file to try an upgraded version?

[Willfor]

I am pretty sure the answer to that is a definitive 'no'. Though I don't pretend to understand the technical details leading to that conclusion, it has been stated as a BAD THING in this thread on numerous occasions.

[Brian]

I just switched back to Ubuntu after a few-month long hiatus.  Semi-fresh OS install, 64 bit os,..

Okay I just fixed my problem but just in case anyone else has it you can find the solution here:

/df_linux$ ldd -v dwarfort.exe
   not a dynamic executable

Means you're as much of an idiot as I am.  Install the ia32 libs, take two advil/beer, and run ldd again.

[devilcrayon]

I use the dvorak keyboard layout.  With 40d7, it now recognizes this, but only for _most_ of the keys.   When I hit shift-e (the physical key) I should get ">", but the game sees it as "E".  It does the same thing in the keybinding screen.  Also does it for "<", seeing "W" instead.  This makes it hard to scroll up and down in z-levels.   Otherwise, it seems to run pretty well in Windows.

-d

[Jemulov]

You can use Shift-num5 to go up and ctrl-num5 to go down. I know it isn't a fix but it's an alternative to using < and >. Plus it works well with the numpad navigation.

That is if you have one of course.

[Phantasma]

It is irritating and troublesome to copy all of my tilesets, graphics settings, and so forth every time you increment versions.  Can I replace only the EXE file to try an upgraded version?

Do tileset really have an influence on FPS? Unfortunatly I am used to tilesets and can't live without anymore, playing with the tileset makes much more sense to me than vanilla DF.

Also, is it possible to load my old d4 fortress in the new d7? I tried but got a few errors...

[penguinofhonor]

So 40d6 worked great for me. It was fast and had no problems.

With 40d7, everything gets messed up. Either all the menus constantly blink between what they should be and every tile being two dots, or it shows two menus at once, or all the menu screens constantly flash between being to the left a few tiles and being to the right a few tiles. Sometimes when I'm not viewing a menu, it will flash between showing the dwarves working and the last menu I was on.

[Rift]

on a 54 dwarf fort, d7 goes about 10-20fps faster then d6 for me... Which is good, it also bounces around like crazy though so thats my "average" it deviates usually about 20fps down every 10 seconds or so.

Something like, for my 54 dwarf fort:
d6 fps/d7 fps/d1 fps
title screen:450/750/300
mountain-terrain: 74/85/105
outside-flatish: 82/98/108
underground dugout: 89/98/108
underground empty: 100/100/110

On the right track.. the fps jump down every once and awhile isn't very fun, but atleast overall it seems to be rising.