Game Development Reference
In-Depth Information
class iAttribute
{
public:
virtual
˜iAttribute()=0;
virtual type_info
GetTypeID()
const =0;
virtual const std::string&
GetName()
const =0;
};
template<typename _tAttribute>
class cAttribute : public iAttribute
{
public:
cAttribute(): m_name(), m_pData(NULL) {}
˜cAttribute()
{ if (m_pData) delete m_pData; }
type_info
GetTypeID()
const { return typeid(_tAttribute); }
const std::string& GetName()
const { return
m_name; }
_tAttribute*
GetPointer()
{ return
m_pData; }
private:
std::string
m_name;
_tAttribute*
m_pData;
};
Listing 1.2. Attribute classes.
this occurs the engine can start one or more threads and from these execute any
update loops that the aspects may require. It is here that any aspect precedence
should be resolved; correct functioning of the engine may be dependent on the
order of updates, and there will usually be an optimal order and frequency with
which aspects should be updated.
1.7.1
Aspect Update
As each aspect is autonomous, being in effect a vertical slice of engine functional-
ity,eachhasitsownupdateloopperforming all the operations needed to manage
both the core scene and its own internal resources in respect to its subset of
functionality ( Figure 1.9 ).
When it is time for the aspect to update, it must acquire a lock on the core of
the engine, then process any new events that have occurred since the last update,
parsing subgraphs that have been added to the scene or removing aspects for
nodes that will soon be deleted. It will also need to synchronize the values in its
own internal objects with those of the corresponding scene nodes before releasing
the lock. At this point the aspect is potentially updating in parallel with the
rest of the engine, performing any internal logic. Once its internal state is fully
updated, the aspect reacquires the lock upon the core of the engine, synchronizes
the core entities with any relevant data, and generates new events before again
 
 
Search Nedrilad ::




Custom Search