Print

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

[Sorgklaan]

Basically, I want somebody to help explain it to him. He doesn't understand how an ascii game can be so resource intensive and he has mocked me relentlessly because of it. He's a major elitist snob who only plays modern games with HD 1080420P blaze it graphics.

[steel jackal]

tell him its single threaded, locked at 2GB ram, has to pathfind for hundreds of entities, simulate tens to hundreds of other civilizations (depending on the world) has to simulate the lives of thousands if not millions of individuals, has to do (less advanced) pathfinding for those individuals, has to simulate diplomatic actions between civilizations, has to keep detailed track of hundreads of unique monsters all with unique bodies, descriptions, and characteristics, keep track of who killed who with what when and where, has to keep track of every freaking finger, toe, fingernail, toenail, organ, body part and skin of every living and undead in your fort, has to keep track of everyons completely unique personality, has to keep track of every item ever made that still exists, has to keep tract of every single historical event ever from an unimportant dwarf eating cheese to a dragon melting a loaf of bread with its fire breath, has to keep track of every engraving which of there may be thousands in each fort and can have a great amount of detail in what they say if you have good engravers and has to track thousands of unique objects just inside your own fortress, all of which can have hundreds of decorations.


oh and did i forget to mention that your GPU is utterly useless in this game and that your CPU has to do all the work and since its single threaded you can only use 1/4th (intel) or 1/8th (AMD) your cpu capacity?

and you better pray to chuck norris that armok dosnt send 500 zombies, 100 demons, and a few megabeasts at you at the same time, lest you die from the sheer quantity of enemies dragging your FPS down

all of that on 2gb of ram

[Melting Sky]

The best way to demonstrate it to him is take a save of 40 year old fortress with 150 dwarves in it on a good sized embark with a volcano that just breached the circus and install it on his gaming rig and watch it bring his rig to its knees.

[King Kitteh]

tell him its single threaded, locked at 2GB ram

I don't know why, but I don't think this'll stop his mocking.

[Immortal-D]

Admittedly, DF isn't so much resource-intensive as poorly optimized   When Toady gets around to 64-bit and all of the multi-core CPU goodness that comes with it, your FPS won't even blink at a mere 100 catsplosion.  That said, just tell him about the sheer level of detail involved in this simulation.  For example; The game computes every body part, of every creature, in every battle, for the entire length of WorldGen, just in case you want to read about the hilarious and bloody history of your world.

[Edward_Tohr]

When Toady gets around to 64-bit and all of the multi-core CPU goodness that comes with it

Not to keep striking this ‼XXMangled Horse CorpseXX‼, but those are two very, very different things. Lumping them together is like saying "I have 32 gigs of RAM, and all of the CD burning goodness that comes with it".

[Lordhermitcrab]

Admittedly, DF isn't so much resource-intensive as poorly optimized   When Toady gets around to 64-bit and all of the multi-core CPU goodness that comes with it, your FPS won't even blink at a mere 100 catsplosion.  That said, just tell him about the sheer level of detail involved in this simulation.  For example; The game computes every body part, of every creature, in every battle, for the entire length of WorldGen, just in case you want to read about the hilarious and bloody history of your world.

But wouldn't it be immensely difficult to recode this entire game so that it runs on 64-bit? I mean, change one thing and another 5 bugs pops up somewhere, right?

[Spinning Fly]

Maybe this?

Spoiler (click to show/hide)

Edit: And that's just with a fort running in a 2x4 biome in a pocket size world. If you had a fairly advanced fort in a massive world with a much larger area, you'd probably see much more RAM usage.

But I don't really get the question...is he mocking you because your computer is having trouble running a game that (according to him) isn't resource intensive? Or is he mocking you because you're playing a game that (according to him) is not resource intensive?

If it's the former, then just pop DF on a usb drive and run it on his computer. That would show him how slow it gets even on his ultra badass rig.

If it's the latter, and the only reason he's turning his nose up at DF is that it's not as resource intensive as the games he plays, then he's a fucking moron anyway and there's no point wasting time on this.

[King Kitteh]

But I don't really get the question...is he mocking you because your computer is having trouble running a game that (according to him) isn't resource intensive? Or is he mocking you because you're playing a game that (according to him) is not resource intensive?

If it's the former, then just pop DF on a usb drive and run it on his computer. That would show him how slow it gets even on his ultra badass rig.

If it's the latter, and the only reason he's turning his nose up at DF is that it's not as resource intensive as the games he plays, then he's a fucking moron anyway and there's no point wasting time on this.

I think it's because he doesn't think a game with ascii graphics could be resource intensive. Seemingly he thinks that graphics are the main cause of intensiveness in a game.

Honestly you can't really blame him, most modern games strain the graphics card the most. They aren't overly complex in terms of content. It's kinda like how people laughed at minecraft for being laggy when it has bad graphics.

[Findulidas]

Your friend is an idiot or a bully. I mean it doesnt take much imagination to figure out how to make a complex game without using much graphics. You just have to keep adding stuff that the computer has to keep track of. You can then also make each new feature interact with each other.

Such as temperature having an effect on when fat boils, then that having an effect on dwarves being injured. Then it has to calculate wounds. Then it has to calculate pain. Then it has to calculate if the dwarf can continue doing what hes supposed to do or give into pain. I mean its easy to have it cascade.

[PatrikLundell]

Keeping up the beating of the ‼XXMangled Horse CorpseXX‼...

