Re: Future direction of PenguinPlay

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

>However, I also think we should do something else aswell: Create a
>standardised interface.
>
>What I mean by this is that A) all projects in PPlay should follow the same
>paradigm of interface design B) if something is done in one way in one
>place, then it should be done in the same way everywhere else C) programmers
>using PPlay should never have to know what library is used to implement the
>PPlay interface they are using.

Forget it.
Sorry, but do you know what you're talking about? Just have a look at 3D
stuff:

* OpenGL (low level)
* CrystalSpace indoor (portal based highlevel)
* CrystalSpace outdoor (something else highlevel)
* OtherEngine space (highlevel space engine)
* JGL (primitive based mid-level)

You won't be able to create a useable interface covering just two of them.
Either such an interface would be thrice as complex as neccessary or it
would only permit the use of 25% of the functionality of each lib.

You'd end up writing a wrapper for each of the contained libs, and you'd
perhaps manage to make all those wrappers have a somehow similar feel. But
those wrappers will add instability (they require additional testing), they
won't always support the newest features of the underlying libs and it
would be a huge (!!) amount of work to maintain them.

>Imagine a 2D program (like Penguin2D) wanting to load a file with graphics.
>It might then request this file from PenguinFile, specifying only the
>filename (not the extension) and what kind of data it wants (graphics), and
>in what format it wants it.
>
>PenguinFile would then solve this request by looking up the file, and
>assuming that the file existed, it would then check that the file actually
>did contain the type of data requested (atleast in debug builds). If the
>format requested matched the format of the file, then all PFile would need
>to do was to plug-in the file to a stream and pass this stream back to the
>2D program (or perhaps plug-in the providing end of a passed-in stream).

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

Image.pnm
Image.pbm
Image.pgm
Image.png
Image.jpg
Image.jpeg
Image.bmp
Image.pcx
Image.lbm
Image.gif
Image.tif
Image.tiff
Image.tga
Image.xpm 

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.

>Another thing could be threads: it would be VERY uncool having two different
>ways to do threading. All parts of PenguinPlay should use the same threading
>scheme, regardless of how its implemented.

Well, it doesn't matter how the libs do threading internally as long as no
conflicts occur. And if some lib uses an unusual threading way, causing
conflicts, then it's PenguinPlay's job to tell the lib's developers "Hey,
your lib is unable to coexist with others, you'd better fix that bug"

But that's it.


	Christian
--

Drive A: not responding...Formatting C: instead