How many hours will I be able to run Dwarf Fortress on a 1950X before it becomes unplayable (less than 1 FPS)?

How many hours will I be able to run Dwarf Fortress on a 1950X before it becomes unplayable (less than 1 FPS)?

Attached: 1507079215477.jpg (1920x1080, 363K)

Other urls found in this thread:

factorio.com/blog/post/fff-215
google.com/search?q=dwarf fortress sergal
twitter.com/NSFWRedditGif

its not threaded

Just cap your dwarves retard

dont use tilesets you faggot

How can a 2D game be so demanding?

Everytging is active at once, never goes to sleep

...

Literally every single organ of every creature is tracked, this is an autism simulator

Jow Forums approved game

>Literally every single organ of every creature is tracked

Attached: 12d.jpg (567x561, 57K)

Because its single threaded. No matter if the CPU has trillion cores, the game is designed to only use 1.

Is there a technical reason or are the devs just bad?

>devs
It's one dev

It's shit because it's not open source

Fuck off retard, ASCII destroys my retina after hours of gameplay.

Game was in development for a really, really, really long time.

I thought it was two brothers working on it?

Still, it is possible to make it multi threaded if they really wanted

It is multi threaded and 64b for more than two years retards.

In DF, once your fortress is full of items and history, it tends to get memory bandwidth limited. So, I forget exactly what hardware factors control it, but 1 FPS is simply untenable for a playable save.
The real answer for how long your could play is strongly dependent on the size of map you use (world and fortress) and your playstyle. The bay12 forums have a lot of well documented discussion on the matter.

Attached: Burned_beast.png (640x301, 21K)

>it tends to get memory bandwidth limited
SHIIIIIET NIGGA what's maximum RAM supported by Linux? 1 TiB?

>inb4 GNU/Linux
For once I'm actually referring to the kernel itself

Factorio devs wrote an fff blog post about issues with adding multi-threading.

factorio.com/blog/post/fff-215

Why do you think so?

Limited by bandwidth, not by the amount of memory.

>67271280
>Why do you think so?
Hes confused that some versions of the game use a separate SDL thread for graphics output, northing more.

>it's not open source

Attached: 1505123038460s.jpg (250x166, 4K)

Will DF get so bloated that you need a supercomputer to play when it gets to version 1.0?

It's just one dev, and he's stated that he is specifically not interested in making it run well ("We are not trying to make a game that's a technical marvel" iirc). It's a shame, I would like to play it on a large world with many dwarves, but the game runs like ass after hours of play.

He's afraid that somebody is going to use part of his code to release their own simplified dwarf fortress clones. But DF "clones" have already happened like rimworld. Minecraft was influenced was DF.

Probably. It's not complete until it simulates every single known elementary particle.

>rimworld
sounds naughty

Wait... this game doesn't offload anything to GPU?

It has actually 2 threads, one for rendering and 1 for everything else.

What are you implying user?

Attached: 1.jpg (1280x1829, 291K)

Shame terraria doesnt borrow more from df, that could be interesting

Is Dwarf Fortress a rabbithole worth going down?

Absolutely, you'll have arrived once you dream in ASCII graphics.

Yes.

Trust me, it's worth it. After all the struggle it eventually clicks and becomes maximum comfy. You are only limited by your imagination and perserverance.

Attached: 1531534886381.jpg (500x356, 175K)

What a degenerate. Rollercoaster tycoon (assembly) should be the base line for gaymen programmers

I've never gotten into reverse engineering. On a scale from side project to mission impossible, how hard would it be to open up the binary, find some intensive processes (water, pathing), and make just those few bits multithreaded?
Targeting linux, of course

not just organs, fingers, teeth, ears, eyes, nose; it differentiates between muscle, tendon, nerve, fat, organ, open wounds, and bruise damage as well

this is what happens when a phd in math codes a game

I would estimate it to be nearly insurmountable. Just guessing from the fact that he doesn't want to do any optimizations, the existing methods are probably so interlaced with everything else that it would turn to a convoluted mess in assembly. not to discourage you, as I would definitely like an optimized DF.

That is one of a kind, you can't have that shit with current game developers. I guess DOOM devs are pretty cool, even 2012 mid range cards can run that pretty game well.

RCT was written in assembly as otherwise it wouldn't run on anything but a supercomputer. Besides, with modern compilers, do you even gain that much benefit writing something in assembly?

That sucks, cus even light threading (like seperating pathing) could do a lot I imagine.

Its not "high level" vs assembly so much as writing it in assembly indicates the author is actually competent with optimisation. A modern compiler is good and all but its not going to optimise poorly coded work

I wonder when we're gonna start using meme learning on compilers

No. Game will crash many times before you get the hang of it.

