Its been a while since my last journal entry, since I haven't been working on my project for a while. I didnt have any internet access for nearly a month (I cried every night) and I've been settling into a new house and university term.

I did do a little work in the last 3 weeks. I now have command line utilities to compile the .ac file into a Poly Forest file, and a brush file of a similar format. The brush file format will be used for both static geometry that is repeated, and dynamic objects that can be picked up and, for example, used to beat zombies about the head.

During my absence, I also did a little work towards another area of the game engine. In order to manage loading resources, I've implemented a "shopping list" system. This system manages the dependency between resources. For example, a mesh of a bus may use several meshes, including the wheel mesh. A truck may also have the same wheels and therefore use the same mesh. The shopping list would know that two objects are using the wheel mesh, and then load it with a user count of 2. If the bus is then unloaded, the use count will be decremented by one.

Furthermore, the wheel mesh is likely to require the wheel material, and may share this material with another kind of wheel, e.g. on a car. The user count for the wheel material will be 2, since 2 seperate meshes use the same material.

This continues down the heirarchy, as a material will consist of some shaders and textures which in turn may be used by more than one material.

The point of the "shopping list" analogy is that an "order" is constructed every time a new section of the level is loaded. Imagine that you are writing a menu, and three of the items are:
Tiri Misu,
Bacon and Eggs,
BLT sandwich.

There are
2 counts of egg,
1 count of mascarpone,
1 count of sugar,
2 counts of bacon,
1 count of bread,
etc...

By writing a list of the requirements of each item, we can formulate a single list of the ingredients and the amount required.

This can be done with the aid of the following class:
< std::cout< }

private:
EResourceType type;
std::string name;
int change;
friend class ShoppingList;
};

class ShoppingList
{
public:
void addEntry(ShoppingListEntry& newentry)
{
std::vector::iterator index;
for(index = items.begin(); index != items.end(); ++index)
{
if(index->name==newentry.name && index->type==newentry.type)
{
index->change += newentry.change;
return;
}
}
items.push_back(newentry);
}

void dumpToConsole()
{
unsigned int index=0,end=items.size();
for(index; index!=end; ++index)
{
std::cout<<"Entry #"< items[index].DumpToConsole();
}
std::cout< }

void ShoppingList::extract(EResourceType t, ShoppingList& subset);
std::vector items;
private:

};
}
#endif






With the aid of this class, I can streamline the loading and unloading of resources as I need to. As yet I have not finalised the resource manager, but it will take items at the top of the heirarchy (vehicle, brush, actor) and load those. The seperate loader classes will then return a new shopping list, which is concatenated and the next level on the heirarchy (material) will be loaded. This continues until all resources have been loaded, with the correct usage counts.

Any resource that is no longer needed can be removed from GPU ram, or otherwise sidelined, and marked for death. If it is needed again shortly (which is likely, e.g. if a player goes 128m in one direction then doubles back) it is already loaded from disk, and needs only to be copied back into video memory, thus reducing HDD bandwidth. The criteria on which these are then removed from system memory I have not decided, but I have several ideas.

Task for tomorrow:

By tomorrow I hope to have the ability to spawn a physics object, and process the resulting "shopping list".