Print

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

[Dorf and Dumb]

It'll be interesting to see the game more elaborate - the problem is, computers don't really seem to get much faster any more.  So I think a top priority has to be speeding up play so fortresses can be run all the way through.  This includes:

* 1x1 embarks.  I don't know why but it seems to want 2x2, which is 4x the area to simulate.

* Finally FINALLY get rid of the 150 dwarf thing for nobility.

* Easier culling of items and mobiles.

* This is a thing to itself, but: improve gameplay for using dwarves as reservists so you can get by with fewer.  (For example, mobilizing woodcutters as axemen shouldn't send them on a mandatory futile trip to switch axes, or even send them into some bugged mode where they can't use an axe)

* Better default configurations to cut down all the categories of sheer crap that accumulate - I mean, do you really care if it's giant rat leather or large rat leather?  (Yeah, this is in some mods already)  Maybe a better understanding of where the program spends its cycles can suggest better ways to save here.

* I don't know what it takes to make it so that adventurer mode lets you move fast.

You have to be able to _play_ the game to play the game.

[Putnam]

Computers are getting faster. I have doubts your computer is getting faster, but computers are getting faster. Don't worry about that.

3. More "better" than "easier".

6. That's basically a kind of meta "improve FPS" step to improving FPS.

[Maltavius]

Computers are getting faster. I have doubts your computer is getting faster, but computers are getting faster. Don't worry about that.

3. More "better" than "easier".

6. That's basically a kind of meta "improve FPS" step to improving FPS.

Computers aren't getting faster... they are getting more core:s at lower speeds.
A few years ago I had a 2-Core 3.7GHz system Now I have 4 cores at 3.3 GHz instead.

DF is famous for it's inability to use extra cores effectively so the FPS improvements are really needed.

5. Is much needed. Leather should be of three types Small, medium and large leathers and meat as well (beef, pork, veal, monster)

[Nostrolo]

If you want generic meat and leather, use one of the mods. Part of the fun of dwarf fortress is that it's so intricate. I care whether its giant rat leather or large rat leather for the same reason i care whether its mako shark or pond grabber leather. The devil is in the details

[GavJ]

I do VERY much care if it is elf leather vs. horse leather.  But sure, it would be great to make this (as well as as much as possible of everything else) part of the RAWs. Like a tage that says [SPECIALLY_LABELED_BYPRODUCTS] or whatever, which you can remove and it just yields generic stuff, or keep and it will keep track of it.

1x1 embarks are indeed silly not to have. Note that you can already play 1x1 yourself though with dfhack scripts, if you need the FPS boost personally.  Yes, it should also be in the game, but you don't have to wait. I play 1x1 all the time.

This is a thing to itself, but: improve gameplay for using dwarves as reservists so you can get by with fewer.

I'm not exactly sure what you mean by this. I can't think of any other example besides the one you listed. Woodcutting is the ONLY job I know of that uses a dual purpose tool, and should therefore be the only one to be relevant to this, yes? Everything else they should already be able to switch jobs on the fly without futile extra trips.

[Bumber]

Woodcutting is the ONLY job I know of that uses a dual purpose tool, and should therefore be the only one to be relevant to this, yes?

Hunting and mining. (A pickaxe is a wonderful weapon.)

[Putnam]

Computers are getting faster. I have doubts your computer is getting faster, but computers are getting faster. Don't worry about that.

3. More "better" than "easier".

6. That's basically a kind of meta "improve FPS" step to improving FPS.

Computers aren't getting faster... they are getting more core:s at lower speeds.
A few years ago I had a 2-Core 3.7GHz system Now I have 4 cores at 3.3 GHz instead.

You're simply wrong there. More clock speed=/=faster. The Intel Core i5 I have is at least 3 times as powerful as a Pentium 4 with twice the clock speed on a per-core basis

[10ebbor10]

While there are indeed quite a few hardware based improvements, DF's old  codebase isn't really optimally suited to take advantage of these.

[MeMyselfAndI]

I would be intrigued to see what a 64-bit build would do towards FPS improvements.

x86_64 has a number of performance improvements over x86 (partly due to making previously optional features standard, partially because of a few added features).

Also, the pathfinding is... Suboptimal. At least in performance terms. There are a number of improvements over straight A* that could be used, mainly involving caching (some suboptimal, some retain optimality). Even JPS would help.

On a semirelated note, it would be amusing for someone to implement HashLife as the backing tick for a tile-based game. Or rather the backing algorithm behind HashLife.

[Putnam]

I'm not really sure JPS would help.

