Game Development Reference
In-Depth Information
in a debugger to determine where the compiler decided to place the virtual table
pointer.
By replacing each virtual table pointer with an ID of the type of object, the
loader can walk each loaded object and determine the type required. This solves
both the issue with the virtual-table along with any issues without knowing what
data have been serialized to the file. On load, a lookup table can be used to convert
these IDs back to virtual table pointers.
7.4.3 Platform-Specific Issues
If the tool chain and target platform are not the same, the serialized memory image
may not match the target platform. Once again, because data are crafted specifi-
cally for the current build on a specific platform, these issues can be handled while
saving. Although this may cost performance while saving the file, most transfor-
mations on the data will be transparent compared to other operations. Common
sources of issues are endian ordering and alignment requirements.
For endian
2
correctness, a second pass can be made on all of the data to switch
the endian ordering of each field. Endian ordering is a known value at compile time,
so the change should be simple to predict and implement.
To deal with different alignment requirements, the tool must be able to com-
pletely mimic the target platform. If the final system requires specific alignment
or padding rules, the tool must adhere to the same rules in memory. Any quirk or
requirement needed by the compiler on platform must be completely reproduced
by the tool-side code. This can be done via compiler directives to ensure that data
are in the right place inside an object.
7.4.4 Runtime Functionality
To load up an object in the disk image conversion process, the code for that object
needs to be compiled into the tool. In some cases, runtime code cannot be functional
in a tool. This may be because the code depends on libraries that are not available
at compile time. This can be solved a number of different ways.
From an implementation point of view, the easiest way to solve this problem is
to separate data from functionality. Serialized objects should be only represented
as plain old data. The objects can contain methods, but those methods should
only deal with the internal state of the object and should be cross-platform. For
in-game functionality, the code needs to reside in an external object that is not
serialized from disk. This significantly simplifies the tool code, and it can also lead
to a cleaner, more-understandable code base.
Often, this is not possible. When an object needs to reference code that will not
work in the tool, preprocessor macros can be used to form compatible, but different
2
Depending on the platform, the order in which numbers are represented varies. For example,
x86 and related platforms are little-endian while PowerPC architectures are big-endian.
