Print

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

[Grax]

I want to see in the game:

1. Dwarf who can carry TWO light items at once (cloth, threads, sandbags, weapons and other) - BECAUSE THEY HAVE TWO HANDS.
Maybe just divide by weight - for example, (50g) per (level of strength/agility) per (hand).

*It'll be fun to find a dwarf who can carry a gold nugget especially in the first year.

2. Object information in job screen. Dwarf "Store ITEM in stockpile" and the description of an ITEM.

3. Named stockpiles.

4. Prioritization of jobs in list - to not let the stupid dwarfs loose all food when the corpses are rotting.

5. Make the kind of priority marks/signs (like MELT or DUMP or HIDE when you loo"k" onto the specific object) to attract dwarf attention to objects that are lying away and hopeless alone awaiting for some action while the dwarves are dumping a freshly mined stonefield.

That's one of the reasons I'm getting a quad.

I'm too, Q8400@4000.
But there's a major problem in DF - it's not a multicore program.

And in my opinion it's the least time-consuming solution to pathfinding problem - multithread that procedure to let the system spread them on other processor cores.

[Jackrabbit]

I have no idea about hardware or anything but one thing I picked up is that people in this forum do not like the word multithread. I don't know why.

[SirHoneyBadger]

I have no idea about hardware or anything but one thing I picked up is that people in this forum do not like the word multithread. I don't know why.

It's not the word itself, or even the concept, it's the idea that Toady doesn't currently do multithreading, and (apparently, I don't have a reference) doesn't want to halt his current work in order to learn how.

So we get a *lot* of requests for it, but it's not likely to happen anytime soon (the possibility that it will after the game goes "gold" does exist, but who knows?), and therefore it causes a certain amount of frustration and eyerolling.

Apparently, from what I've read, there are some very good arguments for the application of multithreading to the game, but I only know the very basics of it and am in no way qualified to judge it's merits.

[Sean Mirrsen]

Multithreading or parallel processing would allow to stick tasks happening in parallel - such as flows and pathfinding - into parallel threads that would execute simultaneously on several cores, thereby greatly increasing performance. The problem is that conventional single-threaded applications are very hard to restructure for multithreading once they've grown past a certain point, and DF seems way past that point by now. There are ways to automate parallelization, but more often than not it doesn't work as it should, and I don't think I remember it being possible to do with C.

Supposedly, there's some kind of system out there on the Internet that allows a single-threaded app to utilize multiple cores, but I forgot its name, I don't recall them claiming it to work on anything other than rendering engines, and it most surely isn't free.

[Neonivek]

Apparently, from what I've read, there are some very good arguments for the application of multithreading to the game, but I only know the very basics of it and am in no way qualified to judge it's merits.

Yeah but a lot of the time they seem to have an unrealistic view of what Multithreading does.

Though I am not computer expert... 0*4 = 0

Not 100.

Though I am only assuming that multithreading can only multiply the framerate by the cores available at best. (once again this is an assumption)

So a lot of people wouldn't actually be better off with multithreading. This isn't a arguement against multithreading as coupled with a more efficiant code Dwarf Fortress would be noticably faster... it is more or less a peave of mine when seeing people argue for it when their framerates suggest that even multithreaded it wouldn't help them.

[AbuDhabi]

I don't have a clue what y'all are concerned about framerate for.  I've always played with weather, cave-ins, temperature, and other stuff turned on, and my framerates have been either a reliable 30-50 FPS(pre-graphical upgrade) or 100+ FPS(post graphical upgrade) on my dinky little 1.6 Ghz Celeron M processor.

It's really not that bad.

Can you tell me how you're doing that? (By that I mean pasting your init file, and whatever else that might have an impact.) I have here a 2.0 GHz Sempron with 1.5 Gb of RAM, and once I get more than 20 dorfs, it feels like I'm Mother Nature in a Powerthirst commercial.

[Sean Mirrsen]

I regularly attempt braving 6x6 sites with chasms and magma on my 2.0GHz C2D Santa Rosa, but the only times I experienced slowdowns was when playing with battery saving settings on. I suppose there's a lot of Heisenbugs in the pathfinding and game logic, which seem to surface on a per-machine basis with no discernable pattern.

Also, multithreading will help, and help a lot. Suppose you split ALL pathfinding into threads. If previously it would eat up 50% of your one core, on a quad-core it could get SIX TIMES MORE POWER^*, thus no longer being a bottleneck. I have no idea how the A* pathfinding thing operates in reality, but if you can clear the order que six times faster, you'll have to dump orders in at least six times faster to begin clogging the que up again. And since game logic has a speed limit, it's likely you'll have much more than a sixfold performance increase.


