Print

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

[Silverionmox]

Also consider that Toady is remarkably trustworthy and durable for a free game developer. The internet is paved with webpages dedicated to game projects that were started off with great enthusiasm but floundered before completion. Never change a winning team - even if it is a one-man-and-his-brother-team.

[Irenices]

I dont know anything about programming, so yeah, but it would be cool if he got some help with just some basic engine stuff like making it run on more than one processer, and like someone said things like the UI and what not.  Things that don't really effect the gameplay just give a better experience with it, im sure there are excellent programmers here who would be willing to donate some of there time doing this.

[Kogut]

I dont know anything about programming, so yeah, but it would be cool if he got some help with just some basic engine stuff like making it run on more than one processer, and like someone said things like the UI and what not.  Things that don't really effect the gameplay just give a better experience with it, im sure there are excellent programmers here who would be willing to donate some of there time doing this.

Multithreading is NOT basic nor easy. It is extremely hard to do it in proper way and multithreading bugs (race conditions) are ridiculous hard to replicate. It is typical that certain racial condition will happen only on certain FPS or only with disabled debugging or only on certain processors, or only on certain FPS with disabled debugging, or...

http://en.wikipedia.org/wiki/Race_condition#Computing

[Irenices]

Sorry i didnt mean to imply it was an easy thing to put in, i meant basic as in under the hood stuff that players would never see, perhaps a poor choice of wording.

[nighzmarquls]

The best way to help toady as a programmer as far as I can tell would be to supply programming examples of difficult to solve problems he might encounter and raw data for the statistics of his game.

Save him research time for potential solutions so he can focus on what he loves

Beyond that everything else turns into problems of inexperienced individuals meddling in a very intricate machinery that is a game engine.

[hermes]

I dont know anything about programming, so yeah, but it would be cool if he got some help with just some basic engine stuff like making it run on more than one processer, and like someone said things like the UI and what not.  Things that don't really effect the gameplay just give a better experience with it, im sure there are excellent programmers here who would be willing to donate some of there time doing this.

Multithreading is NOT basic nor easy. It is extremely hard to do it in proper way and multithreading bugs (race conditions) are ridiculous hard to replicate. It is typical that certain racial condition will happen only on certain FPS or only with disabled debugging or only on certain processors, or only on certain FPS with disabled debugging, or...

http://en.wikipedia.org/wiki/Race_condition#Computing

Hey Kogut, I've seen you post about the difficulties of multithreading before and I wanted to ask you, is it really that hard?  I use Java, though I'm sure with the appropriate libraries C++ would be almost identical, and threading a function, giving it an array to buffer jobs and work through them and maybe using an interface function to send the results back, is really not hard at all to implement.  I've always thought that kind of thing would work well for pathfinding provided the function has visibility of all necessary variables.  Have I missed something that makes it a lot harder than this?

[Kogut]

I dont know anything about programming, so yeah, but it would be cool if he got some help with just some basic engine stuff like making it run on more than one processer, and like someone said things like the UI and what not.  Things that don't really effect the gameplay just give a better experience with it, im sure there are excellent programmers here who would be willing to donate some of there time doing this.

Multithreading is NOT basic nor easy. It is extremely hard to do it in proper way and multithreading bugs (race conditions) are ridiculous hard to replicate. It is typical that certain racial condition will happen only on certain FPS or only with disabled debugging or only on certain processors, or only on certain FPS with disabled debugging, or...

http://en.wikipedia.org/wiki/Race_condition#Computing

Hey Kogut, I've seen you post about the difficulties of multithreading before and I wanted to ask you, is it really that hard?  I use Java, though I'm sure with the appropriate libraries C++ would be almost identical, and threading a function, giving it an array to buffer jobs and work through them and maybe using an interface function to send the results back, is really not hard at all to implement.  I've always thought that kind of thing would work well for pathfinding provided the function has visibility of all necessary variables.  Have I missed something that makes it a lot harder than this?

It is is obviously doable. There is one major problem - Toady have zero experience with multithreading (AFAIK) and he explicitly announced that multithreaded DF is not planned (confirmed).

Hasn't Toady expressed in the past that he has no interest in learning parallel processing? That kind of kills most of these ideas right off the bat.

EDIT: Toady answers the question:
DF Talk #9, at 57 minutes 53 seconds, or Ctrl+F "multiple cores" on the transcript.

The part that isn't on the transcript:
Toady: hehhehhehhehhehhehhehheh
Rainseeker: Uh oh.

And "It's complicated, and from what I gather it would be a really difficult long project and it's probably not going to happen."

[Aquillion]

I think you're overthinking it!

