My $0.02 on this subject....
I agree completely that a lot of game developers will need a "core"
ogg decoder which has no dependencies on any standard library.
Ideally I'd like to see a separate file with the library functions
in it so I can rewrite them as needed.
eg. <file "oggstd.c">
double oggSin(double d)
{
return sin(d);
}
void* oggMalloc(size_t s)
{
return malloc(s);
}
The decoder would then call oggSin() instead of sin(), etc., and people
could patch it as needed.
If this is done then I'd also suggest making a pure decoder which
contains no code to read from files, just the existing callback
mechanism to provide the data (we still need to seek() though).
> The Vorbis code should then maybe strive to use as few external
> functions as possible to simplify this interface.
I haven't looked at it yet but I'm betting it wouldn't need more
than a dozen standard library functions for such a "core" decoder.
> If something like this isn't done, it's a case of hack the Vorbis
> source to make it compatible in our game, and that's a bad thing
> if we want to move forward easily (e.g. to Vorbis V2.0).
Precisely. I'm worried about learning/changing the ogg code because
any work I do will have to be re-done for each release of ogg.
Something like this needs to be done at the source, not by the
users of the library.
> I don't want to push this too hard anyway, I'm just trying to
> let you know how it looks from the perspective of one game developer.
I'm sure it's a common feeling among developers. I'm betting
that it wouldn't be difficult to implement a "core" decoder
which can be compiled seperately from the main lib, but I don't
have the time to do/redo it (it's not the actual coding, it's
learning to navigate the source code which takes time).
Having the "core" in a separate .lib with the main libvorbis
providing oggSin(), oggMalloc(), etc. for normal usage would
probably be a good way to go for *everybody* who uses ogg.
It would also separate out the code which needs most optimizing
(the decoder) from the rest of the library and this would make
it easier for people to work on it.
I has to be a Good Thing, and I bet it wouldn't take too long
for somebody who knows their way around the code to do it.
--------------------
Also:
Somebody mentioned that the decoder takes 500k per instance.
Is this true? I'm thinking of using ogg in a game where I can
easily have five or six tracks playing at the same time, this
could be a problem....
Again, if the decoder was a separate "core" then it would be
easier to work on things like this - less source code for people
like me to navigate.
--
<\___/>
/ O O \
\_____/ FTB. http://www.artlum.com
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
