Can MP3/OGG format be played in DirectX games?

There is an article that covers a DSound server. You can add the OGG VorbisLib routines that refill the buffer with decompressed sound data.
However, for non-profit project FMOD is a good choice as modena suggested.

Good luck,
Pat.

That's an absolutely terrible article on how to use OGG.

Here's one that isn't terrible.

http://www.icarusindie.com/programming/homebrew/oggvorbistut.php

It includes a plug and play class that's entirely contained in a single h file. It handles any size Ogg file and any number of buffers. Since DirectSound handles all the threading issues internally it's kind of (most definitly actually) redundant and pointless to suggest that the coder implement threads as well.

You don't need to dedicate a thread to checking to see if a sound is done playing. It's a huge waste of resources. Especially for single processor systems.

And actually you should use DirectSound 7. It's about 3 lines of code and a #DEFINE difference (change the define first and the compile errors will guide you the rest of the way). Unless you plan on using the advanced features of DirectSound 8 (I can't think of any), DS 8 only serves to break compatibility with old soundcards. Which is stupid.

I have an OpenGL project that works great on old hardware but before I switched to DS7 for the Ogg class it wouldn't run simply because the sound card wasn't compatible.

You have to watch out for stuff like that.

Oh yes, and FMOD is pointless unless you want cross platform support. Which if you're using DirectX, it isn't an option. Loading and playing Ogg is such a simple process that there's absolutely no need to use some complex library like FMOD. The Vorbis DLLs handle pretty much everything and there's no licensing restrictions.

Something you seriously want to avoid if you can. Your product should only be limited by restrictions you put on it. Microsoft doesn't care what you use DirectX for. Since FMOD does care, you need to seriously consider why you would need to use them.

Quote:Original post by Anonymous Poster
That's an absolutely terrible article on how to use OGG.

Here's one that isn't terrible.

http://www.icarusindie.com/programming/homebrew/oggvorbistut.php

It includes a plug and play class that's entirely contained in a single h file. It handles any size Ogg file and any number of buffers. Since DirectSound handles all the threading issues internally it's kind of (most definitly actually) redundant and pointless to suggest that the coder implement threads as well.

You don't need to dedicate a thread to checking to see if a sound is done playing. It's a huge waste of resources. Especially for single processor systems.

And actually you should use DirectSound 7. It's about 3 lines of code and a #DEFINE difference (change the define first and the compile errors will guide you the rest of the way). Unless you plan on using the advanced features of DirectSound 8 (I can't think of any), DS 8 only serves to break compatibility with old soundcards. Which is stupid.

I have an OpenGL project that works great on old hardware but before I switched to DS7 for the Ogg class it wouldn't run simply because the sound card wasn't compatible.

You have to watch out for stuff like that.

Now that's great - you bash the use of multi-threading because of its 'huge waste of resources' and suggest using a class instead, that uncompresses a whole OGG into a DSound buffer! You know that this is not suitable for playing background music, don't you?
If I have a 4:10 min song at 44.1KHz, 16 bit stereo that's 4*44100 * 250 bytes of data → 44MiB!!! Waaayyy better than a 3 second buffer that is updated in a single seperate thread. I understand that. My multi-threaded sound server uses only about 128k of memory (depending on buffer size) and uses up to 1% of my CPU time because of the threading overhead [wink].

Now try to imagine I want to fade two songs into each other using that DSound class...

It works fine for playing background music and sound effects.

By decompressing on the fly you're wasting CPU cycles that are better used for gameplay and graphics.

Quote:Original post by Anonymous Poster
It works fine for playing background music and sound effects.

By decompressing on the fly you're wasting CPU cycles that are better used for gameplay and graphics.

You trade off a small amount of extra CPU cycles for a huge amount of memory. If you implement a system that changes background music occasionally, the game will choke on that because of the time required for reading and decompressing. Streaming provides you with a small memory footprint and a very smooth CPU utilisation.
Small samples and effects, however, would of course be decompressed completely before being played. I wouldn't want to waste 103MiB of memory on a 10 minute background song, though (remember your rant was specifically targeted at low-end machines - chances are that such boxes don't even have 100MiB of RAM).

Regards,
Pat