Print

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

[lucusLoC]

I know that for the 40d# series Toady broke out the display code so that it could be worked on by interested and more knowlagable parties. I am also vegly aware that there is some other "game" that uses this engeine, so that said parties could work on the problem without seeing the DF code.

My question (pretty much directed solely at Toady) is would that be possible, and worth it, to do for the fluids and pathfinding? These are the two biggest drains on cpu usage, and are hindering me, and others im sure, from making the uber city/water park forts we dream of.

I know that Toady wants to not have to manage other programers, and i think the sucsess with the d# series shows that he can get relativly no presure help on the more sticky issues. But that, of course, is just the impressions of an outside observer.

(On an asside, i hate not having spell check available. Sorry for the horrid spelling)

[Warlord255]

Outsourcing bits of pathfinding code is risky, but so far the 40d## modifications have been OK.

The main complication of extra coders is that you lose knowledge of all interconnected systems, of which there are MANY in this game. Presently, the pathfinding code is a chunk which is pretty much isolated from other parts of the code. If the fluid handling is like that as well, then it would stand to reason that Toady could humor attempts by other coders to provide a superior fluid handling algorithm which he could then introduce without other people meddling in the important stuff.

[lucusLoC]

i kinda figured those would be the only other sections of code that this wold work for. it seems that the functions would be fairly isolated, and as long as Toady kept the input and output requirements fairly strict that those hunks of code would be fairly modular. maybe not so much for the fluid code, since that probably has to access map data a lot, but the path finding seems like it would only be called after the map data was already processed. just a guess though.

[Kholint]

I really like this idea, especially as it means DF might get multithreading in the areas it needs it most, but there's one potential show stopper (which isn't so much an issue with the openGL code):
Even if the pathfinding and fluid simulation were as modular and abstracted from the rest of the game as realistically possible, toady will in all likelihood have to modify the code later if there's some major map structural change (especially on a similar level of 2D -> 3D).

The openGL code for the 40d## series more or less doesn't need a massive amount of touching as long as toady doesn't port DF to the crytek engine (best kitten smashing game meets the best korean smashing engine), so it might as well be magic, but if the fluid and pathfinding were rewritten using the best intelligent caching systems and multithreaded to scale indefinitely to 2, 4, 8 or even 512 cores, toady would need to fully understand it to continue to develop DF with any kind of independence.

(By the way, I do realise the horribly condescending tone this post has in regards to toady "understanding" things, but he's stated before he doesn't have a particularly good grasp of multithreading (nor is he particularly interested in improving said grasp), so I think it's a fair point.)

[lucusLoC]

well, assuming maximum abstraction of those functions (e.g. A* is a function unto itself in the code, and has no other dependencies) then all Toady would have to do is keep the input and output data formatted the same. if for some reason he needed to change that format, then he would be at the point where he would have had to rewrite his old code anyway, so he could just do that. meanwhile he could post the new function specs and have the community work on that. which is, i think, what he did for the openGL rewrite if i am not mistaken.

of course this all depends on how integrated the pathing and fluid code is. if it is highly integrated then this is all a moot point anyway. but if it is a separate, distinct and well defined function then i don't see why it should not be possible to have it "outsourced"

[Granite26]

Pathfinding requires access to the entire map.  For this to be any appreciable speed, it would need to have access to the normal storage structure of the map

Good OOP could mean a class that only has read access back to it, but it's still huge chunks of the inner bits of map storage.

[jaked122]

this is going to have to wait until toady realizes that Dwarf fortress must outlive himself, and then release the source code once (god forbid) he dies.  I will attend that funeral

[Corona688]

Pathfinding requires access to the entire map.  For this to be any appreciable speed, it would need to have access to the normal storage structure of the map

Good OOP could mean a class that only has read access back to it, but it's still huge chunks of the inner bits of map storage.

OOP is not data protection.  If one part of the program can write to it, so can another, and language features to stop this are easily circumvented.  Hell, the DF community has proven that hardcoded binaries are not data protection.  Exposing map data will just make it easy for modders to dick with it.

I still think this isn't the death of the idea.  The outside library could be used to provide an algorithm but not be given the data itself.  And optimizing fluids fluids would be awesome.  Something like the 'hashlife' algorithm may be possible, which could be vastly more efficient.

[lucusLoC]

Why is making map data more accesible to moders bad? I know toady does not want to feel forced into helping third party add on developers, but that does not mean he cant make it esier.

Of course all of this is hinged on 2 factors: 1. That Toady liked working with the opengl group and fealt that he could do it again and 2. That the code is written in such a way as to allow it. Both of those qestions only Toady can answer.

[Granite26]

Why is making map data more accesible to moders bad? I know toady does not want to feel forced into helping third party add on developers, but that does not mean he cant make it esier.

Of course all of this is hinged on 2 factors: 1. That Toady liked working with the opengl group and fealt that he could do it again and 2. That the code is written in such a way as to allow it. Both of those qestions only Toady can answer.

1: There is a goal that the game not broadly depend on any 3rd party application to be run by the general public.  That is, if a large portion consider it 'unplayable' without a specific 3rd party app working, that's bad.

2:  Once the map data is exposed to modders, using the map data for modding becomes official.  Any future changes to the map data (a not unlikely occurance) will likely break all future mods.  Assuming there was a 'pathfinding' dll that attached to DF and did the pathfinding 3 times faster.  If a new release came out and this mod failed, people would think DF itself was having problems (because it's working at 1/3 speed).  That's a huge leap of faith for somebody whose livelihood is on the line.

You're right... the OpenGL stuff may open the door to this stuff in the future, but it might not.  Remember, we're just passengers who are lucky to be along for the ride.