This is exactly what we do in our sound engine: create one "loader" thread
at startup, and queue load commands to it. We added some priority features
to the requests, so initially we feed it with a list of all in-game sounds
(and variants of each sound) we want to be loaded over time, it works in the
background, but we can request immediate loading of a given sound (for
example, GUI sounds when the user brings up the in-game menu). This sped up
our Level initialization times immensely.
Javier Arevalo
Pyro Studios
----- Original Message -----
From: "Jon Watte" <hp...@mi...>
> > doesnt, so i guess 2k also doesnt. We worked around it by creating a
> > threadpool and let them wait for a win32 event, and signal the
> > event as soon
> > as one of them needs to do something. Works like a champ, but it keeps
me
> > wondering.. Its really a shame this is so slow in win9x.
>
> In general, it's healthy design to treat threads as very heavy-weight,
> almost static resources, and not depend on creating them at run-time.
> Thus, creating a thread for doing asynchronous work for the sound system
> at construction time is a healthy design anyway. Queue commands to it
> using your favourite syncrhonization mechanism, and off you go; that's
> how most solid systems I've seen actually work. Un-solid sound code
> typically comes from not using a thread at all (leading to dependencies
> on frame rates, stuttering when loading, high latencies, etc) or from
> using too many threads within a single component.
|
