Print

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

[Sizik]

*facepalm*

Edit: Map writes are what I thinking of when I wrote that, which someone mentioned before.

[Dozebôm Lolumzalìs]

Guys there is a misconception

I love that phrase, it's my new sig once I get back on my comp.

Anyway! I was responding to people who were afraid that if fluid logic had its own thread, the game would go on without it, and on slower computers, water would flow slower. Multi threading is great, and I never meant my statement to disparage its utility.

[Dirst]

Guys there is a misconception

I love that phrase, it's my new sig once I get back on my comp.

Anyway! I was responding to people who were afraid that if fluid logic had its own thread, the game would go on without it, and on slower computers, water would flow slower. Multi threading is great, and I never meant my statement to disparage its utility.

"What is that?"
"It's a wall of water rushing down the passage right for us!"
"So why is it, you know, just sitting there?"
"CPU must not be able to keep up the updates.  You know, more threads that cores."
"Wonder what is hogging up all the resources."
"Probably our AI.  So don't stop thinking."

[galneon]

This thread resulted in some excellent insights from khearn who could speak in more specific terms regarding the inevitable day of reckoning, and I hope Toady reads it at some point.  Khearn's well-established ethos warded off most of the rowdy locals in denial as DEET repels bloodthirsty mosquitoes.  I was not so protected, but I'm honored I was able to provide a platform for this dose of reality despite the protectionist furor it initially attracted.  I've emerged unscathed.

[NJW2000]

This thread resulted in some excellent insights from khearn who could speak in more specific terms regarding the inevitable day of reckoning, and I hope Toady reads it at some point.  Khearn's well-established ethos warded off most of the rowdy locals in denial as DEET repels bloodthirsty mosquitoes.  I was not so protected, but I'm honored I was able to provide a platform for this dose of reality despite the protectionist furor it initially attracted.  I've emerged unscathed.

And you're being very agreeable about it.

[Fniff]

"What is that?"
"It's a wall of water rushing down the passage right for us!"
"So why is it, you know, just sitting there?"
"CPU must not be able to keep up the updates.  You know, more threads that cores."
"Wonder what is hogging up all the resources."
"Probably our AI.  So don't stop thinking."

And to the out-of-context thread she goes.

[Dozebôm Lolumzalìs]

Hey, khearn thought each dorf would have their own thread. What does he play on, a 10000-core machine? I DEMAND RECOGNITION FOR CORRECTING THE MISCONCEPTION

jk

Srsly, galneon, y u so mean? Who're u calling a "rowdy local in denial", a "bloodthirsty mosquito", a forumite with "protectionist furor"? Nobody deserves to be called that. Most everybody here has been civil. except u with ur mean words

[Geltor]

http://www.bay12forums.com/smf/index.php?topic=154172.0

this topic was approached from every direction in that thread. im surprised how many people think you need to re-invent df for concurrency support.

the only thing that stands in the way between you and an unlimited, 100 fps dwarf fortress forever is refactored path-finding with multi-threading. path-finding is the only major bottleneck of end-game performance in df (i say this with confidence). re-writing only that single section, no matter how difficult, surely must be easier than re-writing the entire game. if anything, that would be a great start.

[Dirst]

http://www.bay12forums.com/smf/index.php?topic=154172.0

this topic was approached from every direction in that thread. im surprised how many people think you need to re-invent df for concurrency support.

the only thing that stands in the way between you and an unlimited, 100 fps dwarf fortress forever is refactored path-finding with multi-threading. path-finding is the only major bottleneck of end-game performance in df (i say this with confidence). re-writing only that single section, no matter how difficult, surely must be easier than re-writing the entire game. if anything, that would be a great start.

It might be the place with the most bang for the buck, but it may not be the best place to start for any number of spaghetti-code reasons that only Toady knows.

Of course, if there is some off-the-shelf multithreaded A* solution lying around then pathing moves many places up in line for multithreading treatment.

[Xazo-Tak]

It's entirely possible, but it's also entirely the wrong time in the game's life to do so.
 all the time spent on the previous optimisation a waste

Making the game run better and faster is a job to wait until all the features are in, so there's less coding clashing going on. Once everything is in the game that Toady wants, that is when people should go back and look over it, find ways to make it faster, whatever. There's simply no point wasting time on something that could quite easily be rendered obsolete so quickly.

On the contrary, optimisation should be done as early as possible.
Otherwise you're building good code on a bad platform, and if the platform is changed the code has to be changed.
Unfortunately, it's too late in the game's development to do some really cool optimisations and improvements, moving away from a tile based system early on would have helped so much but now the whole game's built around tiles.

I had an idea for how pathfinding would work in mesh based terrain that could be applied to tile-based terrain though. Divide floors into rectangles as large as possible, since they're very simple to figure out pathfinding with.

