DT: Reclaiming Memory

Development
1

Konis1-848x445.png848Ă—445 469 KB

http://stonehearth.net/dt-reclaiming-memory/

8 Likes
2

First \o/

Thanks for DT and memory improvments :smiley:

3

That must be a horribly painstaking process, looking through all the code and changing things without breaking everything. Good work @yshan, 10% is awesome!

3 Likes
4

Hey, Hey , hey… Whomever in the video that was playing “3DTree-tris” they are cheating! They are not allowed to destroy individual trees with dev tools! :stuck_out_tongue: (so kidding).
Cool stuff! And ty for your work :peace:

2 Likes
5

that is one freaking nice town :slight_smile:

1 Like
6

Hi! Very interesting blog post! It’s always fun to learn more about the intricacies of game development :slight_smile:

I have a question though, you mention moving certain attributes to “read only memory” to speed up access times, but what does that mean? I haven’t heard of this being possible in code before and I’d love to learn more

7

I’m not sure I understand the read only memory thing either, but I can sort of guess.

I suspect they mean that they save all the unchanging bits of an item as constants in a globally accessible definition. To instantiate an instance of that object, you would then only have to define the changeable bits of the object and include a pointer to the unchanging bits.

This would reduce the memory footprint to something on the order of (x+1)n + y instead of (x+y)*n, which gets to be quite considerable when x (the changing bits) is small and y (the unchanging bits) and n (the number of objects) are large.

4 Likes
8

That is possible, if the unchanging bits are identical across all objects (or a subsection of all objects), but that sounds more like what they describe further down as

The model variant component, which stores the appearance of an object, is now just stored once for all objects of a type.

Where they don’t mention read only memory.

I don’t mean to nitpick, so I’m not trying to complain about their wording, I just want to know if there’s something new here that I don’t know about :slight_smile:

9

I think the whole reference to “read only memory” is kinda confusing for layman.
It does not really refer any thing specific to memory or whether it is read-only or not.

Let’s take a slightly different approach to what @Tuhalu has described, using simple example (I find that using example is a lot easier to explain things to non-experts)

All the data entities in the game are modeled by a bunch of properties.
now, imagine that there are 10,000 blocks of wood that we need to store.

A naive way is to store 10,000 of the data represented below:

// note: all data are fake.
// the following is the properties for a block of wood
aBlockOfWood = {
    type        : "entity/resource/wood",
    name        : "wood log",
    description : "a log of wood",
    icon        : "some/path/to/wood/icon.png",
    model       : { ... 3d data for a block of wood ... },
    weight      : 10,
    value       : 1,
    pos         : (100,200,300)
}

it means that we need to store 10,000 x the space required for name, description, icon, model etc…

But, a lot of the properties are actually the same for all blocks of wood entity, and do not change at all.

So instead of storing above 10,000 times, we take out the common parts which never changed (hence “read-only”), and only store it once. Then for all the rest of the entities, we make them reference this copy.

// this is only stored once.
wood_data = {
    type        : "entity/resource/wood",
    name        : "wood log",
    description : "a log of wood",
    icon        : "some/path/to/wood/icon.png",
    model       : { ... 3d data for a block of wood ... },
    weight      : 10,
    value       : 1,
}

// this is stored 10,000 times 
aBlockOfWood = {
    entity_data : wood_data,     // references the same copy of data above
    pos         : (100,200,300) // this must be stored once per entity because it is different for each one
}

Hence there will be a reduction in the memory used (as what Tuhalu’s post mentioned)

6 Likes
10

Yes, I understood what Tuhalu meant. I’m sorry if it was not obvious in my comment, but I am actually a programmer :slight_smile: I kinda felt the reference to read-only memory was more confusing to a non-layman, but that might be because I’m far too literal :stuck_out_tongue:

11

lol ok. Guess my earlier post was not required :slight_smile:

Yea. I think both the use “read-only” and “memory” can cause confusions. partly because “read-only memory” has a totally different meaning, and partly because the “memory” here actually refers to the stored data. I think “memory” was used because it was used in the title. The difference would not matter to non-programmers anyway.

“read only” however, could have more reasons in the context on a component based entity framework, which stonehearth may be using. (just a guess)

A simple way to use shared components in such a framework is to logically categorize them as “read-only”. (strictly not all shared components are “read-only”, but a “read-only” component can definitely be shared). This also has the possible advantage of systems processing a shared aspect being able to cache some results (cutting some computational costs as well), as opposed to having to process the same thing over and over again for each entity type. “Read-only” here, will be a useful design annotation.

come to think of it, “read-only” is probably “strange” when it gets joint with “memory”. at least to me :wink: