Game Development Reference
In-Depth Information
}
}
Succeed();
}
This process is meant to loop forever in the background, ready for new decompres-
sion requests to come in from the Event Manager. Once the decompression request
comes in, the method initializes a
ZipFile
class, exactly as you saw in Chapter 8,
“
”
After the resource has been decompressed, an event is constructed that contains the
progress (100%), the Zip file name, the resource name, and the buffer. It is sent to
the Event Manager with
VThreadSafeQueueEvent()
method.
The event can be handled by any delegate in the usual way.
Loading and Caching Game Data.
const EvtData_Decompression_Progress & castEvent =
static_cast< const EvtData_Decompression_Progress & >( event );
if (castEvent.m_buffer != NULL)
{
const void *buffer = castEvent.m_buffer;
// do something with the buffer!!!!
}
Note that I
m bending one of my own rules here by allowing a pointer to sit in an
event. The only reason that I can sleep at night is that I know that this particular
event won
'
t ever be serialized, so the pointer will always be good. I also know that
this process doesn
'
t have an exit condition and will happily sit in the
while (1)
as
long as the game is running. If this keeps you up at night, you could implement a
new event that would shut down the process cleanly.
'
One improvement you could make to the real-time event processor is to double-
buffer the events, just as the regular event queue does. This would help protect the
real-time event queue from being spammed by a misbehaving event sender.
Decompressing a data stream is a good example, but there are plenty of other tasks
you could use this system for if you had a spare weekend. These include rendering,
physics, AI tasks such as pathfinding, and others.
Rendering is probably the most common subsystem besides audio that is run in a
separate thread. It is already highly compartmentalized, especially if you use the
architecture in this topic. Much of the rendering pipeline prepares data that is sent
