Print

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

[idgarad]

Actually it was to reduce the table of objects to allow for merge operations. Contiguous blocks can be merged in the table and only need to be broken out at mining time.


E.g.


ABC
EAA
AAA

Can be reduced to two A blocks in the index. Even if you want to keep them square you go from 6 A blocks to 3 A blocks. By not retaining any intrinsic data beyond a loot table you could reduce the data for a single block down to maybe 2 bytes total along with saving in merges. The thing that kills dwarf fortress is the number of distinct objects in memory and lookup times. I have a few threads on ways to trim and clean up the number of tracked objects. This would provide some low level optimizations that can be leveraged later in reducing the number of objects. Every object is a potential pathing node if not occluded and even swapping out occluded terrain blocks still means we need to keep the exposed blocks in a list (i.e. walls) A single width hallway 10 blocks in length has 20 blocks not counting the ceiling\floor of the hallway. If all of them Granite with merge you get two grantite{1x10} objects if you do a merge optimization. Otherwise you have 20 distinct granite objects. Even if the merge objects need 5 bytes each you still have a 50% reduction in objects memory footprint. By using a loot table then you no longer have to track granite and then the gems and ores you may find in the granite.

Back to 10 square length hall

AAAAABBABB

AABBAAAABA

Assuming B's are gems with a merge optimzation you don't gain a lot You get:

(A*5)(B*2)(A)(B*2)

(A*2)(B*2)(A*4)(B)(A)

so you go from 2 distinct blocks to 9 distinct objects. But if the merge blocks say take 5 bytes compared to 1 bytes we go from 20 bytes to 33 bytes (we got worse, not better).

If we use the loot table we get just 2 merge objects at 10 bytes

AAAAAAAAAA

AAAAAAAAAA

Since the gems and ores are no longer distinct.

That was the main impulse in the suggestion. That way if we have to brute force or walk an array the merged objects represent an improvement in the number of iterations that need to be ran, this is valid at run time AND during things like worldgen as best as I can guess on how things are coded.


Now given a 40x40 region at 128 layers this may provide some benefits coupled with object management (furnace, vaults, etc.)

[Sowelu]

Unmined stone isn't an object, and it doesn't have any of the associated tracking difficulties or slowdown issues at all.  Plus, if you think that using RLE to compress the map during play will make the game faster, you need to go back to your computer science courses :/

If you want something fast, you don't compress it.  You'd have to uncompress it every single time you needed to touch it, which is all pathfinding etc.  Also, it totally prevents you from tracking things like the temperature of a given tile.

[idgarad]

Unmined stone isn't an object, and it doesn't have any of the associated tracking difficulties or slowdown issues at all.  Plus, if you think that using RLE to compress the map during play will make the game faster, you need to go back to your computer science courses :/

If you want something fast, you don't compress it.  You'd have to uncompress it every single time you needed to touch it, which is all pathfinding etc.  Also, it totally prevents you from tracking things like the temperature of a given tile.

It has to be an object in a table, the memory footprint scales linear with embark size as far as I can tell. Try a 3x3, then a 4x4, and a 5x5.

[Sowelu]

And?  Yes, it's huge.  Modern computers have at least a gig of RAM.  6x6 embark tiles is going to be around (48*48)*(6*6)*(100).  That's 8,294,400 tiles.  Whoopee, big!  Each one has...Okay, let's say there's two bytes for material type, two bytes for temperature, one byte for natural shape (unmined, partially mined, up-ramp, fortification, etc etc)...Aw hell, let's just say 20 bytes.  The dfhack people would know.  Constructions, flows, etc are not stored in this table (well maybe flows are).  Which gives us...oh about 170 MB of RAM.

So?

If you implement RLE or something like it, you are going totally, utterly cripple the FPS whenever that compressed area needs to be referenced.  You'll need a second table to keep track of what's compressed and what isn't.  And really, taking up more RAM doesn't make it slower (it's way beyond the point of hardware caching, after all).  Having a couple hundred megs lying around in a big array isn't too bad, all things considered.

They're not object in a table, anyway.  They're an array of structs (semantics...).

Also, what happens when new stuff needs to be stored for unmined stone, en masse?  Like, what if suddenly it started tracking material stress for caveins.  Or, let's say...occupancy flags.  Ghosts can pass through walls, right?  I bet they set the occupancy flags no matter where they are, so that part of the struct needs random-access all the time.

I guess you could just separate out the stone type, pull it out of that data structure, and leave the rest of the struct intact.  You'd be pulling out like two bytes per tile--saving 16 megs on a 6x6 embark--and storing it into, well, something else.  Worth it?  Nah...Especially since you'd need to decompress a chunk of that data just about every single time the screen refreshes.

So...I'm thinking the gain would be unnoticeable, the losses in FPS and extensibility would be large, and it would overall be more trouble than it's worth.

[Draco18s]

And correcting myself, it won't save FPS. Reading it from the semi-random number reservoir shouldn't be very different from reading it from memory.

Reading from RAND isn't faster than reading from RAM.  Except that it uses less RAM.

[Granite26]

Wouldn't dig order matter in most implementions?

[Draco18s]

Wouldn't dig order matter in most implementions?

Yes, but does it matter?

[Granite26]

Wouldn't dig order matter in most implementions?

Yes, but does it matter?

Can I say yes without us getting into a big long thing about determinism in games?

Also,  what about npc fort exports?

Why am I even encouraging this topic?

[Draco18s]

Wouldn't dig order matter in most implementions?

Yes, but does it matter?

Can I say yes without us getting into a big long thing about determinism in games?

What I mean is: if you use your RNG string in the order that tiles are dug, it doesn't matter which tile is dug and where that ore drops, except in very extreme circumstances (channeling into magma dropping a stone of platinum, for instance).

[Granite26]

But different stone types have different drop charts.

[Draco18s]

But different stone types have different drop charts.

Ah yes.
In any case, I was never "for" this idea anyway.

[ikkonoishi]

For metals you can kind of fake it now with a reactions. Make a few mineral types that have "traces" of metal in them, and a new type of misc item "scraps".  You can then create a reaction to turn the trace minerals into metal scraps which can then be melted down to metal bars. It costs much more fuel, and smelter time to get metal this way, but it is completely non random.

You could require some sort of acid to do this, and have a naturally boiling syndrome causing byproduct if you wanted to.

[Silverionmox]

But the merit of the suggestion is that you have have spatially varying ore content in the same rock: the center of a magnetite cluster would be much more ore-rich than the edges, and the surrounding rock would yield a little ore too.

[Draco18s]

But the merit of the suggestion is that you have have spatially varying ore content in the same rock: the center of a magnetite cluster would be much more ore-rich than the edges, and the surrounding rock would yield a little ore too.

Except that this doesn't do that.  The non-cluster rock has an equal chance to drop the iron ore over the whole layer.  Distance from an ore vein would have no bearing.

[Granite26]

But the merit of the suggestion is that you have have spatially varying ore content in the same rock: the center of a magnetite cluster would be much more ore-rich than the edges, and the surrounding rock would yield a little ore too.

< 1 ore per square is ok, but this is a ludicrous way to do it