Going to 64 bits shouldn't be incredibly difficult, as it's mostly a matter of changing compiler switches, although care will be needed to ensure data types are changed to larger ones when appropriate (with the attendant adjustments of any pointer offset access to data). 64 bits won't provide much in itself, as it mainly allows DF not to crash when requiring more than 2 GB memory, but instead continue to crawl at 0.1 FPS. 64 bits is basically an enabler, like a sturdier foundation allowing you to build a higher house.

Multi threading, however, is a completely different matter altogether. It's not insanely difficult to do when implemented from scratch and basic discipline is maintained, but retrofitting something not intended for it is a fair bit more complicated. Let's try a DF analogy:
In this DF mock system we can order the production of a loaf of bread, and, as e.g. digging orders in the real DF, tasks are given in a priority order and allocated in that order. Urist McHermit is given the following tasks with the following priorities:
1. Harvest wheat (and store it in the food stockpile).
2. Pick up wheat from the food stockpile and mill it into flour.
3. Store wheat flour in the food stockpile.
4. Pick up flour from the food stockpile and take it to the kitchen to make a loaf of bread.
5. Store the bread in the food stockpile.
6. Pick up the bread from the food stockpile and eat it in the tavern.

In the multi threaded case Urist McOne harvests the wheat, while Urist McTwo, Urist McThree, Urist McFour, and Urist McFive all "cancel task, no source material". And finally Urist McOne "cancel task - no bread".

In multi threading you have to ensure everything that's dependent on things happening in a specific order actually are performed in that order, delaying dependent jobs until the preconditions are met. Sometimes you might not care which order things are happening in (regular wear of a ¤sock¤ vs wear of that same sock due to burning), and sometimes they're not related at all (King of fortress Distant ordering the execution of the Liaison in spring and the harvest of plump helmets in Fortress Local during the same tick. The former should affect Fortress Local only when the news reaches the fortress MANY ticks later, although you may give engravers the liberty of knowing, but then you have to take care the engravers aren't reading data that's only partially written). With multi threading you also have to ensure data protection, i.e. that one thread isn't affecting a piece of data while another one is reading it. If we take the !¤sock¤! above, it doesn't really matter if the wear due to fire or wear is applied first, but it does matter if its done as:
- Burn thread: Read current !¤sock¤! wear.
- Wear thread: Read current !¤sock¤! wear.
- Burn thread: Subtract burn damage wear from !¤sock¤! and write it back.
- Wear thread: Subtract wear from !¤sock¤! and write it back.
In this case the burn damage is lost, because the wear thread overwrote the results from the burn damage. This can be even worse if the !¤sock¤! gets destroyed, so the burn thread removes the now ex ¤sock¤ from the game, and the memory used by that ¤sock¤ is reused to store some completely different data altogether, like a pointer to the list of items in a new migrant's inventory. When the wear thread writes the !¤sock¤! wear it now overwrites a pointer with a wear value, and DF will probably terminate the next time it tries to access the migrant inventory list, as the pointer is corrupted and doesn't point to any legal memory in DF at all.

I'd try to explain what's said by others above. If the friend isn't interested in listening, just stop mentioning DF to him, as it's obviously a subject there's no point in discussing.

[King Kitteh]

-snip-

Kinda sounds like the longer Toady puts off multi thread support, the harder it'll be to add 

[Orange Wizard]

Kinda sounds like the longer Toady puts off multi thread support, the harder it'll be to add 

Pretty much, although it's basically impossible at this point anyway because you'd need to gut and rewrite 10+ years of code.

But wouldn't it be immensely difficult to recode this entire game so that it runs on 64-bit? I mean, change one thing and another 5 bugs pops up somewhere, right?

64-bit version is in the works now, and it's hardly rewriting the entire game like multithreading would be. It should speed things up a little, and unlock more memory so paging won't be such an issue.

[Shonai_Dweller]

-snip-

Kinda sounds like the longer Toady puts off multi thread support, the harder it'll be to add 

And since Toady just said that it's mainly badly optimized code (for which he has a fix-list) rather than single core threading that causes fps death it probably won't get done any time soon.

[PatrikLundell]

Getting a better FPS is the goal, and multi threading is just a means. If better optimization improves the FPS gains then optimization should be higher on the priority list than threading. However, the more stuff that's thrown into DF and the more of these things there are (64 bits allowing it), the more likely it is multiple threads have to be used (but that won't help if the DF processing is limited by memory access throughput rather than CPU, though).

The more code you produce without thoughts of multi threading the harder the task. I wouldn't be surprised if a proper multi threading overhaul of DF took several years. However, you can produce new code that at least provide the basics (such as making sure all new objects introduced are accessed only via methods/operations/APIs... that either support concurrent access protection or allows easy implementation of it. It ought to be possible to implement partial threading as well, by locating tasks isolated from most everything else and put that in separate threads, with the data stores shared with the rest of DF being protected. At some time, however, the bullet will probably have to be bit through a long multi threaded only arc, with the DF coming out at the other end being a fair bit faster and subject to many horrible threading bugs that takes quite a long time to clear up. If the multi threading support was introduced properly, DF shouldn't just terminate, but produce some kind of report indicating what failed (that's sound programming practice not tied to threading, but it's surprisingly uncommon nevertheless). Such error reports would typically not tell you what was wrong itself, but rather where it was detected (such as "trying to access non existent creature inventory item", but it won't tell you where DF failed to properly remove the reference when the item itself was removed).

The problem with producing a threading foundation with new code is that most of the new code will still access the old data stores in the old, unprotected, ways, and the old code/design probably doesn't provide for a nice easy way to provide access to old data in a more multi thread ready way. You can retrofit one data store at a time, but that requires first locating and then rewriting of all the places that accesses that store.