Print

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

[Peristarkawan]

quote:Originally posted by Jaqie Fox:
<STRONG>

You say I am wrong and then say soething supportive of what I said. You are making absolutely zero sense.  I suggest you watch the link in my signature.</STRONG>

While it looks like part of Devastator's post got lost somehow, I think you misunderstood what he did say. That Dwarf Fortress has to do a lot of calculations each frame has nothing to do with how efficiently those calculations are programmed. It would only be inefficient if those calculations were poorly programmed or if it were doing more calculations than necessary, neither of which we're in a position to know anything about.

[Jaqie Fox]

On the contrary, anyone that knows enough about computers and programming can look at what a program does and have a pretty good idea of the power needed to do those things with efficient code.

[Peristarkawan]

quote:Originally posted by Jaqie Fox:
<STRONG>On the contrary, anyone that knows enough about computers and programming can look at what a program does and have a pretty good idea of the power needed to do those things with efficient code.</STRONG>

Well, I don't presume to know everything that Dwarf Fortress is doing. In fact, I get the impression that there may be quite a bit going on beneath the hood that I know nothing about.

It occurred to me that while the DF source is closed, there's nothing stopping us from peeking at the Kobold Quest source and extrapolating from there. I gave it a quick look-through and didn't notice any obviously bad code (although the formatting is hideous).

The only thing I did notice was that the path-finding uses breadth-first search rather than a heuristic algorithm (although bear in mind that DF doesn't necessarily use the same approach). I'm not sure without trying it myself how much of a performance gain could be achieved in this case by changing it, though.

Toady does cleverly avoid having to reallocate or clear the large path-finding data structure each time the function is called, so I have to give him points for that.

[Toady One]

DF has been using a heuristic for the past few months.  There are enough path-finding failures that it's actually slower (because of the additional overhead), but once I put in enough checks to make sure it never attempts to form a path that won't succeed, it will be a bit faster.  Path-finding isn't really the main bottleneck though.  Storage handling in large forts is the main issue in the currently released version, though that has been resolved to some extent now.  After that, temperature and weather have the greatest effect.

[Veroule]

I have been delving through the Kobold Quest code and really can't find any easy way to make the graphics run faster and cleaner.  Essentially the objects involved don't really have a clear order of precedence.  So there is no clean seperation of the graphics from the objects that require drawing.

I was thinking about writing a library of graphics functions specifically tailored to what DF does and wants to do, and an example application.  However it pretty much means that I have to learn all the GL stuff first, and it would involve a huge rewrite for Toady to make use of it.  That is if I ever managed to finish it.

I just wonder if it is worth doing?

[Toady One]

Nope.  Although I'm not sure what you're shooting for.  The "slow" part of kobold quest for people with GL problems is the rendering of the curses 80x25 rectangle, where it spits out 80x25 quads twice.  Aside from checking the buffer and not printing a quad if it doesn't have to, I'm not sure what you had in mind to speed it up.  It doesn't call the GL functions twice if it prints a kobold over a square for example.  It only renders when the scene is set.