Toady enjoys working on Dwarf Fortress the way he is now; I don't think he really wants to have to run things past a team of people or worry about someone changing something under him -- he has a vision of the game he wants to make in his head.  And he's not starving to death (if you're worried, the donate button is right there.)

He has no reason to change the way he's doing things.  Toady and Dwarf Fortress are doing fine the way they are.

EDIT:  Regarding multiple cores, I'll just copy-paste from the transcript.

Rainseeker:   Here's a technical question; 'Recently in computer architecture the paradigm has shifted to multiple cores. I was wondering if Dwarf Fortress will support multiple threads eventually, and if so what timescale it will occur in.'

Toady:   It is my understanding that the SDL stuff is now multicored, with the graphics and the graphics display and so on. Now obviously people, when they're asking about it, that's one important point but people are curious like 'why can't I have seventeen dwarves pathing at once' or 'why can't you take that stupid ass weather simulation and make that go happen on some core, preferably not at all'. It's complicated, and from what I gather it would be a really difficult long project and it's probably not going to happen. That's what I gather. Now there are some things, like these micro multithreading of a smaller process just to get through one loop faster, it can break it up and then come back without it being a case of running path finding at the same time as you're running a fluid simulation, and that stuff, the more I know about that the better, probably, and maybe that's feasible. As for splitting up the path finding and stuff: some people have discussed about how that might work, but as for whether anything is actually going to come of that, I wouldn't bet on it anyway.

So some minor multithreading might be viable, but the big things would require major rewrites and are unlikely.

[astaldaran]

where multithreading gets complicated (if someone knows more about the subject, feel free to correct me) is that it can have the same difficulties as a team. 

So the program gives each team member a job or jobs and then each team member (core) goes off and does it's job and comes back with the results to share with the rest of the team.  Well what happens when team member A has to go accross the country to measure the depth of the grand canyon and core B, in Ohio, needs to know the measurements of Core A in order to write the text book he is working on...If Core A has to wait for Core B to get back anyway..has splitting up the job between two cores useful anyway?

And that is the primary problem with multithreading in dwarf fortress. I know the illustration wasn't very good but essentially multithreading gets more return on investment the more isolated the code running in the different threads are from each other.   So for some things that are nearly independent (as Toady said "Now there are some things, like these micro multithreading of a smaller process just to get through one loop faster") that it makes since to throw somewhere else...but for a lot of stuff there is just way to much communication that has to happen to easily implement or may not even be able to implement in a way which actually improves performance.

Now, I do qualify this in saying that had Toady started out with a multithreaded approach, it would be a whole lot easier to take advantage of it..but even then it wouldn't garauntee that he could really use it to its full potential. For example, why is splitting the path finding off from the rest not simple?  Well lots of things in the other core rely on the result of the pathfinding, so they have to wait for that second core to return the pathfinding values before they can go about their business. Does that mean it can't be done? No, but it is complicated especially to add in and the gains might not be worth it.

Multitheading is best for things like operating systems where you can have different isolated programs running on different cores.

Now things like graphics might be split off, maybe various clocks and checkers and some math but because of how integrated everything in DF is, I doubt we will see it multithreaded much.

Now one place where I could see it being multithreaded is for continued world events going on around your fort while you are playing.  A second core could just essentially sit there and do World Gen stuff while you play, and only occasionally passing information to and from your fort (like when the caravans come).

[Jenniretta]

Honestly I would be a bit concerned by outsourcing toady got for the game, I think a big part of why it's such an amazing game is because he's not fighting with a team of coders over how to do this or implement that - as a solo developer he can do things the way he feels is best, and keep the game as close to his vision for it as his skill as a coder (and time, etc) allows. The more people get involved, the more compromises he would have to make for the group to function, and the farther from his ideal the game would get. At least with the current development model, fans can give feedback and help improve the game, but it's up to Toady how to handle everything, and what suggestions to listen too, etc. So he can keep an eye on what needs work, while still maintaining control.

As for the possibility of him passing away before it's complete, that is an unfortunate possibility for anything like this, it would be very sad if that were the case, but at least toady has an archive of older version around, and if I recall in the readme file it says redistribution is allowed - meaning if something does happen the community and game can continue in whatever state he left it in at least.

If you really want to help the game thrive and continue, then donate when/if you get a chance, and if you can't do that, try to advertize for him, I've gotten a few people to play and hopefully at least one or two of them will love it enough to make a donation.
><; I need to donate but I currently have no money to spare (student loans are a problem...) but I plan to make a donation if I get any extra cash soon.
Toady is nice enough to offer this amazing game free, despite how much work he's putting into it - I think he's earned the donations.

As for multithreading, the poor guy has so much to do for this game, and trying to make multithreading work properly, on his own (which I think is how he would handle it if he chose too) would probably put progress in most or all other goals of the project on hold for a very long time, If he finds a way to implement it quickly and painlessly, then maybe it would be worthwhile, but as-is I don't see it being a reasonable goal, and I don't think it's something we should expect to see. (not to mention as others have said he basically said "no" to it, lol)

[peskyninja]

Oh crap! Another discussion about helping Toady...

[Phmcw]

To sum up what need to be said :

Multithreading is a bad idea that won't give much benefits. This is not an highly thread-able application, and if it's doable easily toady will do it.

Another programmer would be an intruder, and if your read Toady's bio, you'll find i clear that it won't happen.

Code need to be improved, toady know. But since he got to redo the path-finding, he'll do it after he tackle more work on how the map work. I really don't see why he'd make a final and optimized version now.

And a personal one : do you know what is a gaming computer? Yeah? You want to have a game as good as commercial ones? yes? Then make it run on a proper gaming grade hardware : DF won't and shouldn't work well on older comps. (All you actually need is a fact comp, with lot of good ram).