Print

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

[ZJVavrek]

I wasted tons of money on a computer with the following:

Wasted?  How sad.  Here, I'll make it better for you.  I'll take that computer off your hands.  Give you $100 for it.  $150, even, because I think you have an honest face.

[tolkafox]

Oh, I assumed by 'wasted' he meant 'failed to research what was best for DF and is ignoring everything else the computer is capable of doing.'

I found a good balance between DF and Fallout 3. I'm also currently playing on a $200 laptop that runs DF at 50 FPS if I have 100 dwarves, more if I have less dwarves. Can't play waterfalls that run into two rivers though

Years of study and coding on Toady's part, or $200 on our part. Hrm....Sorry to be rash about it, but that's the truth. You have good games like Crysis where you have to shell out an arm and a leg to play on minimal settings, and you have good games like DF where you just need to know your processors and RAM to play on the maximum settings and can play an average game for $200. Unless the maximum settings have been boosted up to 18x18 embarks and an average game is no longer 3x3 with a river O.o

[Tharwen]

I have no graphical lag

I challenge you to find me any computer which gets graphical lag on Dwarf Fortress.

It literally has to render nothing but 300-ish (I'm completely guessing here, but it's a fairly small number) little bitmaps.

[612DwarfAvenue]

Define graphical lag.

[hjd_uk]

I am a games developer and am currently implementing a  multi-thread / multi-core particle system.... it ain't as easy as pressing a "make faster" button.
But as its on PC/Mac and threads can access main memory (*shakes fist at PS3*), it should be possible to move things like temperature calculations and path-finding tasks to separate threads. But ho-boy don't expect the DF-Multicore update anytime soon. As mentioned in previous posts, really these things need to be designed form the ground up, retro-fitting parallel processing into a current program is fun .

It would be awesome to see DF at its full potential, but I im not going to whinge about a free Indie game being coded by ONE guy.

[Draco18s]

I am a games developer and am currently implementing a  multi-thread / multi-core particle system.... it ain't as easy as pressing a "make faster" button.
But as its on PC/Mac and threads can access main memory (*shakes fist at PS3*), it should be possible to move things like temperature calculations and path-finding tasks to separate threads. But ho-boy don't expect the DF-Multicore update anytime soon. As mentioned in previous posts, really these things need to be designed form the ground up, retro-fitting parallel processing into a current program is fun .

It would be awesome to see DF at its full potential, but I im not going to whinge about a free Indie game being coded by ONE guy.

Finally someone who knows WTF he's talking about in these kinds of things.
Not to say there haven't been others, I just mean a programmer who's tried this kind of thing.

[ferok]

I am a games developer and am currently implementing a  multi-thread / multi-core particle system.... it ain't as easy as pressing a "make faster" button.
But as its on PC/Mac and threads can access main memory (*shakes fist at PS3*), it should be possible to move things like temperature calculations and path-finding tasks to separate threads. But ho-boy don't expect the DF-Multicore update anytime soon. As mentioned in previous posts, really these things need to be designed form the ground up, retro-fitting parallel processing into a current program is fun .

It would be awesome to see DF at its full potential, but I im not going to whinge about a free Indie game being coded by ONE guy.

Finally someone who knows WTF he's talking about in these kinds of things.
Not to say there haven't been others, I just mean a programmer who's tried this kind of thing.

There was another dev a few posts up that had similar insight, but a different view.

And as a game-technology software developer myself, the reality is, the answer is "it depends".  To get the best/most performance, building from the ground up with a multi-threaded approach is the only way to go.  But that is not to say that enormous gains cannot be made in performance in certain (common) situations with relatively small changes.

 There are many threading libraries that will convert a for loop into a multi-threaded for loop, which basically takes a little bit of find and replace.  The catch here is that any given step in the for loop can't depend on any other (this creates an error in logic).  It also means that common writable resources need to not be involved or be made thread-safe (which is conceptually simple, but often in practice difficult).  Both of these will be an issue in some places, and not in others.

The entire game does not need a multi-threading overhaul in order to make an enormous performance boost, of course.  Generally there are few, massive bottlenecks in terms of loops.  If a few of those can be threaded, the game suddenly performs much better without touching a bunch of code all over the place.

However, since none of us have any knowledge of this codebase, how easy threading can be is highly moot.  It must be evaluated on a case-by-case basis.  On the other hand, this isn't a problem that's going away.

[lordnincompoop]

I swear, DF Suggestions is like beating your head against a brick wall sometimes.

