Print

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

[NJW2000]

^This, so much. While DF is growing, computer power is growing exponentially. Unlike other games, it might still be there and relevant, and is likely to be, ten years from now, in which case this will likely become meaningless.

DF is one of very few games that can afford to let technology improve faster than its performance, but I think this might be the most viable strategy.

[Dirst]

Technically, Dwarf Fortress is doomed.  It won't survive the heat death of the Universe.  But this isn't particularly relevant to performance issues.

There are a very small number of people that Toady seems to trust on coding advice on bugs (Quietust and Ag that I know of), and of course the SDL implementation involved outside help, so it's not like Toady is religiously dead-set against accepting help.  But my understanding is that the SDL experience did not go well, so whoever does get tapped to assist is going to have to play by Toady's rules.

Multi-threading may or may not help.  Personally I think that offloading periodic updates to a GPU would be more fruitful.

[galneon]

Going multi-thread would not only be a colossal time investment on Toady's part, it's not actually a guaranteed performance boost. Multi-threading done right can be very powerful, but done wrong it can actually slow your program to a crawl if you even manage to keep it stable, and it's specifically dreaded in game programming. Multi-threading is typically only useful if your program has a lot of cache misses slowing it down, which DF probably has, but switching over is such a monumentally complicated, time-consuming and error-prone task that you could have played dozens of games over the years it could take Toady to manage making DF multithreaded without breaking the program.

I didn't suggest Toady take care of it himself because I know that he simply cannot.

If you're upset with poor performance, just let computer science advance and hold off playing the game until technology can support a faster DF without requiring unreasonably drastic changes to the program. Heck, within the next decade we could be seeing true commercial quantum computing, memristors or some other crazy invention.

This is not how hardware scales over time, and I won't speculate on radically different architecture with an uncertain future.  In 10 years will DF run better?  Yes, of course.  Will FPS death still be an issue if development continues at its current rate and direction?  Undoubtedly.

I don't care if improvements come from the most brilliant implementation of multithreading in gaming history or some other means.  I just know something dramatic must be done, and that doesn't involve waiting for hardware to improve in a magical way that makes an inefficient engine behave otherwise.  I hope the options, however daunting, are being considered.

[AzyWng]

Technically, Dwarf Fortress is doomed.  It won't survive the heat death of the Universe.  But this isn't particularly relevant to performance issues.

Sigged.

[AbstractTraitorHero]

What you talking about dwarf fortress will be saved by time travelers who then escape the universe with it!

[therahedwig]

The problem here is that you want reassurance that something will be done, specifically with a nice timeline so that you feel your anxiety lessen.

You're not gonna get that.

What you are gonna get is "this is toady's baby, he'll inevitably work on fps issues as it starts bothering them". Does this mean that maybe he'll spend a whole year rewriting fps blockers? Probably. Will this kill player enthusiasm for Dwarf Fortress? Well, considering he's done 3 big updates that took a full year already, I somehow doubt this.

DF has been in development for a long time. The community is used to living the slow life and is not gonna topple over when toady isn't releasing new updates every week. (Maybe, this final update before speedup cleaning will finally allow Masterwork to catch up )

[Salmeuk]

This is not how hardware scales over time, and I won't speculate on radically different architecture with an uncertain future.

Dwarf Fortress is both radical and different, and you can practice architecture within it, yet you seem to be quite willing to speculate on it's uncertain future.

This kind of 'call to arms' post doesn't get much support around here (IMPENDING DOOM and DISMAY just don't sell around these parts, perhaps due to the amount of time we spend playing DF) though it does provoke interesting discussion about the nature of game development so I welcome you to continue your sign-waving.

The game slows down, sure, but much like the ASCII people have come to terms with this. I don't think anyone wishes for the game to become slower. However, the opportunity to further enjoy a procedurally-generated fantasy simulator of this magnitude is far more important than the speed of that enjoyment.

And this has already been noted, but to reiterate: Toady makes this game because he wants to. The community that followed was almost an accident, but it's turned out to be a rather productive relationship for all concerned. As near as I can tell, if the community dries up the development will go on. Dwarf Fortress won't just die like some kickstarter or early access, so your fears are unfounded.

[Isngrim]

Going multi-thread would not only be a colossal time investment on Toady's part, it's not actually a guaranteed performance boost. Multi-threading done right can be very powerful, but done wrong it can actually slow your program to a crawl if you even manage to keep it stable, and it's specifically dreaded in game programming. Multi-threading is typically only useful if your program has a lot of cache misses slowing it down, which DF probably has, but switching over is such a monumentally complicated, time-consuming and error-prone task that you could have played dozens of games over the years it could take Toady to manage making DF multithreaded without breaking the program.

