Print

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

[bombzero]

I still think the main issue is not pathfinding in the game.

NW_Kohaku has already traced a lot of lag back to item indexes.

temperature calculations are a known mass consumer of CPU time.

fluid is nearly as bad as temperature.

I think pathfinding actually has the LEAST noticeable effect on the game, every open world roguelike I have seen points to large number of items as a huge source of lag.

[g1real]

I'm about 80% sure that you're just not going to be able to do this without actually decompiling DF (at least not easily). Utilities like DFHack that already exist to interface with DF are not capable of modifying running code on the fly nor redirecting code flow, at least so far as I'm aware. And that's pretty much the state of the art so far as hacking DF goes.

I've actually read some issues about someone who was decompiling dwarf fortress and recompiling his own version with optimizations in. He advertised it on this forum and subsequently got (perma)banned. The guy behind DFhack was passively involved, but did not condone it. It's not that it's not possible, its that it's disrespectful towards Toady, who doesn't want it to happen (and therefor banned the guy who did it)

If you really want to prove that this idea is feasible for DF (and that's the most important bit right there), I think that your best bet would be to write a parallel program that can more or less mimic what DF has to do so far as path finding goes in a completely single threaded manner. Then rewrite your code from there to deal with handing off control to the thread pool.

Because, realistically, that's what's going to have to happen. DF has almost a decade (if not more, I think work started around 2004?) of work put into it. Retrofitting a new system, particularly one that deals with concepts the programmer hasn't dealt with before (multithreading) is not at all a trivial task. That's the main problem people are having it.

Ah right, it's like saying we shouldn't ever research and attempt proper casual transportation into space because it's too costly and unneeded really.
Yeah I'm a bit of a dick for comparing it to that, I just think a bit more pressure on getting multicore support would be beneficial, it's halfway to 2013 already, we're (nearly) having consumer-ready 6 cores available on the new socket 2011.

[G-Flex]

I've actually read some issues about someone who was decompiling dwarf fortress and recompiling his own version with optimizations in.

I don't know why people think this is as feasible an option as they do. Compiled binary and source code do not have a 1:1 correspondence even if you know what IDE and compiler were used. "Decompiling" does not, and can not, work the way people think it does.

[g1real]

I've actually read some issues about someone who was decompiling dwarf fortress and recompiling his own version with optimizations in.

I don't know why people think this is as feasible an option as they do. Compiled binary and source code do not have a 1:1 correspondence even if you know what IDE and compiler were used. "Decompiling" does not, and can not, work the way people think it does.

Where exactly did I state it was easy? Or feasible? Or work any other way then it would?

I stated no such things, I simply stated someone was attempting to decompile or had done so as reference and reason as to why it isn't done.

[10ebbor10]

I remember hearing about such an incident. The version I heard was that someone decompiled/ got hands on part of the source code and used that to make his own game.

It was stated as to why Toady doesn't open source things, among many other reasons

[g1real]

I think the reason he doesn't do open source is so he doesn't lose control over the project and/or lose his income because he's afraid a group of people would work faster, appease the crowd more. For the game itself it would probably be good, for Toady not so much, my humane side can respect that, my selfish side...

[weenog]

I think the reason he doesn't do open source is so he doesn't lose control over the project and/or lose his income because he's afraid a group of people would work faster, appease the crowd more. For the game itself it would probably be good, for Toady not so much, my humane side can respect that, my selfish side...

List and detail what you think would be better about the game if it were turned open source, please.  Be specific.  Also be advised that You != The Crowd and there are plenty of players that want what you hate, and are adamantly opposed to what you think would be great.

[bombzero]

if I am completely 100% honest, I do not want Dwarf Fortress to go open source after seeing the games community.

I mean, no offense to you guys in general, but there appear to be a number of people who...
1) know how to code.
2) have some stupid ideas.
3) harbor stupid ideas that were originally inside jokes of the older community.

this would result in a number of very, very bad forks of DF popping up over time, and likely not having a single copy anywhere that is even somewhat relevant to Toady's wonderful ideas for the game.


basically.

You != The Crowd and there are plenty of players that want what you hate, and are adamantly opposed to what you think would be great.

this.

[G-Flex]

I remember hearing about such an incident. The version I heard was that someone decompiled/ got hands on part of the source code and used that to make his own game.

It was stated as to why Toady doesn't open source things, among many other reasons

Nobody got their hands on any of their source, but I believe some reverse-engineering was involved of some form. Beyond that, I don't know much.