Why the hell did this guy want to release a free (gratis) game but not a free(libre) one? I think it's probably because he doesn't want retards running amok in his code.

it would cause fragmentation of the community quite quickly
he may also be ashamed of his code, I bet it's 10,000 spaghetti mess

*10,000 line

spaghetti is good, majority of spaghetti type languages are lower level, so run far faster and are far more optimized than OOP. So I doubt that.

10k is kind of a low number for something the scope of dorf fort

I'm imagining 10k lines all in one file, not across the project

How does DF differ from HomeWorld? It was a 3D space war/battle simulator that kept track of each spaceship across a large expanse for full matches. Is DF doing something more?

read the thread

Multithreaded fluid updates might not be so bad. Same for temperature. Multithreading unit pathing would probably be hard though. Each individual pathing call is pretty quick so there's not much room for parallelism internally. You'd have to do something tricky like returning a dummy path immediately and shipping the query off to a background thread, then when the game realizes that the dummy path didn't actually get the unit to its destination and checks again, you give it the real result (assuming it's ready).

As for the low-level reverse engineering part, look up DFHack. They've got reverse engineered header files for most of the major data structures, and I think for some of the functions as well.

>1950X
>before it becomes unplayable (less than 1 FPS)
14+ years

It keeps track of every body part and mental process of every creature. Dwarfs going rampage because their pet cat died is kind of a meme there.

Worth it.

Attached: mariana_cavern.png (1160x4706, 863K)

>he may also be ashamed of his code, I bet it's 10,000 spaghetti mess
It absolutely is. The linux version comes with source code for part of the UI code. It's about 20kloc and it's pretty horrible to read.

i hope he has a backup that goes public in case he dies.

No joke, his bother and one or more trusted members of the community have sections of the source code stored in safe places. They have instructions, in writing, to combine them and open source the whole thing if he dies. So long as it is not under 'mysterious circumstances.' He said this explicitly in a podcast or something.

based

I tried to get into it years ago. It was a mess, both gameplay and technical wise. Most of the depth of the game comes from procedural/random generation.

The wiki contains a fairly detailed explanation of why it strains hardware. Like the posters said it need a good single core and good memory bandwidth. Every entity is constantly being checked that’s why one of the main strategies is item destruction. My 930 could handle 100+ dwarf forts for longer than I could maintain interest. 7800k runs the game great.

where can I see UI code?

g_src/ in the df_linux tarball

CLA > ASCII > any other tileset

autistically complex system that is coded by one guy (who admits he's absolutely shit at it) with zero optimization/no threading

even that's baby shit and you know it

Not really. It comes from the interaction of the many many subsystems. Even Toady can't really predict how shit will work out. The stuff with cats suddenly dying en masse after some patch, for example.
If you like buzzwords, I think emergent is the correct one.

Get a better color palette then

>yfw toady doesn't use any version control

I don't know if I'd like to discover how someone would write DF without OOP, inheritance, etc.

Dwarf Fortress is one of those games that it's more fun reading about other people playing it than actually playing it yourself.

Like EVE-online I guess.

Can't wait to use my rtx 2080 to use Ray tracing to calculate my dwarves organ vectors

...

Those tiles destroyed mine.

Nah.
Playing the game is incredibly comfy and fun.

>>>Anyway, let's move on to what I expect was one of the biggest challenges in developing the game: the amazing pathfinding.
>TA: Is it amazing? It's creaky and slow.
>>>Well it looks amazing from my end, since there's a metric ton of characters all doing it at once.
>TA: The dwarves themselves mostly move around with A*, with the regular old street-distance heuristic. The tricky part is that it can't really call A* if they don't know they can get there in advance, or it'll end up flooding the map and killing the processor.
>>>Sometimes in commercial projects the developers do a bit of cheating, and predefine travel paths.
>TA: Yeah, that's the hard part. We can't really predefine areas beyond very basic notions because fluids can zip by and block them off, or they can mine a floor out. All it does now, and this isn't ideal, is keep connected component numbers. So if a dwarf is standing in "2", they know they can't get to "3" and don't bother trying. However, they assume they can get to any other "2", and will A* those paths. There are still a few failures, but it's fixable.
>There's a price to pay for that though, on a few levels. First, it's a pain to maintain. If a fluid occupies a square, it has to update. If a fluid flows through a passageway and cuts it in half, it has to reindex one or both sides.

By "update" does he mean doing a BFS on the whole map to redefine the connected components?

open source game = faggots adding fursuits
it already happened with CataDDA

they're already at the gates
google.com/search?q=dwarf fortress sergal

yeah DF modding community is infested with some of the faggiest shit imaginable, thankfully the Adams brothers have remained (mostly) pure

>this is what happens when a phd in math codes a game
You say like its a bad thing