I didn't suggest Toady take care of it himself because I know that he simply cannot.

I wouldn't go that far,just 30 seconds of research would show you Toady is likely more then capable of it:

Adams earned a degree in mathematics at the University of Washington.[2] He applied for his doctorate at Stanford University, completing it in 2005 with a dissertation titled "Flat Chains in Banach Spaces", which was published in The Journal of Geometric Analysis. During his first year at Stanford, he was under pressure, the professional environment and competitiveness affected him negatively. He cited the conflict between studying mathematics and developing video games as the reason. This stressful situation left him depressed and he admitted to having a brief encounter with drugs.[8]

In 2006, he started his post doctorate in Texas A&M, which was his goal since his undergraduate days. He decided to leave during the first year due to the increasingly stressful situation[3] and is said to have broken down in the head of department's office. He left in the same year after receiving a stipend, to devote his full attention to developing Dwarf Fortress and other games, which was until then only a hobby. He said, "At the end of a math problem, you have a paper and maybe you publish it, and the paper can be a building block for the edifice of mathematics, but to me that’s not so important. But working on a problem and having a game when you’re done? That’s pretty damn cool."[2]

other then that,everybody else beat me to the point.

[Kirkegaard]

Going multi-thread would not only be a colossal time investment on Toady's part, it's not actually a guaranteed performance boost. Multi-threading done right can be very powerful, but done wrong it can actually slow your program to a crawl if you even manage to keep it stable, and it's specifically dreaded in game programming. Multi-threading is typically only useful if your program has a lot of cache misses slowing it down, which DF probably has, but switching over is such a monumentally complicated, time-consuming and error-prone task that you could have played dozens of games over the years it could take Toady to manage making DF multithreaded without breaking the program.

I didn't suggest Toady take care of it himself because I know that he simply cannot.

I wouldn't go that far,just 30 seconds of research would show you Toady is likely more then capable of it:

Adams earned a degree in mathematics at the University of Washington.[2] He applied for his doctorate at Stanford University, completing it in 2005 with a dissertation titled "Flat Chains in Banach Spaces", which was published in The Journal of Geometric Analysis. During his first year at Stanford, he was under pressure, the professional environment and competitiveness affected him negatively. He cited the conflict between studying mathematics and developing video games as the reason. This stressful situation left him depressed and he admitted to having a brief encounter with drugs.[8]

In 2006, he started his post doctorate in Texas A&M, which was his goal since his undergraduate days. He decided to leave during the first year due to the increasingly stressful situation[3] and is said to have broken down in the head of department's office. He left in the same year after receiving a stipend, to devote his full attention to developing Dwarf Fortress and other games, which was until then only a hobby. He said, "At the end of a math problem, you have a paper and maybe you publish it, and the paper can be a building block for the edifice of mathematics, but to me that’s not so important. But working on a problem and having a game when you’re done? That’s pretty damn cool."[2]

other then that,everybody else beat me to the point.

It is a specialists job. Not every programmer can do everything equally well, especially not if one to a degree is self taught.

[cochramd]

(Maybe, this final update before speedup cleaning will finally allow Masterwork to catch up )

Given how much fun new stuff has come out in v42, I am doubtful that there will be much interest in Masterwork by the time Toady decides he needs to optimize. However, I've never used Masterwork so I might very well, much like OP, be talking about something I know nothing about.

[Livingdeath]

To quote scripture, premature optimization is the root of all evil.

Toady could very easily optimize a lot of things right now on that front, that could give in principle enormous speed up benefits..   Like a factor of 10 or more.  Pathing for instance is a major compute hog, and could be ameliorated considerably.

The problem is, these sorts of optimizations are so specific that it's unlikely they will continue giving the same benefits if something changes drastically (Pathing for instance will radically change if you implement a rail system) and in fact could make things worse.

You really want the optimizations right before the final release.

So while hardware is unlikely to really keep up, software here really does have a large amount of wiggle room.

[galneon]

The problem here is that you want reassurance that something will be done, specifically with a nice timeline so that you feel your anxiety lessen.

You're not gonna get that.

No, I don't.  I never said any of that or anything resembling it.  I never requested "a nice timeline," and I don't want "reassurance" because I don't frankly care enough about playing the game.  I don't play a ton of DF, but I follow it because I love what it represents and I would hate to see someone's life's work plagued with technical issues that are never resolved and possibly even worsen as complexity increases while some of the most vocal fans suggest FPS death doesn't really matter.  I made this thread (I'm hardly the first) because the issue should be brought up frequently.  Keep your straw-men in the closet next time.