Because of the way Today's done his code, a multi-threaded implementation would be incredibly time-consuming, excruciatingly painful to do and is very difficult with his level of programming knowledge. There is little point in arguing that no, it will be easier or harder than people think, because DF is closed source and therefore we have very little idea of how Toady's actually organised his code. On top of that, we have his general unwillingness (at least until more features are implemented), his unwavering refusal to take in codemonkeys and his own statement that this would be incredibly difficult for him to do.

A suggestion like this pops up once a week. I very much doubt that any of your ideas haven't been repeated at least thrice in the long list of woefully uninformed and vague suggestions for multithreading.

[Starver]

The pathfinding suggestions are all in one thread .

I've personally been involved in two specifically-about-pathfinding threads, and don't doubt that I've missed several others (never mind all the times a thread about something else (especially multi-threading or similar)) because of my sheer inability to read absolutely every thread, let alone post to them.

Also, am I misremembering, or doesn't the graphics-display aspect (FWIW, and I think Baughn's and Toady's combined optimisations have made this a relatively trivial task compared to the rest) already potentially run on a different core from the 'mainstream' DF processing?

Anyway, add to that the whole "64 bit isn't necessarily better anyway" argument.

I should hope the OP enjoys the hardware regardless of DF's... deficiencies in this regard.  It isn't going to be at all slovenly with other games that may be vastly more simplistic WRT environment statefulness, but need to do a lot of POV processing, and can certainly sustain the full gamut of the latest Windows/Other-OS bells'n'whistles that some people seem to actually like).  Or creating rendering some multi-pass ray-traced scenes in a fraction of the time he(/she) might have otherwise needed.  Or perhaps quickly running some SETI@HOME-style analyses for the common good (albeit wasting the graphical capability.)  And, what's more, while you're waiting for that to happen you should be able to play DF at almost exactly the same speed as you would if you weren't otherwise gainfully employed in these other projects.

[lordnincompoop]

Graphics is now done on another core, yes, but that isn't what people usually think about then they think "multithreaded". The logic is what people usually want.

I'd just like to mention that Toady didn't code the graphics or the multithreading for that either - he had to let a B12er named Baughn in the project for a short while. This probably attests to Toady's difficulties with the multithreading issue, but also illustrates his reluctance to share his code; Baughn only had access to the small, relevant bits of code, and the code he did see was apparently alrady old.

[ferok]

Because of the way Today's done his code, a multi-threaded implementation would be incredibly time-consuming, excruciatingly painful to do and is very difficult with his level of programming knowledge.

because DF is closed source and therefore we have very little idea of how Toady's actually organised his code.

We neither know how difficult nor how easy it would be.  All that we know is that Toady is so far unwilling.

[lordnincompoop]

We neither know how difficult nor how easy it would be.  All that we know is that Toady is so far unwilling.

We do know that multithreading in general would be very difficult for Toady; he has attested to it himself.

How difficult or easy a certain implementation or method is would be next to impossible to figure out without access to his code. We cannot suggest good implementations either, because we do not know which one would work well with DF.

[ferok]

We neither know how difficult nor how easy it would be.  All that we know is that Toady is so far unwilling.

We do know that multithreading in general would be very difficult for Toady; he has attested to it himself.

How difficult or easy a certain implementation or method is would be next to impossible to figure out without access to his code. We cannot suggest good implementations either, because we do not know which one would work well with DF.

That he says it would be difficult does not make it so.  It my previously referenced quotes, his level of knowledge with regard to threading comes into question.  It could be a lack of understanding, rather than innate difficulty, that is the true issue.

[Draco18s]

We neither know how difficult nor how easy it would be.  All that we know is that Toady is so far unwilling.

We do know that multithreading in general would be very difficult for Toady; he has attested to it himself.

How difficult or easy a certain implementation or method is would be next to impossible to figure out without access to his code. We cannot suggest good implementations either, because we do not know which one would work well with DF.

That he says it would be difficult does not make it so.  It my previously referenced quotes, his level of knowledge with regard to threading comes into question.  It could be a lack of understanding, rather than innate difficulty, that is the true issue.

Or, you know, both.

[lordnincompoop]

We neither know how difficult nor how easy it would be.  All that we know is that Toady is so far unwilling.

We do know that multithreading in general would be very difficult for Toady; he has attested to it himself.

How difficult or easy a certain implementation or method is would be next to impossible to figure out without access to his code. We cannot suggest good implementations either, because we do not know which one would work well with DF.

That he says it would be difficult does not make it so.  It my previously referenced quotes, his level of knowledge with regard to threading comes into question.  It could be a lack of understanding, rather than innate difficulty, that is the true issue.

So we're in agreement. Is there some point you're trying to make?