Print

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

[willfarb]

Dwarf Fortress is probably my favourite game ever. I cannot -- and am sure I don't need to -- describe just how awesome it is. Literally awesome; inspiring of awe. Nothing else combines such wonderful character with such engrossing engineering-based gameplay. Surely no single man could possibly have within him the ability to lead a project of such dichotomies!

Since I can't really draw, my fan art is in the form of Java code:
http://www.youtube.com/watch?v=wrOwiUdMG5I

A friend and I, little baby first and second year CS uni students respectively, spent a little while playing with a proof of concept DF-like toy in Java, with a heavy emphasis on multi-threading. At the time, we weren't much anything of coders, but I think we certainly achieved something. In the video above there are more than 1000 dwarves all moving and digging, and the frame rate was still capped. Elsewhere in the map, there is water flowing in a river. Perhaps I will upload a binary, so people can see for themselves. Obviously, this isn't exactly a complete simulation - we don't have Dwarven Lung Men, Bronze Collossi or even stairs (quite) yet.

Why make that? As I said; fan-art. We both dearly love this game, but neither of us have played more than a few mins after each update in a year or more, because after my epic auto-flooding gatehouse-maze went online and our populations climbed over 100, the game is just too slow to play.

I know that multi-threading/performance is probably an oft-discussed topic here, and probably a great source of ire when someone new comes along and says "u shud multi-thred it" -- please don't be angry at me! This is not a threat or a bribe. We're not going to start some stupid competing open-source clone if our ultimatum of better performance isn't met . We're not going to say "Oh man, I'd totally donate... but only if it was faster". We're not trying to compare starting a new project from scratch designed for multiple processes with trying to add that in at a later date. Apples are not oranges, and we're not stupid or dicks! There's already a great game like Dwarf Fortress we can play; called Dwarf Fortress! I repeat: please consider this fan art!

I would like to posit this as a positive affirmation of love and respect for our favourite game, coupled with a sincere desire for greatly-improved performance.

[Ampersand]

I know that multi-threading/performance is probably an oft-discussed topic here, and probably a great source of ire when someone new comes along and says "u shud multi-thred it" -- please don't be angry at me! This is not a threat or a bribe. We're not going to start some stupid competing open-source clone if our ultimatum of better performance isn't met . We're not going to say "Oh man, I'd totally donate... but only if it was faster". We're not trying to compare starting a new project from scratch designed for multiple processes with trying to add that in at a later date.

That in spades. If you want to, you can search for it and find the hundreds of pages of discussion that has promptly beaten down any real expectations of DF ever being multi-threaded without a near complete re-write.

[willfarb]

I know that multi-threading/performance is probably an oft-discussed topic here, and probably a great source of ire when someone new comes along and says "u shud multi-thred it" -- please don't be angry at me! This is not a threat or a bribe. We're not going to start some stupid competing open-source clone if our ultimatum of better performance isn't met . We're not going to say "Oh man, I'd totally donate... but only if it was faster". We're not trying to compare starting a new project from scratch designed for multiple processes with trying to add that in at a later date.

That in spades. If you want to, you can search for it and find the hundreds of pages of discussion that has promptly beaten down any real expectations of DF ever being multi-threaded without a near complete re-write.

