Page 1 of 1
[Coding #1291] Containers
Posted: Wed Feb 02, 2005 9:48 am
by 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?
Re: [Coding #1291] Containers
Posted: Wed Feb 02, 2005 10:05 am
by wjp
The container class is a subclass of the item class.
Re: [Coding #1291] Containers
Posted: Wed Feb 02, 2005 10:48 am
by eaterofspleens
Bah, all this object-oriented stuff is just there to confuse people...
Re: [Coding #1291] Containers
Posted: Wed Feb 02, 2005 4:27 pm
by 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.
Re: [Coding #1291] Containers
Posted: Thu Feb 03, 2005 12:18 am
by 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.
Re: [Coding #1291] Containers
Posted: Thu Feb 03, 2005 5:06 am
by 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.
Re: [Coding #1291] Containers
Posted: Thu Feb 03, 2005 8:05 am
by 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.
Re: [Coding #1291] Containers
Posted: Thu Feb 03, 2005 8:57 am
by 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.)
Re: [Coding #1291] Containers
Posted: Fri Feb 04, 2005 12:59 am
by 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