[thisisjimmy]

I remember hearing about such an incident. The version I heard was that someone decompiled/ got hands on part of the source code and used that to make his own game.

It was stated as to why Toady doesn't open source things, among many other reasons

Nobody got their hands on any of their source, but I believe some reverse-engineering was involved of some form. Beyond that, I don't know much.

It's a bit off topic from the original post, but what I think might have happened is that Toady accidentally released DF with debug symbols in it one time.  This would allow someone to get much more readable code when they decompile it.

[G-Flex]

I know he released a version with symbolic information retained, so probably a debug release. I'm not sure what kind of information that contained, though.

[aha]

I'm about 80% sure that you're just not going to be able to do this without actually decompiling DF (at least not easily). Utilities like DFHack that already exist to interface with DF are not capable of modifying running code on the fly nor redirecting code flow, at least so far as I'm aware. And that's pretty much the state of the art so far as hacking DF goes.

http://stackoverflow.com/questions/5063577/asm-opcode-injection-with-c

I'll write a simple function to interact with memory mapped files and inject it to the appropriate location. This is for later though, working on a visualizer/simulator atm.

[aha]

Usually you would use a heap for the open list.  This will let you pop the minimum value in O(log(n)) time.  I'm not sure what your current system is, but if it takes linear time, then using a heap should give you a much better performance boost than any of the micro-optimizations.

Thanks, timed the open list operations and it was slooooow - using a hybrid queue with a small heap on top now - will tweak it further when I get the simulator going.

[JanusTwoface]

this would result in a number of very, very bad forks of DF popping up over time, and likely not having a single copy anywhere that is even somewhat relevant to Toady's wonderful ideas for the game.

You do realize that's not generally how open source projects work / have to work, right? You are well within your rights to release the source code under the condition that:

- No one else is allowed to fork the code
- Any changes to the source code must be submitted back to the original author for review.

Granted, few projects are actually licensed under such restrictives terms, but it's entirely possible to do. Then it's not really that much different from decompiling or copying the code. Technically, it wouldn't be *that* hard to write a program that duplicated a good part of DF without ever actually seeing the source. It's much easier to duplicate an idea / implementation that someone else has already put a decade of work in than to come up with it all yourself.

I remember hearing about such an incident. The version I heard was that someone decompiled/ got hands on part of the source code and used that to make his own game.

If you really want to read more about it, the core of the argument came down here. The project that resulted from that still exists on github (if you really want to see it and can't find it yourself, PM me and I'll send you a link) but hasn't been touched in over a year. A bit more evidence that clones / forks like this tend not to have nearly the success that DF has for whatever reasons.

http://stackoverflow.com/questions/5063577/asm-opcode-injection-with-c

I'll write a simple function to interact with memory mapped files and inject it to the appropriate location.

Hmm. Interesting. That would be the why of my 80% figure. It's possible, but not particularly easy. Out of curiosity, have you done anything like this before? It might just work, but you're going to run into a few issues with reverse engineering enough of the code so that you don't below anything up when you're mucking around. I'm actually curious if it even can be done.

One last future note, you may want to read the copyright notice in the readme.txt file

Spoiler: Copyright from 0.34.11's readme.txt (click to show/hide)

*** COPYRIGHT INFORMATION ****************************

Copyright (c) 2002-2012.  All rights are retained by Tarn Adams, save the following:  you may redistribute the binary and accompanying files, unmodified, provided you do so free of charge.  If you'd like to distribute a modified version of the game or portion of the archive and are worried about copyright infringement, please contact Tarn Adams at toadyone@bay12games.com.

This software is still in development, and this means that there are going to be problems, including serious problems that, however unlikely, might damage your system or the information stored on it.  Please be aware of this before playing.

You may actually be fine if you actually write a program to inject code rather the redistributing DF with your changes in it, but it still doesn't hurt to read it at least. Granted, this sort of worry is still a long way off. I was just curious myself he'd actually put in his copyright so I went and looked it up.

This is for later though, working on a visualizer/simulator atm.

You may want to look at this thread, specifically this simulator someone already wrote. When we say that pathfinding has been discussed extensively, we're really not kidding.

[thisisjimmy]

Technically, it wouldn't be *that* hard to write a program that duplicated a good part of DF without ever actually seeing the source. It's much easier to duplicate an idea / implementation that someone else has already put a decade of work in than to come up with it all yourself.

This is so true.  Most of the work in game development is all the designing, iterating, tweaking and balancing.  Cloning an existing project goes much, much faster.