Print

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

[DwarfStar]

Indeed modern processors have very high bandwidth to CPU local caches, so multithreading a data-bound process might be “as simple as” dividing the workload so each CPU only needs to touch a subset of the total memory. But that might require a deep rewrite of core data structures to realize.

As far as VRAM goes, DF probably only uses graphics hardware for the obvious purpose of rendering. So the only data needed in VRAM is the sprites and some buffers telling where to draw them, what color and blending mode. It’s possible to offload game logic processes onto graphics hardware, but that requires even more deep rewrites than I mentioned above. Even then, getting the data on and off of VRAM is a hassle. There’d usually be no reason to put game logic data in VRAM unless you were processing it there.

[Mr Crabman]

As far as VRAM goes, DF probably only uses graphics hardware for the obvious purpose of rendering. So the only data needed in VRAM is the sprites and some buffers telling where to draw them, what color and blending mode. It’s possible to offload game logic processes onto graphics hardware, but that requires even more deep rewrites than I mentioned above. Even then, getting the data on and off of VRAM is a hassle. There’d usually be no reason to put game logic data in VRAM unless you were processing it there.

Given that the Steam page lists a simple GPU requirement, I think even if it doesn't now (not sure if it's just another thread, or actual GPU use), it will indeed use it for rendering soon.

Yes, certainly just keeping the game data in VRAM would be pointless (detrimental even), but my idea was indeed to process the data there; the kind of processing that GPU's are well suited to, like temperatures, fluid flow, and also according to some people, pathfinding?

Might be worth mentioning the processing order of the game loop right now, which Toady revealed in an interview 2 years ago (https://www.gamasutra.com/view/news/343859/QA_Dissecting_the_development_of_Dwarf_Fortress_with_creator_Tarn_Adams.php), as it probably has implications/hints for what data each part of the processing logic is assuming is already done:

Spoiler (click to show/hide)

What does the main game loop look like?

In dwarf mode, say.  It starts with some announcement checks and considers autosaves, etc.  A lot of the rest doesn't happen every tick.  Every hundred ticks, for instance, it'll check job assignments and 'strange moods.'  Armies are moved on the world map.  Every hundred ticks (staggered from the job check), it handles job applications by dwarves, a kind of invisible auction that it uses to manage the various competing priorities.  Every ten ticks it advances the seasons, which actually does all kinds of things with the weather and map (both locally and in the world), and it also does a check for certain plot element advances (diplomats, sieges, etc.), and it checks whether your fort is still alive.

Then it hits some things that it does every tick.  Fluids and other map tile information is advanced (though there are various optimizations here so that not every tile is necessarily checked every turn, and there are various flags so that entire sections of the map can be skipped if nothing has happened.)  Vermin running around are updated.  Other 'events' on the map, like active fires, are handled.

If a flag is set, wounded/thirsty/hungry dwarves that can't care for themselves get an update, and every so often, dead dwarves 'think' about their burial arrangements so that jobs can be set.  Caged and chained creatures update their thoughts and situation periodically.

Then creatures leave the map if they are set to at the edges.

Every fifty ticks, staggered from other updates, all of the taverns, temples, libraries, etc. get their information updated.  Stockpiles, staggered on a different tick, also work this way.  Similarly with storage job creation, though that process is complicated with various optimizations and lengthening ping times and so forth, and it's still slow, since at some point, 50000+ boulders will cause trouble.

Every thousand ticks, objects that have been marked for deletion and removed from the game are actually deleted and freed.  This happens more often with items, every fifty ticks, along with a building use check (mostly updates for wells and some other flags that often need checking.)

We hit another every tick update at this point.  Projectiles are moved.  Activities (which range from dances to martial training to storytelling) get updated as needed.  Dwarves and other creatures decide on and advance their immediate actions (movement to an adjacent tile, working at a workshop, etc.) -- the bulk of their AI (outside of job selection) is here.

Every hundred ticks, items are rotted.  Every tick, vegetation is advanced (though there are various staggers and flags here.)  Building states are updated every tick as needed, and minecarts are moved.  Hauling routes are advanced.  Temperature is updated (there are various optimization flags here, but this is still an unfortunately slow process.)

Finally the camera is updated to follow the creature you are following, if any.

[DwarfStar]

That’s an interesting bit of that article, for sure! Thanks for posting that.

The main thing it does to me is to underscore what a huge amount of work it would be to multithread DF. Each of those subsystems would have to be significantly revised. The data structures would need to be able to absorb new calculations at any time, possibly while another system is querying it. Which by the way would slow the whole thing down on single processor systems. Using the GPU is even harder because you have to translate the code to shader language and figure out how to get good throughout, something the CPU kind of takes care of for you. Oh, and then you get bugs that only affect some graphics cards. When you’re done, it’s just the one system that’s now optimized…so one out of about a dozen listed in that article.

Granted, if you really liked to do huge fluid projects, just having the fluid sim super optimized might seem worth the effort. But lots of people would have different priorities.

[Schmaven]

I think I heard in 1 of the Dwarf Fortress Talks that the GPU requirement is probably in there because "graphics requirements" can't be left blank when listing a game. 

[PatrikLundell]

I just remembered there was a blind DF player on the forum a couple of years back. How will the change to tiles for the character set affect the ability to translate the display into sound? Has any thought gone into that, and, if so, has any support been thought of?

[Bumber]

I've been looking through the disassembly of a function that returns a plant at an x, y, z coordinate. (Looks like it's called by tree chopping and rendering code, among others.)

