[Coding #1291] Containers

[Andrea B Previtera]

I've solved this one already, but just out of curiosity: how are Exult containers structured? Since I thought of containers too late into the development, I had to invent something of a "hack" which I am not too happy with, but which seems to work just fine.

I've got a global list of containers, each one linked to a unique item in the world (so actually anything may be a container, even a tree or a chimney). Upon activation of an item, this list is checked and if a container links to that, it's opened etc. etc.

But, again, how does it work in Exult?

[wjp]

The container class is a subclass of the item class.

[eaterofspleens]

Bah, all this object-oriented stuff is just there to confuse people...

[Gradilla Dragon]

No, object-oriented stuff is the other way around. Even non-programmers can program in object-oriented languages. I guess you just don't get it.

[Andrea B Previtera]

In terms of pure data, each unique world item is a record of three bytes for the x,y,z position relatively to the tile it's linked to (my tiles are large, more or less the size of an exult's chunk), another byte for the rotation on the Y axis, and an word id which identifies which kind of item is it.

Now, this makes for 3+1+2 = 6 bytes for each item. It's a huge world made up of 512x512 tiles, and average of 10 items per tile seems plausible. This means 60 bytes per tile, 512x512x60 = 15 mb for the whole world map.

If each one of those items could potentially be a container (and thusly owning a list of the contained items), that would mean that I should add at least a pointer (4 more bytes) to the item structure. Quite a large increase! Since the U7/Exult world map still seems to be so small in terms of memory occupation, I still wonder how it works...

Of course I get that much is solved by the fact that the chunk structure allows for defining with a couple bytes a large collection of "items", but I don't like it too much.

[Tristan de Inés]

Most items in U7 are concentrated in cities and special locations. If you think about how many item-empty chunks there are in U7 (forests, water, streets, swamps) I really think it would come down to 2 or 3 items per chunk.

I'm talking about "real", movable items, of course, and not the ones "stickied" onto a chunk.

Maybe every chunk on the U7 map has a linked list of items on that chunk. That would seem a plausible way of doing it.

[Andrea B Previtera]

That's for sure. I don't use chunks, and my solution is exactly that: a linked list of items for that chunk. I am talking about the containers, which is quite a detached problem.

[wjp]

Each item already takes up dozens of bytes of storage in Exult (location, type, frame, quality/quantity, linked list pointers, rendering order dependencies, misc. other stuff). A single vtable pointer per item doesn't really cost all that much, and is easily worth it to get access to virtual functions, in my opinion.


Note that in your case items also cost more than 6 bytes/item if you're storing them in a linked list. (The 'next' and possibly 'prev' pointers.)

[Andrea B Previtera]

Definitely. So it's how I supposed... all the saving is in the Chunks. Sigh, too late to think again about those and - also - I like the freedom of just dragging stuff a sticking it into the world