[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Future direction of PenguinPlay
Bjarke Hammersholt Roune wrote:
>That's nice, right, but it would slow things down noticeably. If we assume
>we do a good job implementing codecs for many file formats, PFile would
>have to look for the existence of
>which is useless 99.999% of the time because game programmers usually know
>what format they've saved their gfx in.
>And it doesn't work for "nonstandard" file formats, e.g. formats designed
>by the game developer to exactly fit the specific needs.
Part of PenguinSound is the loading of different sample formats.
Heres the architechure I used.
First there is a abstract class - the sample interface - called ppsSample .
This defines the different operations necessary for the samples.
Then based on the ppsSample I have created ppsSampleAu, ppsSampleIff etc
for each of the different formats. If you have a specific format that you
load say a Sun Au file, then you'd just do:
I haven't yet modified the code so that it uses PFile.
If you don't know what format the file is the you'd do:
ppsSample* sample = ppsSample::LoadByFactory(filename);
The factory checks the file creates an instance of the class for that
loads it and returns a pointer to the object.
LoadByFactory uses the ppsRegistryFactory class. This class is simply a
for the Factories that create the proper class. Its also a singleton. Only
one can be created.
To get an instance of the ppsRegistryFactory you call Instance. This means
that the user can
modify the behaviour of LoadByFactory. At the moment for samples the
criteria for creating the
different classes is based on the filename extension. If a user wants to
remove half the Factories
from the ppsRegistryFactory then they can do it. If they want to add some
more or add their own
they can do that too.
If you do things right then you can make things easy to use with out taking
any power away.