ZDoom with OpenAL

[VoidMage]

I feel much better with autotools, though even there I rate myself only slightly about amateur

Ugh, autotools. In the time it takes to make sense out of that stuff one can become a master of CMake.

Did you just ask me if I understand m4 ? Well, no, not really.
But as far as standard macros go, it's about of the same complexity (and on average, autotools ones tend to be better tested).

But let's not bikeshed about favorite build systems - this doesn't lead to anything constructive.

[Graf Zahl]

3 is a problem that's bound to cause reports. It was the first thing I immediately noticed after switching to the OpenAL backend.

Aside from that I couldn't find anything obvious. I started several songs on both backends and switched between them in various situations, including underwater. It all seems to work fine so far.

That leaves the need for constantly polling the sound system and feeding it new data in the game thread. For a quick release we definitely have to make sure that the sound streams do not starve during screen wipes but I think this stuff needs to be offloaded to a separate thread so that it doesn't hog the same CPU core as the game and renderer.

[Graf Zahl]

autotools ones tend to be better tested).

The biggest issue with autotools is that it doesn't work on Windows, and it's in a state where you cannot present this to users with limited knowledge.

CMake has a nice GUI where it's relatively easy for the user to set all relevant info, and reconfigure the project until everything fits, plus it's not limited to a single toolchain and can be used to create MSVC and XCode projects. I think these advantages easily outweigh everything autotools may provide in familiarity.

[Csonicgo]

The water reverb is missing the pitch shift down, if I recall correctly. It's not much of a big deal considering that doesn't happen in real life anyway (sound doesn't travel slower but travels faster in water).

[Nash]

If sound travels faster in water in IRL, why do they sound lower in pitch then? Anyway I think ZDoom's underwater effect is pretty decent except I think the actual "reverb" portion is wrong (It makes things sound like a huge empty hall). I would bypass reverb completely and just use lowpass and pitch down.

[randi]

I would bypass reverb completely and just use lowpass and pitch down.

Oh, really? Hmm hmm hmm. I think that might make porting to FMOD Studio easier if I did that (since it doesn't like me rehooking its built-in reverb DSP unit).

[Nash]

Yeah I feel that with the reverb module, it actually makes underwater environments sound boxy and acoustically empty... kinda inaccurate if you ask me. Anyway that's just my opinion. :D

[Graf Zahl]

Back on topic:

I fixed the music interruptions during screen wipes - for now without adding new threads.

I did some checks about performance impact of stuffing the music stream in the main thread. Fortunately it's of no importance. I could see a very minor difference if using FluidSynth but it's only 188 vs 190 fps when playing a MIDI through FluidSynth. With other MIDI players or other formats I could not detect any difference at all, so it looks like making this multithreaded is not really necessary after all.

If you ask me, this now looks finished but I'm going to test 64 bit as well today to really make sure.

The only thing that still needs to be done is to delay load the OpenAL related DLLs (openal itself, libsndfile and libmpg123.) so that ZDoom can be shipped without these.
Once that is done I think this can be merged to the trunk.

[Graf Zahl]

If you ask me, this now looks finished but I'm going to test 64 bit as well today to really make sure.

Ugh.
This is going to be annoying:

ALL three libraries used here have the exact same file names as 64 bit versions compared to the 32 bit versions. Which, of course makes it impossible to develop both builds in parallel in the same directory.

What is it with Linux devs to constantly overlook such things that make other peoples' lives harder?

[Graf Zahl]

As for the libmpg123 lib thing, I think we'll need to provide the stuff in a download somewhere. There's more you have to do if you want to statically link and the libraries they provide depend on a very specific version of the mingw redist IIRC. I think I made a statically linkable version of it.

I checked it all now.

For compiling all that stuff on Windows, we may just add the required files to the git repo. It's 200kb of header files and 77/79k of import libraries, 32 and 64 bit respectively. So altogether it'd add 360k of file size. No big deal if it makes compilation of this stuff so much easier (not that it's really hard to set up with CMake...)

The OpenAL binary package with the decoders included would be 868kb for 32 bit and 845kb for 64 bit - the 32bit version requires one additional library which makes it larger.

So my take on this:

- put the compile stuff into the git repo but only use it for Windows with Visual Studio, unless someone can provide MinGW versions of the import libraries. As it stands, there's only ones for OpenAL but not for the decoder libraries.
- for the binary stuff it depends on what we really want. Should FMod remain the default or can it be removed for good? I doubt Randi would want to let it go but I really do not care. From an end user's point of view it'd mostly be the same anyway. A complete binary package with OpenAL instead of FMod would be 500kb larger, if we'd include both backends it'd be 845 kb larger.

[edward850]

There's no point dropping it if it still works.
As a side note, I use ZDoom and ioquake3 sometimes to test old unlabelled hardware, and sometimes the drivers I find for the soundcards will trip up either OpenAL or FMOD. Probably less of a problem with actual day-to-day modern hardware, but there shouldn't be any harm in keeping both anyway, simply for the edge cases (and diagnostics ).

[Graf Zahl]

You are basically correct, but let's not forget a few things:

1. The licensing situation - we all know how this is frowned upon...
2. A basically unstable API is just annoying. Each version changes something and breaks old code.
3. A future rewrite is inevitable because FModEx is already a 'legacy' product.

But well, who cares, CMake allows both backends to be disabled so the biggest problem with this is no longer present anyway:
It can be a hassle to compile older ZDooms because it's nearly impossible to find the proper libraries to compile the sound code.
At least with OpenAL and a stable API as an alternative, the FMod code can now simply be disabled without leaving a broken project behind.

Let's just hope that my last round of fixes is enough to finally merge this.

[edward850]

3. A future rewrite is inevitable because FModEx is already a 'legacy' product.

At least this part could be resolved, depending on how necessary it's deemed. The FMod Studio API looks almost exactly the same, if it is not in fact exactly the same already. To add, GZDoom on Android already uses it (probably not entirely legally, as it's still not GPL, but it doubles it with OpenAL as well).

[Graf Zahl]

In case someone wants to play around with the CMake setup, here's the include stuff for compiling on Visual Studio - all required headers and import libraries. I'd prefer if someone with better knowledge of CMake adds this stuff, I might break other platforms if I tried.

[Zanieon]

Let's just hope that my last round of fixes is enough to finally merge this.

OMG he said "merge this" on that!

I'm really waiting for this since it started.