What you are gonna get is "this is toady's baby, he'll inevitably work on fps issues as it starts bothering them". Does this mean that maybe he'll spend a whole year rewriting fps blockers? Probably. Will this kill player enthusiasm for Dwarf Fortress? Well, considering he's done 3 big updates that took a full year already, I somehow doubt this.

DF has been in development for a long time. The community is used to living the slow life and is not gonna topple over when toady isn't releasing new updates every week. (Maybe, this final update before speedup cleaning will finally allow Masterwork to catch up )

Now that we've established I don't care about "when" and am not seeking to quell my anxiety, only that eventually something is done for the good of the game, I think it's clear we agree on most of this--though I think if major improvements to performance are made, I don't think it will be solely Toady who is responsible.

As for player enthusiasm, I don't think it's likely to die regardless of the direction of development as there will always be die-hards who, as I mentioned before, consider FPS death a neat feature and not a problem.  The sycophant doesn't always provide the best feedback, though, and it would be a shame if eventually they became the majority.  They just might become the majority in this thread, though, and I'm not counting you among them.

It is a specialists job. Not every programmer can do everything equally well, especially not if one to a degree is self taught.

Thank you.  Toady himself has said that multithreading is not his forte.  I'm not suggesting he's stupid, or a bad programmer.  (But of course we know that multithreading is not the only thing that could help.)

Given how much fun new stuff has come out in v42, I am doubtful that there will be much interest in Masterwork by the time Toady decides he needs to optimize. However, I've never used Masterwork so I might very well, much like OP, be talking about something I know nothing about.

I'm disappointed...  You didn't even try to misrepresent my words--just an artless attack on my credibility without anything (real or imagined) to actually discredit me.  Boring.  I'm surprised you manage to even get through world generation.

To quote scripture, premature optimization is the root of all evil.

Toady could very easily optimize a lot of things right now on that front, that could give in principle enormous speed up benefits..   Like a factor of 10 or more.  Pathing for instance is a major compute hog, and could be ameliorated considerably.

The problem is, these sorts of optimizations are so specific that it's unlikely they will continue giving the same benefits if something changes drastically (Pathing for instance will radically change if you implement a rail system) and in fact could make things worse.

Pathfinding is actually the sort of thing that wouldn't break as easily as the codebase expands, and overhauled pathfinding would indeed be a big improvement.  You're right though that little performance hacks do tend to break over time.  Those would not be the sort of improvements needed.

You really want the optimizations right before the final release.

Final release?  Are you sure we're talking about the same game?

[Orange Wizard]

Multithreading would require absolutely gutting the engine and reassembling everything in a vastly (vastly) more complicated manner than it's currently arranged (which is already really complicated).
I don't doubt that Toady could do it, but it's the sort of thing that would need an army of Toady-clones to get done in a reasonable timeframe, and even then you'd still have endless bugs to deal with.
Simply put: Multithreading the mechanics of a game like DF is really sodding hard. The performance boost is probably not worth it.

some of the most vocal fans suggest FPS death doesn't really matter

For the record, nobody actually thinks this (and if they do they're wrong) but it isn't a priority while the game is in active development.
Toady can optimise the game further (and he does, as major problems arise), but that's not his priority. DF is currently in alpha, which means adding features (and fixing major bugs, but mostly adding features). If the game makes it to beta, then he'll get on to bug-squashing and optimisations.

[therahedwig]

Bzwah? So you just want to sit around here and poke us so that we will forever be discussing the same oldass boring topic? You do realise we play this game for fun right?

Well, if you're into that, how about you start a thread about the UI as well then?

I just assumed you were one of those people who didn't know how to use the search function. Guess I was wrong.

[Miuramir]

My 2☼:

In the long run, some sort of technological change in the code will be necessary.  That said, with most estimates of something that would be called 1.0 off in the 20 year timeframe, predicting tech that far out is not a good use of effort.  There's reasonable odds that simply compiling it with Visual Studio 2030 will take advantage of whatever massively-parallel, quantum, or whatever hardware exists at the time.  (Among other things, compilers are starting to become more parallel aware; I suspect that the era of hand-optimizing for multiple CPUs is a temporary one.)  Spending a huge chunk of time optimizing DF for pre-2020 computing tech isn't a good investment.

That said, building in *flexibility* is a useful investment. It's difficult to predict things like screen sizes, for instance, but the odds that at some point someone will want to play DF maximized on a next-gen 8k display are reasonable; making configuration options handle larger than current numbers is wise.  You can buy dual 20-core desktops with a terabyte of RAM *today*, not to mention GPGPU computing where you're dealing with thousands of cores.  We *really* don't know what the future will look like. 

(Side note: the rapid growth of power optimization may mean that the future gets heavily into things like reversible computing... talk about needing a whole new paradigm of compilers, it makes rewriting for massively parallel look like a walk in the park.)