Print

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

Faster, no (unknown) problems

Faster, problematic

Same speed, no (unknown) problems

Same speed, problematic

Slower, no other (unknown) problems

Slower, problematic

Doesn't work at all

[peterix]

Seems a little faster to me.
However on a complex fort in all modes if I maximise the window the frame-rate drops of massively.  (big monitors, about 12 * the number of tiles)

On a complex fort with all the trimmings, When paused its framerate is maxed out at the default window size, when I maximise the screen it drops to a rather poor 10FPS. 

I'm assuming pausing shuts off most of the simulation.  It doesn't seem like there should be anything like enough drawing to cause so significant a slowdown,  I've not been source diving but it seems calculating what to display is looking overly expensive.  Needs profiling really, but for my money there may be much more to be gained from things like spacial partitioning of the object data than reworking the drawing.

(if that is correct running the display in a different thread to the sim would have a potentially serious impact too. - sorry)

There are a few undrawing related things happening that I'd not noticed in 40d.  Some jobs don't seem to get done anymore, e.g. carpenters and smiths won't build animal traps.

Regarding the spatial portioning:
The map is basically a big 3D array of 16x16 blocks of tiles. I can only guess how the other objects are put into the tiles at the rendering stage (I haven't really looked that hard), but considering the fact that creatures, buildings, plantlife and constructions are all packed into vectors, it probably has to walk all those vectors for every game tick. A big question: is the frame put together as part of the game-loop tick, or does it walk the vectors twice? How about using some different container? (no matter how inconvenient that would be for me and my hacking efforts to reverse-engineer).

This of course uncovers the reason why having too many items in the item vector slows down the game so much. A dwarf trying to find a path to the closest stone has to find that stone. Does it walk the vector in that case? Probably has to.

Designations work like this: Each of those map blocks points to a different object (haven't named those yet). This object has some flags, including what I call a 'dirty bit'. Only blocks with a set 'dirty bit' are used for designated jobs (digging, felling trees, plant gathering, etc.). Seems pretty good, right? Now a question: is the bit cleared when it's impossible to path to those designated blocks? What happens when I designate 20k tiles in 78 blocks and only 78 tiles are ready to be mined (an extreme case, I know)? 20k jobs to check? I bet this is the case.

A door hooked up to a lever is the bane of FPS. I bet DF has to recalculate the pathing data (part of the map blocks AFAIK) in that case. Give an order to pull the lever continuously (doors are instantly opened/closed) and watch the FPS counter plummet towards 0.

I could continue. When people say 'fix pathfinding', they actually mean THESE problems. The pathfinding algorithm is probably very good all things considered. It just has to do much more work than it should.

This brings us back to the graphics. The biggest part there is putting the 'things' into a square grid and then later blasting that to the screen using whatever method implemented in libgraphics. Which part is the slower one? I don't really see that big differences in rendering speeds in this thread. But what I do see is that 40d was compiled with an older version of the MS compiler. So, these numbers are all bogus. Any Improvements could be just as well from using a better compiler. If you want to measure something, have a control - plain DF 40d compiled with MSVC 2008.

Now, how much time is spent by the CPU waiting for the memory instead of actually processing things? Are STL objects passed by reference? Allocating and freeing many small objects is expensive!

Etc.

[Baughn]

There are six arrays representing different elements of the screen - which tile is showing, its foreground and background color, etc. For d19, if you're showing 80x50 they'll be 80x50 arrays; in earlier versions they were always 256x256.

These arrays have to be converted to something that can actually be shown, once per frame. They're also /completely rewritten/ at least once per frame, and in code I don't control.

Thus, the way I do it is to maintain a shadow copy of the last frame's arrows, and compare it to them to figure out what has changed. This could be optimized a bit - it compares the graphics-mode arrays even when graphics are off - but overall that's a very small amount of the cost.

After it's done that, it'll have a (usually) small list of altered tiles. These are converted appropriately and, depending on print-mode, either just those tiles are put on-screen or they're used to edit print-mode specific arrays which are then passed to opengl.

Notably, other than creating this list - which won't have more than a few dozen elements per frame, typically - there's no memory allocation involved.

==

On an unrelated note, I finally decided I'd had enough of not being able to compile DF, and therefore not being able to do the major (or even minor) refactorings required to make this truly reliable. So I'm writing a tetries clone to replace DF.

There are many tetris clones, but this one is mine.

Hopefully, I'll be able to eliminate all the redundant state changes and inefficient/hard to understand (never mind bugfix) code with this. We'll see.

[koitsu]

After applying the head, I now get an error:./dwarfort.exe: error while loading shared libraries: libjpeg.so.8: cannot open shared object file: No such file or directory

I have libjpeg62 installed, which is the only package in the repos that seems to include libjpeg.  Furthremore, I have libjpeg.so and libjpeg.so.62, but not libjpeg.so.8.  I don't know much about how the libraries work, so I can't diagnose further.

I got that same problem too, at first, and I... symlinked libjpeg.so.8 to libjpeg.so.62. After that, it worked fine! Just... remember to remove that before upgrading your libjpeg package in the future.

(there's no package in Debian that has libjpeg.so.8, and I suspect it might be the same way in Ubuntu at the moment.)

Don't do this, *EVER*.  There is absolutely zero guarantee that the symbol semantics (or if the symbol exists, the underlying function code) are identical.  The risk you're taking is very high.  Again: please don't do this.

Debian most definitely has jpeg8 support, but the package is part of the "unstable" tree.  Debian has a very strange concept of what's stable and what isn't, so there's probably very little risk in installing this and Doing Things Right(tm).

http://packages.debian.org/sid/libjpeg8

I don't see a package for Ubuntu, so Ubuntu users should contact their distributor for assistance.  If you don't, you'll never get the package.

[CobaltKobold]

I'd'e sworn I posted in here with my errormessage of running out of color pairs (in textmode) and asking Baughn to implement a workaround (the error message said to).

It seems to ha'e been eaten by a grue.

The text mode is very cool; I'm guessing DF is a bit too heavyweight for someone to set up a free ssh server like Crawl and NetHack have, but on a multi-core system you could probably have one copy of DF running on each core without noticing much slowdown. (Hey, a performance advantage to DF's single-threaded nature!)

Someone did, but only 1 game running for people to watch/play.

[peterix]

After applying the head, I now get an error:./dwarfort.exe: error while loading shared libraries: libjpeg.so.8: cannot open shared object file: No such file or directory

I have libjpeg62 installed, which is the only package in the repos that seems to include libjpeg.  Furthremore, I have libjpeg.so and libjpeg.so.62, but not libjpeg.so.8.  I don't know much about how the libraries work, so I can't diagnose further.

I got that same problem too, at first, and I... symlinked libjpeg.so.8 to libjpeg.so.62. After that, it worked fine! Just... remember to remove that before upgrading your libjpeg package in the future.

(there's no package in Debian that has libjpeg.so.8, and I suspect it might be the same way in Ubuntu at the moment.)

Don't do this, *EVER*.  There is absolutely zero guarantee that the symbol semantics (or if the symbol exists, the underlying function code) are identical.  The risk you're taking is very high.  Again: please don't do this.

Debian most definitely has jpeg8 support, but the package is part of the "unstable" tree.  Debian has a very strange concept of what's stable and what isn't, so there's probably very little risk in installing this and Doing Things Right(tm).

http://packages.debian.org/sid/libjpeg8

I don't see a package for Ubuntu, so Ubuntu users should contact their distributor for assistance.  If you don't, you'll never get the package.

And that's why you put it in DF's libs folder instead, because it's set up to look for libs in there first.

[quinnr]

I wonder if DF could be put into Dgamelauncher.

That would be awesome.

[Phwoar]

I believe the 2d version could be sped up by creating an algorithm that combines tiles close to each other into one blit.

Unfortunately, struggling to recall what this process is called, or I'd provide some reference links..  Does anyone else know off-hand?  Anyone have the smarts/time to look at implementing/testing this?

Off the top of my head, perhaps you're thinking of dirty rectangles?

Ah, yep, thanks..  should be enough to get on the right track.

I believe DF already sort of uses a dirty rectangle system, in being tile-based and only drawing the changed bits, but I guess what I was suggesting was more a method of combining/consolidating dirty rectangles to limit blits.

Not positive it would work, but something that would essentially allow, say, your meeting/dining hall to be blitted in one big square, rather than 60 little ones, would logically be an improvement.

[Veroule]

Now, how much time is spent by the CPU waiting for the memory instead of actually processing things? Are STL objects passed by reference? Allocating and freeing many small objects is expensive!

Etc.

Your first question is why I am always pissy about how much memory is being used in less then efficient fashions.  Sure, everyone has 1GB of ram now...let's prove Wirth right and not care about how much we use.  [sarcasm]1GB is huge we will never use all of it.[/sarcasm]

Most of the STL classes are small structures with nearly everything behind a pointer to allocated memory.  Also the C++ func(type &var) is really the same as the C pointer parameter notation.  The compiler just handles all the conversions for you.

Allocations and frees are a little bit trickier.  Toady likes global variables some, and Baughn is a nut for them.  STL classes only do a free in thier destructor.  Global variables only get thier destructors called at program end if at all. This means that many of the vectors, strings, maps, maps of string+int, etc. are allocated and then never freed.  If you want to see this in action launch DF, load up a paused save, and check the memory usage; then turn the intro on and do the exact same steps with the exact same save.  You should see about 20MB being wasted.

[Veroule]

On an unrelated note, I finally decided I'd had enough of not being able to compile DF, and therefore not being able to do the major (or even minor) refactorings required to make this truly reliable. So I'm writing a tetries clone to replace DF.

There are many tetris clones, but this one is mine.

Hopefully, I'll be able to eliminate all the redundant state changes and inefficient/hard to understand (never mind bugfix) code with this. We'll see.

I always used to port the code between BC and DF builds.  I will see if I can put it together with your current code.

[Narmio]

So, after reading that we need a standard benchmarking fortress, I went and created Testfortress the Fortress of Testing, "Okilgeshud Geshud Okil".  It's 16x16, has a whole bunch of stuff, and has f1 set to an area with a brook, the wagon and some peasants and kittens wombling around.

http://dffd.wimbli.com/file.php?id=1905 , or can also be easily found by punching "Testfortress" into the DFFD search.

To use, set your DF window to 150x75, load the save and hit F1 to zoom to the wagon, cats and frolickers.  Wait a minute or so and then take the FPS reading.  Then, to ensure subsequent readings are compatible, kill DF without saving, so that future tests see the exact same minute of save-scummed peasant frolickery.


I hope it's helpful.  I'll post my benchmarks using Testfortress here in a bit.

[Untelligent]

150x75 is bigger than my screen. =/

[Quietust]

I wonder if DF could be put into Dgamelauncher.

That would be awesome.

If it could, you'd need a supercomputer hosting it (or at least a beefy server with several dozen CPU cores) and lots and lots of bandwidth to handle all of the frequent screen updates - what works for Nethack almost certainly would not work very well for Dwarf Fortress...

[quinnr]

I know...(ohmygawd the lag!)

[Baughn]

I'd'e sworn I posted in here with my errormessage of running out of color pairs (in textmode) and asking Baughn to implement a workaround (the error message said to).

I fixed what caused the message to appear instead. So unless it still happens, there's no actual need for the workaround - yet.

--

Linking libjpeg.6.2 to libjpeg.8 works for DF for the specific reason that DF doesn't actually /use/ libjpeg. It's pulled in through, probably, sdl-image; though using your own local sdl-image is better than doing bizarre workarounds with ln -s.

--

..no, I don't like global variables. Really. Honest. 

I just haven't had much choice in inserting them, since actually altering the classes would tend to cause DF to segfault. I've tried to always use accessors for them anyway; these global variables are global in name only.

[Rafal99]

Since we already are discussing technical side of 40dX versions, I would like to have a question to Baughn or anyone with enough knowledge.

How do you actually draw colored tiles?
I mean in the simplest but reasonably effective implementation.
Ok you load a tileset file, you get 256 tiles. Every tile can be drawn with 16 different foreground colors and 8 background colors.
So you get 256x16x8 possible tiles total. You can't cache them all.
Are you caching the ones actually used?
Or is there some simple yet effective way to get a tile and paint its foreground and background with different colors on the fly?