ZDoom with OpenAL

[Chris]

zdoom: /usr/src/zdoom-svn/src/sdl/i_system.cpp:168: void I_FreezeTimePolled(bool): Assertion `TicFrozen != 0' failed.
Aborted

See: http://forum.zdoom.org/viewtopic.php?f= ... 46#p386670

You can either apply that patch, or warp directly to a map using the +map command line param.

[bagheadspidey]

Heh, this is awesome :D

[Chris]

Some more changes now. It doesn't 'new' a pointer to store the source in the SysChannel anymore (instead it takes a pointer to its location in the Sources vector). The underwater pitch change should work even if EFX isn't available, and the underwater filter should be able to work even if it can't set up an environment filter/reverb (not likely to happen, but just in case..).

This version also allows OpenAL to handle attenuation on sounds that use logarithmic rolloff. It can also work on sounds that use linear rolloff, if the AL_EXT_source_distance_model extension is available (it's just waiting for finalization).

EDIT: Please note, I am dumb.I also didn't test it properly, so if you downloaded it, re-download it to get the fixed version.

[bagheadspidey]

Is that what that "duh" message was about? I wasn't gonna say anything, figured you'd catch that ;)

edit - Yes, awesome, yay, thank you.

edit2 - works in gzdoom also. I had to manually apply the cmakelists part, though, even though everything looked exactly the same, and I told patch to ignore whitespace. Not sure what was up with that.

[skadoomer]

great job Chris. I'm really impressed with how you stepped up to the plate on this task.

This seems like its winding down to a close, so what is left to be done aside from general tests and bug fixes?

[Chris]

Mainly just Randy's "okay", I think. There might be something I overlooked/forgot, but I don't think there's much more that can be done until some OpenAL extensions I'm waiting for also get okay'd (ie. per-source distance models and attenutation tables to handle SNDCURVE, instead of having to manually play with the source gains). I have some cleanups/improvements in local changes (mainly caching different reverb environments instead of converting/reloading them for each environment change), and some more cleanups might be able to be done, but I imagine it can be put in soon and improved later.

[Chris]

Right now I'm contemplating moving off the format loading to ALURE, which I recently created for reasons such as this. It's still new, but it can already handle the same formats I had ZDoom handling, and relying on that one lib for will be simpler than relying on three or more. The same DLLs will be needed in the end for all the formats, of course, but it's easier than needing the development stuff to build against. Plus once I can get CMake 2.6 (when Gentoo stops taking its sweet time), I should be able to make prebuilt Win32 binaries of it so no external libraries need to be built before hand.

As a consequence, I can get rid of the decoder interface. I kept direct handling of libvorbisfile for DecodeSample/OXM files, but moved it into the base SoundRenderer class so derivitives don't need to decode it themselves. For Windows, you only need the vorbis/ogg headers and they can even be put into ZDoom's source tree.. the dll is loaded at runtime and silently skipped if missing. Linux still needs it at compile time, but if this is an issue, I will look into dynamicly loading it there, too.

If needed, I can revert back, but here's patches using ALURE.
(PS. I know it says that the API is not finalized; however, unless someone has valid concerns or something bad crops up, it won't likely change before it's finalized).

[Chris]

Now that ALURE has officially been released, with Windows binaries*, hopefully these patches can be usable to other people again. As far as I can tell, the only thing really missing is the underwater reverb (which I'm still not sure how it fits into everything), and the reverb conversion may be a little funky. Unfortunately, I had to drop MP3 support from ALURE because libmpg123 was not cooperating and does not like to be loaded at run-time, so MP3 sound effects and music won't work (though ZDoom can always hook up with a different lib like libmad and provide callbacks for ALURE to get that working again).

* The binaries provided are made for MinGW32, though the header and DLL should work with MSVC.. ALURE is not explicitly linked at compile time, so an import lib isn't needed)

[Graf Zahl]

* Use the provided dlls\<WinType>\ALURE32.dll if linking dynamically. The DLL
should be placed in the end-user's system32 folder...

Are you insane?!?

[Chris]

Are you insane?!?

Heh. Well, one of the benefits of dynamic libs is being able to share the same one for all apps that use it. Upgrade it, and all apps that use it will immediately benefit. AFAIK, system32 is the "public" place that all Win32 apps will look to for a DLL if it's not next to the exe, and I do say you can optionally just set it next to the executable.

[Graf Zahl]

System32 is the most abused thing in Windows history. I believe that third party stuff has no place being there!

[Enjay]

As a windows user who knows that his system32 directory is significantly bigger than it used to be and has lots of redundant dlls sitting in there left behind by messy programs, yet I have no way to identify what is needed and what is not, I agree entirely.

[bagheadspidey]

Out of curiosity, is there some recommended place for 3rd party shared libraries on windows systems? I imagine anywhere in the path should do, but system32 is the only place I know of that's always in the path...

[MDenham]

Out of curiosity, is there some recommended place for 3rd party shared libraries on windows systems? I imagine anywhere in the path should do, but system32 is the only place I know of that's always in the path...

System32 is, unfortunately, the "recommended place"; however, programs are horrible about cleaning up after themselves when there are no other programs using the DLLs in question.

Incidentally, this is part of what the massive expansion of the Registry between Win3.1 and Win95 was supposed to help with (usage counts for DLLs is in there, but largely ignored by uninstallers)...

[Chris]

Updated for r1369, and cleaned away some unneeded code.

Anyone know what the legality would be for using a GPL lib (libmad for MP3) with ZDoom? AFAIK, run-time loading doesn't protect it from the viral aspects of the GPL, and since ZDoom's license isn't GPL compatible, I'm not sure what can be done. The other MP3 lib I'm aware of which is LGPL (libmpg123) isn't conducive to being loaded at run-time.