*: Presuming it gets three cores while everything else keeps one.

[Neonivek]

SIX TIMES MORE POWER

That is half more then my guess which is four times.

So people who have horrible Framerate with microfortresses will still have horrible framerate with normal fortresses even with multithreading. So my Peave remains.

[Mel_Vixen]

Before we talk aboiut multithreading we should talk about a rework off the Bottlenecks like Weather and Temperature. Why? Just because it would help everyone and it could still be multithreaded later.

Also a dualcore programm isnt 2 times faster then a singlecore. Generally you can say that you get a plus of ~ 80% because the negotiatian and communicationof the cores takes some processing time.

Anyway we have again derailed far enought i think.

[Neonivek]

Well Toady is apperantly programming in Huge Lakes with the slight problem of the Lakes falling off the edge of the play area.

I wonder if lakes could have dried up when you get there. Though since it happens with the smaller ones I can only assume the much larger Lakes are the same.

Time for a Toady Quote

- Update 'nastiness' for mats vs. eating/etc

[Tormy]

I have no idea about hardware or anything but one thing I picked up is that people in this forum do not like the word multithread. I don't know why.

It's not the word itself, or even the concept, it's the idea that Toady doesn't currently do multithreading, and (apparently, I don't have a reference) doesn't want to halt his current work in order to learn how.

So we get a *lot* of requests for it, but it's not likely to happen anytime soon (the possibility that it will after the game goes "gold" does exist, but who knows?), and therefore it causes a certain amount of frustration and eyerolling.

Apparently, from what I've read, there are some very good arguments for the application of multithreading to the game, but I only know the very basics of it and am in no way qualified to judge it's merits.

I think it's quite clear, that DF must be multithreaded in the future. Just take a look at the v1.0 dev items. If all of these will get implemented...I am not sure that how much FPS we gonna have. The whole generated DF world will be active & alive [+hundreds of new features will be added] -> Realtime processing. Right now RT processing is only "true" about the embark area.
Either way, let's stick to the topic lads.

[Random832]

I don't have a clue what y'all are concerned about framerate for.  I've always played with weather, cave-ins, temperature, and other stuff turned on, and my framerates have been either a reliable 30-50 FPS(pre-graphical upgrade) or 100+ FPS(post graphical upgrade) on my dinky little 1.6 Ghz Celeron M processor.

Is that on a 6x6 map with 200 dwarves and running water and magma?

[Tormy]

I don't have a clue what y'all are concerned about framerate for.  I've always played with weather, cave-ins, temperature, and other stuff turned on, and my framerates have been either a reliable 30-50 FPS(pre-graphical upgrade) or 100+ FPS(post graphical upgrade) on my dinky little 1.6 Ghz Celeron M processor.

Is that on a 6x6 map with 200 dwarves and running water and magma?

1.6Ghz Celeron + 6x6 map with 200 dwarves = zero FPS. 

[Random832]

Another idea, as the caves are being formed any gemstone tiles that are being deleted should instead be preserved and moved down a level and left exposed on the cavern floor for us too find (probably not even requiring mining).  This would make the caves a desirable place to go gem collecting while also being consistent with standard fantasy lore and geology, the possibly dangerous animals would balance the rewards.

Another thing that would be nice with caves: Line of sight discovery. Even without a fog of war, requiring you to send a dwarf somewhere they can see it to be able to see what's in the cave would be fun. (Bonus if once gems are discovered, a horde of dwarves immediately goes out to grab them if you don't forbid them)

Also would be nice - well, practically required if we're going to have significant underground enemies (sieges?) - a way to designate areas as "secure" and "insecure", rather than just relying on underground status for the 'dwarves stay inside' order.

[Footkerchief]

Another thing that would be nice with caves: Line of sight discovery. Even without a fog of war, requiring you to send a dwarf somewhere they can see it to be able to see what's in the cave would be fun. (Bonus if once gems are discovered, a horde of dwarves immediately goes out to grab them if you don't forbid them)

04/03/2009: [...] I also think I'll be able to update discovery/revealing of the local underground so that it depends more on where your dwarves have actually been, instead of revealing everything. Active LOS around every dwarf isn't feasible, but it can push the frontier off through the connected areas when a dwarf is vaguely nearby, anyway, so that there can be enormous connected (adventure-explorable) caverns without having them pre-revealed just because you have some dwarves tinkering around far, far above. I'm sure there will be some issues, but that's normal. This doesn't mean everything will be connected... I guess that might as well be up to world generation, anyway.