Exactly, so I'm very concerned with everyone knowing I'm not one of those miserable gits who wants to rag on about it all the time, and that my expectations are realistic. I suppose I really just wanted to feel a little like there was something I could do (even if there isn't!).

[Ampersand]

If you really want to do something, head on over to the pathfinder thread here;

http://www.bay12games.com/forum/index.php?topic=43265.0

The reason your project won't help much is mostly because it's in Java. Of course, The Pathfinder project isn't focused on Multithreading, but just optimizing the rather brute force approach to pathfinding Dwarf Fortress takes, but who knows, maybe you can work a miracle. But, even the basic purpose of the project I'm sure you're capable of contributing to.

[willfarb]

If you really want to do something, head on over to the pathfinder thread here;

http://www.bay12games.com/forum/index.php?topic=43265.0

The reason your project won't help much is mostly because it's in Java. Of course, The Pathfinder project isn't focused on Multithreading, but just optimizing the rather brute force approach to pathfinding Dwarf Fortress takes, but who knows, maybe you can work a miracle. But, even the basic purpose of the project I'm sure you're capable of contributing to.

Oh I wasn't naive enough to think my Java project would get used somehow; I just wanted to do something DF-related without playing DF, if you understand my meaning.

That project you mentioned is a good idea. I think there would be a lot of use for an external open source (non-virally-licensed for inclusion in DF) pathfinding library. Since working on that old java project I've done a lot of queueing simulation work in C++ as well as working for a company specialising in mapping and routefinding so I may be of some use perhaps. I shall scan that thread for the repository and bug tracker.

[Tilla]

Note Baughn made mention recently that there might possibly be some multi-threading stuff on the way for the SDL/OpenGL code that will be merged into the main game. There is hope!

[Ethnar]

Guys, read what he wrote.

He doesn't want a discussion on multi-threading DF, he just wanted to show (kind of specific) fan-art he made (and he made it having some with fun multi-threading).

That said, it's really pleasant to the eye. Really like how you can leave area unmarked and "dwarves" bump into the wall, not taking it down.

[willfarb]

Haha, yes, the Dwarves behaviour is goofy because we haven't implemented any idle behaviour. If a dwarf has no job, it just stands there. Like I said - we're not nearly silly (or talented) enough to seriously try and replicate the epic undertaking that is Dwarf Fortress!

If anyone wants some lols, a version can be downloaded here:

http://will.pi-team.org/misc/DwarfKeeper.zip

The map has a braided river (New Zealand and Argentina represent! http://en.wikipedia.org/wiki/Braided_river) which starts empty and slowly fills up for you (debugging) and, one z-level down, 101 dwarves that you can make dig holes for you.

Issues that will never be fixed: Afore mentioned goofy dwarves; many errors in everything, water still quite a hideous CPU hog 

Controls:  < and > do z-levels. Arrow keys move persistent cursor, shift + arrow keys moves lots. Just like DF. Designate and Dig are similar ish, but have buttons for them. Go up into the sky z-layers to see the ghetto multi-layer dithered bitmask transparency effects!

[Peteł]

Ooh, nifty.. although I get some nasty flickering and the dwarves seemingly stop digging after some 50 tiles. Weird.

[Demon]

The next 40d will run the game and the display on separate threads.  That's probably about the most multi-threading possible, but it means a huge boost in speed for all the dual core people.

[zwei]

Problem with multithreading is that it requires dutifull locking of all shared data. In DF, pretty much anything you want to work over is shared and mutable to boot so it requires lock or else you are going to get quite weird corruptions.

For example, say, there is workshop order from manager.

first, you find suitable dwarf (iterate over list, to pick one able to fullfill task).

first lock! you need to lock dwarf object in list that you find before you set order. else, you risk that any concurent operation of same kind messes you up (say, seccond workshop that also got same order). this means that any operation of dwarf gets blocked till you assign task.

well, not exactly just dwarf, your list itself during iteration can change (random deaths, immigrants, whatever). You pretty much should lock it too. Result? While you are iterating and looking for suitable dwarf, all threads that would result in list modification must wait. Chances are, it is unit list and not just dwarf list.

Similar goes for items and workshops and whatever...

There is just too much stuff that can result in data corruption if you mess up with threading and if you are way too carefull, you end up having threads, allright, but they are pretty much always blocked. And god help you debugging it if some situation leads to deadlock ...

Anyhow:

FPS: 170. Averge time spent drawing 0
FPS: 64. Averge time spent drawing 0
FPS: 170. Averge time spent drawing 0
FPS: 171. Averge time spent drawing 0
FPS: 57. Averge time spent drawing 0
FPS: 171. Averge time spent drawing 0
FPS: 170. Averge time spent drawing 0

Sometimes performace falls to what were used at DF d# editions. I wonder how it would fare if you rewrite it as synchronous app.

[willfarb]

The code relies on the new automatic sprite acceleration in Java 1.6, so I think users still with 1.5 or on Linux won't get a whole lot of fun. The example I uploaded with just 101 guys runs at 600 fps for me. Also bear in mind that it was written by two guys not even half-way through an undergraduate degree at the time; a blind rodent stumbling over a keyboard could write better code.

Thank you zwei (two?), but I do know about mutexes and synchronisation. Java has a nifty and easy system whereby I don't need to lock my Dwarf object; I can lock specific member variables and methods and it dynamically handles most of the thread blocking states for me as well. This means that access times aren't bad at all; according to the profiler we're using, each thread usually only spends less than 2% of the time blocking. We've seen an almost linear increase in performance going from one to two to four cores testing it here. However, I would imagine overhead gets severe around 16 cores (the effect of non-divisible tasks is exponential).

However, while I defend the speed increase which is possible with parallelism, I continue to acknowledge that it is impractical to add it in to an existing project. And if Today doesn't want to spend a few months doing no new features or bug-fixes just to re-write the pathfinding manager, then that's probably understandable :p All the best rock bands say they write music that they themselves want to listen to, and if everyone else likes it too, then that's also cool; such is it with game development :-)  Even so, I personally wouldn't mind seeing nothing new for a year or 18 months even, if it meant I could play with 250 dwarves and as much water as I like!

[Ampersand]

Bask in the glory guys, a reasonable, understanding, and sane Escaped Lunatic. If only they were all such.

[Heavy Flak]

Bask in the glory guys, a reasonable, understanding, and sane Escaped Lunatic. If only they were all such.

You just have to separate the wheat from the chaff, so to speak.  I applaud Willfarb, both on his fan art and level head.  Good show, friend.  Good show <3