Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 270 271 [272] 273 274 ... 284

Author Topic: Future of the Fortress  (Read 1603126 times)

Mr_Crabman

  • Bay Watcher
  • A person with the head and pincers of a crab.
    • View Profile
Re: Future of the Fortress
« Reply #4065 on: June 18, 2021, 11:16:40 am »

It can also be noted that multiple threads don't speed things up if the calculations are bound by the rate at which data can be brought in from memory, and I believe there are indications DF is memory bound rather than CPU bound.

Maybe so, though I've heard some mention of people measuring cache misses with external software and there not really being a whole lot many from DF, and I myself have noticed the core running DF is often at 100% (as have others), so it's CPU bound at least some of the time, to some extent. Incidentally, threading also means a bit more cache memory anyway, since L1 and L2 are locked to individual cores (so you get more slightly more fast memory to work with), and so you can work on expensive calculations with smaller amounts of data, while other threads are waiting for their large amounts of data to come in.

And while I'm no expert on the matter, it seems like if you could keep as much data in the VRAM as possible (minimizing the transfer back and forth between it and the regular RAM), then that may free up more cache and memory bandwidth for other calculations in the CPU at the same time (aside from the insane parallel power of the GPU of course).
Logged

DwarfStar

  • Bay Watcher
    • View Profile
Re: Future of the Fortress
« Reply #4066 on: June 18, 2021, 02:37:58 pm »

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.
Logged

Mr_Crabman

  • Bay Watcher
  • A person with the head and pincers of a crab.
    • View Profile
Re: Future of the Fortress
« Reply #4067 on: June 18, 2021, 05:00:05 pm »

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)
Logged

DwarfStar

  • Bay Watcher
    • View Profile
Re: Future of the Fortress
« Reply #4068 on: June 18, 2021, 08:48:39 pm »

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.
Logged

Schmaven

  • Bay Watcher
  • Abiding
    • View Profile
Re: Future of the Fortress
« Reply #4069 on: June 18, 2021, 11:43:28 pm »

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. 
Logged

PatrikLundell

  • Bay Watcher
    • View Profile
Re: Future of the Fortress
« Reply #4070 on: June 19, 2021, 03:20:24 am »


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?
Logged

Bumber

  • Bay Watcher
  • REMOVE KOBOLD
    • View Profile
Re: Future of the Fortress
« Reply #4071 on: June 21, 2021, 01:36:04 am »

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.
« Last Edit: June 21, 2021, 01:52:36 am by Bumber »
Logged
Reading his name would trigger it. Thinking of him would trigger it. No other circumstances would trigger it- it was strictly related to the concept of Bill Clinton entering the conscious mind.

THE xTROLL FUR SOCKx RUSE WAS A........... DISTACTION        the carp HAVE the wagon

A wizard has turned you into a wagon. This was inevitable (Y/y)?

voliol

  • Bay Watcher
    • View Profile
Re: Future of the Fortress
« Reply #4072 on: June 21, 2021, 03:09:46 am »


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

  • Bay Watcher
    • View Profile
Re: Future of the Fortress
« Reply #4073 on: June 21, 2021, 06:56:27 am »

@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).
Logged

Mr_Crabman

  • Bay Watcher
  • A person with the head and pincers of a crab.
    • View Profile
Re: Future of the Fortress
« Reply #4074 on: June 21, 2021, 02:49:45 pm »

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)

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).
Logged

voliol

  • Bay Watcher
    • View Profile
Re: Future of the Fortress
« Reply #4075 on: June 21, 2021, 03:44:20 pm »

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

Quote from: FotF May/June 2018
Quote
[...]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.
Quote from: FotF November 2018
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.
Quote from: FotF September 2019
Quote
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

  • Bay Watcher
    • View Profile
Re: Future of the Fortress
« Reply #4076 on: June 22, 2021, 12:01:16 am »

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?
Logged

Gtyx1

  • Escaped Lunatic
    • View Profile
Re: Future of the Fortress
« Reply #4077 on: June 23, 2021, 03:10:03 am »

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?

Logged

leastannoyingman

  • Bay Watcher
    • View Profile
Re: Future of the Fortress
« Reply #4078 on: June 23, 2021, 05:50:14 am »

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/
Logged

Mr_Crabman

  • Bay Watcher
  • A person with the head and pincers of a crab.
    • View Profile
Re: Future of the Fortress
« Reply #4079 on: June 23, 2021, 06:41:18 am »

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).
« Last Edit: July 01, 2021, 02:23:33 am by Mr_Crabman »
Logged
Pages: 1 ... 270 271 [272] 273 274 ... 284