ZDoom with OpenAL

[Graf Zahl]

Ok, my tests are complete, I think I did everything that still was necessary. I'm waiting for the next few hours to see if someone has objections but as I see it this can be merged and closed.

[Caligari87]

Kinda been casually following this for a bit, wanted to just confirm: When this is merged, both the ZDoom and GZDoom "development" builds will be running OpenAL, and the licensing situation with FMOD will be solved, allowing G/ZDoom to be used commercially (or at least one step closer to the same)?

I have no stake in the matter either way, just curious.

[Graf Zahl]

No, commercial use is still not possible. There's some Build code in the software renderer and the OPL code that come with a no profit clause.

[Caligari87]

Ah, okay.

[Xaser]

I thought the idea at some point was to have a quasi-official fork of GZ that removes the software renderer (and I suppose the OPL stuffs) to make such a thing viable.

[Graf Zahl]

It's finally done. I just merged this to the master branch.

To anyone who is concerned about stability, like apparently Blzut3:

The only way to get some feedback is for the OpenAL stuff to appear in the dev builds, so that bugs can be reported.
As long as this remains in its own branch only a handful of people with some personal interest are going to bother.
I think 2.8 is still far enough in the future that potential problems can be worked out - some of my recent changes like DoomEdnum externalization or multiple tags were far more invasive - and the public testing has certainly helped finding the remaining issues there - as it will here.

[Blue Shadow]

Where can I find openal32.dll?

Edit: SLADE3 comes with one. It seems to be working...

[Zanieon]

OMG IT WAS ADDED

[Blue Shadow]

I think I've found a bug, but before making a report, I'd like to test things with the .dll you guys are using, first.

[Blzut3]

To anyone who is concerned about stability, like apparently Blzut3:

You seem to have misunderstood my concerns. I understand that something can't be stable until it's been tested which means it basically needs to be merged. The issue I had was keeping 2.8 from being released due to new features coming in. This would have included your doomednum changes if you made it known you were working on them before going ahead with them. I don't know what you were reading in the developer's forum, but it sounded to me like Randi was about ready to release and then suddenly new features came into play (although I think Randi did add a few himself).

[Graf Zahl]

I think that 2.8 needs to wait anyway for the scripting branch, as I understand the plans. If not, I'd say make it now, merge that branch, wait for feedback and get 2.9 out as soon as possible.

[Graf Zahl]

I think I've found a bug, but before making a report, I'd like to test things with the .dll you guys are using, first.

Did you just add openal32.dll? That alone won't be enough, you also need libsndfile and libmpg123. I already prepared some binary packages but it still needs to be decided how to handle this matter. Randi quickly jumped ahead and disabled OpenAL in the VC++ 2005 solution so official builds will have OpenAL completely disabled which will make it a bit of a problem to deal with this adequately.

[Blzut3]

I'd say make it now, merge that branch, wait for feedback and get 2.9 out as soon as possible.

That was my interpretation of what was said, although looking over the thread now, there's not much that should have given me that impression other than this is what I would do. (Then create some release schedule so that releases are somewhat regular.)

Randi quickly jumped ahead and disabled OpenAL in the VC++ 2005 solution so official builds will have OpenAL completely disabled which will make it a bit of a problem to deal with this adequately.

As far as DRD Team is concerned, my thoughts are to just treat OpenAL as a GZDoom feature.

[Graf Zahl]

As far as DRD Team is concerned, my thoughts are to just treat OpenAL as a GZDoom feature.

Why is that?

[Blzut3]

In my opinion DRD Team should be providing builds as if they were provided by Randi. Of course given that they're done with CMake+VS2005 instead of the hand generated solution there some room for debate there. Randi clearly wants to treat OpenAL as a fall back solely for platforms where FMOD is not viable.

I assume GZDoom is going to have it enabled, so the code would still get coverage there.