Anyway, a 64-bit build is a definite when, not if. It's going to show up, perhaps even soon, since 32-bit is pretty much completely obsolete at this point and DF can extremely easily be made to use too much memory.

[MeMyselfAndI]

I'm not really sure JPS would help.

Why not? At worst it's about the same as A*, and in the best case can be nearly an order of magnitude faster.

And I know that pathfinding is a bottleneck at least in some cases: my current fort went from 20 to 60 fps when I walled off the caverns and enabled burrows.

[Reelya]

HashLife uses an awful amount of memory, that's how it gets away without having to compute things - the answers are pre-computed in hashed lookup tables. This is significant for anything remotely complex.

Plus, the hashes would need to change if the model changes. That is, the entire search space would need to be re-hashed to X future steps anytime the search space changed - e.g. walls were built or floors were placed, thus changing the entire search space.

Also, it's not suited to non-local stuff like doing path searching on complex spaces. The initial hash would have to store every possible route, from any potential point to any other potential point before any single path could be computed. This would be much more overhead and memory needed than just creating paths as needed. You can't just pre-hash that like you can with a simple system like Conway's Life, where all interactions are local and there are simple cell-based rules.

---

Anyway, we can't really claim that the search algorithm lacks this or that, since nobody has seen the code. JPS is just an adaptation of A*. And DF probably already utilizes this. When I open a doorway between two large areas there is a significant game pause. Most likely there is meta-data about pathing being computed when this happens.

Even with stored-paths, the fact that forts are dynamic means there will always be pathing overhead. You just can't store every possible path for 10000's of squares, and even then you need to check that the quick-and-dirty checkpoint path you've decided on is the actual shortest path, so you need to calculate other potential paths at least to the point that they are clearly worse.

[MeMyselfAndI]

HashLife uses an awful amount of memory, that's how it gets away without having to compute things - the answers are pre-computed in hashed lookup tables. This is significant for anything remotely complex.

Plus, the hashes would need to change if the model changes. That is, the entire search space would need to be re-hashed to X future steps anytime the search space changed - e.g. walls were built or floors were placed, thus changing the entire search space.

Also, it's not suited to non-local stuff like doing path searching on complex spaces. The initial hash would have to store every possible route, from any potential point to any other potential point before any single path could be computed. This would be much more overhead and memory needed than just creating paths as needed. You can't just pre-hash that like you can with a simple system like Conway's Life, where all interactions are local and there are simple cell-based rules.

Oh, sorry if it wasn't clear. I *wasn't* talking about it as applied to DF or pathing, I was talking about it in general for a tile-based game. For things like water flow and temperature. Unfortunately, it's less suited to 3d environments than 2d ones.

Anyway, we can't really claim that the search algorithm lacks this or that, since nobody has seen the code. JPS is just an adaptation of A*. And DF probably already utilizes this. When I open a doorway between two large areas there is a significant game pause. Most likely there is meta-data about pathing being computed when this happens.

Even with stored-paths, the fact that forts are dynamic means there will always be pathing overhead. You just can't store every possible path for 10000's of squares, and even then you need to check that the quick-and-dirty checkpoint path you've decided on is the actual shortest path, so you need to calculate other potential paths at least to the point that they are clearly worse.

I was under the impression that DF used straight A* with connected components. (A quote: " The dwarves themselves mostly move around with A*, with the regular old street-distance heuristic. The tricky part is that it can't really call A* if they don't know they can get there in advance, or it'll end up flooding the map and killing the processor. ") And recomputed paths only when dwarves encountered something unexpected (a wall in their route, etc).

What happens when you open a door between two large areas is that it has to recompute (read: floodfill) the connected components. However, I believe you have an incorrect assumption about how JPS works. It requires no more caching than straight A*, and as such I am confused as to why you believe said pause is even relevant.

You are absolutely correct as to the problems with pathfinding in a dynamic environment. For something more involved, MPAA* (possibly with the same JPS optimization as can be applied to A*), would be much better.

[Reelya]

That interview was published in February 2008, and version 1 of the 3D DF came out at the end of October the year before. So, when that quote was relevant it was only a couple of months at most since the first 3D version was released. So that quote isn't really relevant now. Virtually every aspect of the code is now different since 2008.

I'm sure Toady's changed up just about anything he can for more FPS already. He was complaining that it's slow in ~Feb 2008, but that was literally a handful of weeks after he got the first 3D version up and running. virtually all memory structures in the game are rewritten by now, and he's optimized the hell out of it time and time again.

So, i'm just saying some *trivial* optimization that can be found on any undergraduate programming tutorial website is unlikely to be some major revelation to Toady at this point.