Today I started bringing on .ogg support in DirectQ, and I guess that you've probably guessed the end result by now. It's not going to happen for the foreseeable future.
Let me explain a bit here.
I've already excluded the traditional route of adding the 4 (or whatever) DLLs to the distribution - things are already enough of a mess with other source ports doing the same, and using conflicting DLL versions; I'm not going to make things worse. The same applies to anything else distributed in this manner.
Next I looked at stb_vorbis. On paper it looks just the ticket. A single .h file that you drop into your project, make some function calls, and everything happens automatically. Or rather, it doesn't, because you still have to interface it with a sound API, write your own streaming code, etc, and even then it fails to load the sample files from the Vorbis website.
On to FFMPEG. This is a close second-best, being a bunch of static .libs (the Windows distribution even comes with .ogg pre-compiled in) but the API is horrible and besides - the header files are set up for UNIX and don't work with Visual Studio.The option of pulling something together from the Doom 3 source was considered. Sure it would bloat the executable and source code distributions, but something that works should be possible. You'd also need to include all of the idLib stuff and write some public interfaces of your own.At this point I stopped.
To quote from something someone else once said a long time ago in a galaxy far far away:
"I have better things to do with my time."
Is it that bad, really? As far as I'm concerned right now, yes. This is a strange Twilight Zone where priorities are upside-down and where flavour-of-the-month rules over practical considerations. Is it hosted using CVS, SNV, Git, Mercurial? It is cross-compiled for 40 different platforms and oh-so-endian-aware? Does it have a command-line interface with pipes? Guess what?
I DON'T CARE.
All I want here is a nice single static library with a header file that I can drop into my project. No dependencies, no versioning conflicts, 6 functions needed: PlayFromFile, PlayFromMemory, Pause, Resume, Stop, SetVolume. It doesn't have to be technically perfect, it doesn't have to be any of the above things, it just has to not suck.
And it seems as though such a thing doesn't exist. Rant over.
1 comment:
So what you're asking for is for a statically-linked library to create its own dsound buffers with extra dependancies upon the system itself, that doesn't have extra dependancies...
That magically interrogates your process to pull out all spacialisation info so it doesn't sound weird if its the 'voice' of some guy behind you, though I guess you want a lazy solution that is a replacement for cd audio and unusable for things like in-game speech or anything fun like that.
You can always just pipe it through the oggdec program then just treat it as a wav.
You'll have huge stalls, but it would work.
Sure, you'd need an extra exe, but at least it won't be a dll with specific version requirements etc, and you get to choose your own extra dependancies with your playback code. Plus if you actually do it right, you get spacialisation.
Plus, you can actually tell when it finishes and queue up the next file... :P
Check out ezquake's version of S_RawAudio. Its a vauge port of the one from FTE, but works with more vanilla sound mixing. Its intended for streaming audio, and was added for voice-chat (fte also uses it for roq/cin audio streaming). It doesn't really do spacialisation though, so for in-game audio its not viable, but as all you seem to care about is a replacement for cd audio, it should serve your needs just fine.
Post a Comment