(Created page with "ENIGMA's most fundamental locals are stored in tiers for ease of access. Since tiers are linear (each inheriting from the last), they are not easily swapped out, ...")
Newer edit →
Revision as of 04:35, 23 November 2010
ENIGMA's most fundamental locals are stored in tiers for ease of access. Since tiers are linear (each inheriting from the last), they are not easily swapped out, and so for modular groups of locals, a different system must be used.
A typical component system uses pointers for accessing such groups. In ENIGMA, this would lead to messy, wasteful accessor functions. Instead, since ENIGMA dynamically generates much of the code used in the engine, it makes sense that it should assemble and locate components in the scope of the parent object class.
This will be done by reading lists of related locals, assembling them into a structure, then copying the content of that structure into the parent object. From there, a macro similar to offsetof() is used to get the location of the first member from that group in the parent, and that number is treated as an array block to be ignored when casting for locals.
For example, if a function needed to access
lives, it would depend on the package "Typical Status Locals". When ENIGMA read that package, it would generate a structure containing
int health, score, lives;, instantiating the three of them in the parent class as well. It would then store a global variable
typical_status_locals_offset containing e_offsetof(health), which would be instantiated in an accessor struct like this:
int health, score, lives;
lives could be accessed simply by casting the global instance iterator's current instance to
typical_status_locals_access* and accessing it there.