It looks like it checks if ((x / 48) * 48) < 0 || ((x / 48) * 48) >= map_size_in_x_tiles. (It might also be (x - x%48) in your code.)

This check will succeed for values of x as low as -47. Same for the y check. The checks should probably be using the regular x and y coordinates.

There's a check inside a loop that will reject any index that would be outside of the array of a tree struct, though an incorrect result (instead of NULL) could be returned if the value ((tree_dim_x / 2) - plant_x%48) + x%48) is somehow >= 0 and < tree_dim_x for a tree. This is all dependent on a negative value somehow being passed to the function, of course.

[voliol]

I just remembered there was a blind DF player on the forum a couple of years back. How will the change to tiles for the character set affect the ability to translate the display into sound? Has any thought gone into that, and, if so, has any support been thought of?

Blind people probably don’t have much of an interest in fancy tiles, so I imagine they will opt out and continue playing in ascii mode. It has me wondering though, do you know if they used TEXT/console mode or the standard 2D printing mode? The latter is technically tile-based already so a program capable of reading it should be expandable to include fancier tiles (though I imagine the layering would complicate things), while TEXT mode might be endangered if DF doesn’t make it natively to Linux and Mac post-Premium.

[PatrikLundell]

@voliol: I don't know what mode that person used, but I'd expect it to have been text, as any translation of tiles to audio would require someone to link "random" tiles to sound clips (or however that would be implemented) rather than use "standard" SW to read out the CP437 character under the cursor. I guess character recognition SW might work, but that's harder.
It might also be possible to link tiles to the characters they depict (and I'd guess Unicode or something similar would be required as soon as Toady starts to make use of the freedom from the CP437 cramped restrictions and introduce new tiles), and then use a DFHack Lua script to get the tile, then the translation, and feed that to the audio generation SW (somehow).

[Mr Crabman]

Do you have any plans to do something like procedurally generated languages/conlangs?

If so, what extent would this be going to/how far indepth would this be? Like, evolving/splitting over time between cultures, partial merging via loanwords or 2 cultures being in close proximity all the time, creatures not understanding some languages but "translators" or well-traveled ones being multi-lingual?

And for the contents of the languages themselves, would generating them involve low level details to make them seem natural/not generated, like this?:

Spoiler (click to show/hide)

- Choosing limited sets of possible consonants/vowels (phonetics)
- Languages having consonants/vowels that can't be pronounced by some species because of their vocal anatomy, or ending up with accents because of said anatomy
- Phonemes vs phones (sounds that are technically different but are interpreted as sounding the same by the speakers of a language)
- Tones
- Stress
- Allowed patterns of consonants and vowels in syllables
- Consonant assimilation (basically behind why the imp in "import" isn't as awkward as saying "inport" would be)
- Sound symbolism like the whole "kiki bouba" thing
- Grammar differences, including syllable counts per word in general, words consisting of other words combined, and some words not being "root words" in other languages in general (hypothetical example, you could imagine the word for "dead" just being the languages literal equivalent of "not-alive", not its own word)
- Etc etc

Just wondering how far this would go (if this stuff isn't planned already I'll definitely post a suggestion for it, along with some links to good sources people use for making conlangs).

The main thing it does to me is to underscore what a huge amount of work it would be to multithread DF. Each of those subsystems would have to be significantly revised.

Well, I may be mistaken, but I don't think all of them would need substantial revision (as most of the problem comes from a select few systems), and quite a few of them ARE being revised anyway in the big map rewrite, and others are slated to be revised later, so even if it's not done right away, if each system being rewritten is written with the potential of threading later in mind (so that it doesn't require a big rewrite when the time comes) that could be done at some point, assuming that doesn't sacrifice performance in the meantime, which I'm not sure it would.

Which by the way would slow the whole thing down on single processor systems.

Does anyone even use single processor systems anymore, and whatever tiny fraction does, how many will keep doing so as technology marches on and CPU's get more cores?

Using the GPU is even harder because you have to translate the code to shader language and figure out how to get good throughout, something the CPU kind of takes care of for you. Oh, and then you get bugs that only affect some graphics cards.

I agree, the GPU is a big step up in difficulty, which is why it would probably be best to get help with that if it was to be done at all.

When you’re done, it’s just the one system that’s now optimized…so one out of about a dozen listed in that article.

Sure, but only a handful of them really need optimizing, as a lot of performance issues seem to stem from a few bottlenecks; these "big ticket items" at the moment (maybe future updates will bring in new "big problems"), in no particular order of importance, are pathfinding, temperatures, fluid flow (in the forts that make use of fluids or have rivers/waterfalls), and whatever the problem is with the item vector (which I've heard is partially about temperature checks on each item).

[voliol]

@Mr_Crabman It's somewhere in the plans, yes. Below are the mentions of it I found earlier in this FotF thread.

[...]Will language be expanded on like music and such.  Being randomly generated and having to be taught/learned?   It be interesting to see if one language rises to the top of the heap to become that worlds version of 'common'   Or if the myth/history generate makes a single world language that was created by a god for the people to use.    Also maybe species with langagues that can't be spoken or understood by others do some some biological reasion.

[...]Yeah.  I'm not sure *when*, but I'm looking forward to it and it's an earlier non-DF interest of mine.

We're hoping to do a lot with language at some point, but it's always ended up being a lower priority compared to other features.  The notes are pretty extensive at this point, but that's meaningless if we don't work on it.

Have you seen the "Dwaven Language Codifier" here ? And if yes, what are your thoughts about it ?
(http://www.bay12forums.com/smf/index.php?topic=173289.0)

Yeah, I've seen it!  I think it's a cool project.
Since some of the analysis applies to all the languages (since they are underspecified but have a lot of similar characteristics), it's important to note that we're going to end up having to blow a lot of stuff up with procgen, if we can get it to work.  Though I've been wanting to do that for years and haven't had time.  And as with the myth stuff vs. the creature types etc., I really don't know precisely what 'default' is going to mean, or what sorts of vanilla language notions will remain intact.  Presumably, with the editor examples etc., there might even be a more and more fixed version of things.

[AliceRed]

You've mentioned plans for the siege rework before the big wait including ways for invaders to get through walls, like digging or breaking them down. Are there similar plans to make monsters like Giants or FBs have similar capability?

[Gtyx1]

1. Might be a Dumb question, but are pebbles only able to be formed from the specific materials listed in the stone layers or can pebbles be of any material so long as its stone? (I.E native copper, cinnabar, pyrite)


2. Regarding custom made companions:
A. Are companions created from the starting screen considered a separate faction or something? Im wondering because they're loyal to you specifically and will even turn on other companions if you attack them.

B. Also what do the "Respects you" "Highly Loyal" and "Loves You" traits do to your companions and how they act?

3. How wide is the scope of pets that can be spawned by divination dice? Because I've had pets spawn that weren't even Tameable creatures. Is it any creatures with the Large creature tag?  Could i theoretically roll until i get a Night Creature or Angel as a pet?

[leastannoyingman]

Have you considered enabling autosave and backups by default on the Steam version?

Relevant thread:
https://www.reddit.com/r/dwarffortress/comments/o4ob7q/ive_done_it_again_i_forgot_to_turn_autosaves_on/

[Mr Crabman]

1. For various syndrome tokens, I see in a lot of mods people create, that arguments/tags like `ABRUPT` and `PEAK`, and even `SIZE_DILUTES` are used, even in places where it doesn't appear to make intuitive sense, like `CE_ADD_TAG` for example, since it doesn't seem possible for the intensity of something like that to vary over time (and therefore to have a "peak", or to start "abruptly", or be "diluted by size").

Would these actually work in these cases (and if so, what do they do?), or is it just a matter of them being ignored by the token parser? Another way of asking I guess, is which of these "special" creature effect syndrome tokens actually make use of `ABRUPT`, `PEAK`, and `SIZE_DILUTES` (and for that matter, `SEV`)?: https://dwarffortresswiki.org/index.php/DF2014:Syndrome#Special_Effects

2. How would you handle the possibility/risk of making Steam achievements that later become obsolete or nonsensical/impossible to achieve due to design/mechanical changes in updates?

3. Do you think that, if the Bay12 forums become very saturated with new players, it may become a problem to continue FotF as you do now, and to handle reading the Suggestions forum? If so, what solutions would you have in mind? (for example, for suggestions might you make more subforums for different types of suggestion?)

4. Why are there only mammal and reptile werebeasts? Was this a design decision, or just about not having time or interest to manually hardcode loads of bird and insect werebeasts and instead waiting for them to be generatable?

5. How do you manage doing bugfix updates/patches for current versions, while still working on large changes that are not ready to be released to the public (that is, getting the bugfixes/patches in both the release, and in the unreleased version)? I only ask because I wonder how that's possible to practically manage without using a version control system or branches (assuming that hasn't changed).

6. Related to the last thing, how do you keep track of what changes you have made to the codebase and to features?

Have you considered enabling autosave and backups by default on the Steam version?

My guess would be that he'll enable autosave just because of the user friendliness of it (to avoid what happened in that thread), but probably not automatic backups, so as to encourage taking things as they come without rolling back whenever things start to go south (and also because they'd suck up the hard-drive space, which isn't what you want the default settings to do).

[leastannoyingman]

and also because they'd suck up the hard-drive space, which isn't what you want the default settings to do

An option to automatically delete old backups would come in handy then.