Ok, ok, stupid idea!

["Bjarke Hammersholt Roune" <asmild@post6.tele.dk>]

>>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:
>
I haven't ever needed to program anything 3D.

I guess that means the only way to get a proper interface that works for
everything is to write everything from scratch, which is highly infeasable.

I'm wondering exactly what the P2D, P3D, PSound etc. projects will do then?
I mean, the people already working at the libs we're going to use probably
is alot more qualified than any of us to program *their* lib.

>>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
>[...]

>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.
>
There are work-arounds for all of these problems. Atleast if the file is
contained in a pak file:

Store the prefix independently of the rest of the filename, perhaps not as a
string but as a number.

This works perfectly for "nonstandard" file formats: anyone would be able
register more file types and filters with the "conversion-engine".

In many cases, in large projects, the programmer actually doesn't know what
format a file is in, and in any case, its really not something he should be
bothered with; that's the artists' area. If an artist wants to add some
graphics to the game, or just alter/update something, he shouldn't have to
ask a programmer to revise the source code to get the program to recognise
his file, just because it isn't in the format the programmer who did the IO
thougth it should be.

Other parts of the development team should be able to do as much as possible
without the programmers having to getting involved. This makes things move
along alot more smoothly (or so I've read :). The important thing is that
the file contains a piece of graphic, not what format it happends to be
stored in.

However, this is all largely inconsequential. If PPlay itself doesn't use
the feature (which would require a common way of doing streaming between all
libs), it's not worth implementing.

I read about this feature somewhere on Gamasutra. It was utilised by the
team behind Thief and Magic Carpet, which used the same engine for both.