[Urlance Woolsbane]

moving away from a tile based system early on would have helped so much but now the whole game's built around tiles.

Could you explain why you think that's the case? I don't see why it would be such a boon. Surely it would only make things more complicated?

It's worth noting that DF's predecessor, Slaves to Armok, wasn't tile-based. It's not as if Toady hasn't tried doing things that way

[Xazo-Tak]

moving away from a tile based system early on would have helped so much but now the whole game's built around tiles.

Could you explain why you think that's the case? I don't see why it would be such a boon. Surely it would only make things more complicated?

It's worth noting that DF's predecessor, Slaves to Armok, wasn't tile-based. It's not as if Toady hasn't tried doing things that way

It means objects can be located anywhere in space rather than being confined to a grid (Though it'd still be possible to keep the game looking exactly the same as it does now) which greatly simplifies physics calculations because there isn't the strange task of making physics apply to a tile-based game.
It also means that terrain and structures can be mesh-based, which is better for simulating their destruction and can have their vertices used as pathing nodes (If a beeline to the target destination is not possible, the AI is definitely going to make a beeline towards a vertex).

[Putnam]

moving away from a tile based system early on would have helped so much but now the whole game's built around tiles.

Could you explain why you think that's the case? I don't see why it would be such a boon. Surely it would only make things more complicated?

It's worth noting that DF's predecessor, Slaves to Armok, wasn't tile-based. It's not as if Toady hasn't tried doing things that way

It means objects can be located anywhere in space rather than being confined to a grid (Though it'd still be possible to keep the game looking exactly the same as it does now) which greatly simplifies physics calculations because there isn't the strange task of making physics apply to a tile-based game.

That is completely off-topic, unless you're actually saying that easy to program implies easy to compute. If so, I want this list sorted by bogosort in the next 5 minutes:

Code: [Select]

5 4 7 5 1 2 3 4 9 1 5 4 3 4 9 7 5 1 2 3 4 3 5 7 1 2

Bogosort is very simple to program, heck, here's a quick implementation in python:

Code: [Select]

import random
def bogosort(yourlist):
    while not all(yourlist[i] <= yourlist[i+1] for i in xrange(len(yourlist)-1)):
        random.shuffle(yourlist)


[Urlance Woolsbane]

moving away from a tile based system early on would have helped so much but now the whole game's built around tiles.

Could you explain why you think that's the case? I don't see why it would be such a boon. Surely it would only make things more complicated?

It's worth noting that DF's predecessor, Slaves to Armok, wasn't tile-based. It's not as if Toady hasn't tried doing things that way

It means objects can be located anywhere in space rather than being confined to a grid (Though it'd still be possible to keep the game looking exactly the same as it does now) which greatly simplifies physics calculations because there isn't the strange task of making physics apply to a tile-based game.

I'm not the most knowledgeable in this department, so have patience with my ignorance, but doesn't a tile-based system allows for Toady to "cheat" more easily than a mesh-based one? Most physical discrepancies in DF are invisible, which is beneficial not merely in terms of immersion, but also in regards to optimization. Surely not having to calculate each object's mesh (even rather primitive ones, per your proposal) frees up a fair amount of processing power for DF?

It also means that terrain and structures can be mesh-based, which is better for simulating their destruction and can have their vertices used as pathing nodes (If a beeline to the target destination is not possible, the AI is definitely going to make a beeline towards a vertex).

Agreed, but I'm not sure that's viable for something with the scale of DF. Look at the FPS-damage done merely by flooding or by smoke. Imagine the processing-strain resulting from simulating all the minuscule bits scattered by a cave-in.

[Untrustedlife]

moving away from a tile based system early on would have helped so much but now the whole game's built around tiles.

Could you explain why you think that's the case? I don't see why it would be such a boon. Surely it would only make things more complicated?

It's worth noting that DF's predecessor, Slaves to Armok, wasn't tile-based. It's not as if Toady hasn't tried doing things that way

It means objects can be located anywhere in space rather than being confined to a grid (Though it'd still be possible to keep the game looking exactly the same as it does now) which greatly simplifies physics calculations because there isn't the strange task of making physics apply to a tile-based game.

That is completely off-topic, unless you're actually saying that easy to program implies easy to compute. If so, I want this list sorted by bogosort in the next 5 minutes:

Code: [Select]

5 4 7 5 1 2 3 4 9 1 5 4 3 4 9 7 5 1 2 3 4 3 5 7 1 2

Bogosort is very simple to program, heck, here's a quick implementation in python:

Code: [Select]

import random
def bogosort(yourlist):
    while not all(yourlist[i] <= yourlist[i+1] for i in xrange(len(yourlist)-1)):
        random.shuffle(yourlist)


As a programmer That got me to laugh out loud +1 my friend +1.