ZDoom

Since FMOD's website is working again I tried using fmod 4.34.07 with the changes in gzdoom-macosx. As far as I can tell sound works fine. The only thing is if you ignore the #ifdef __APPLE__ (or whatever it was) you have to remove the OPENAL output type on Windows I think.

Edit: It also looks like fmod can natively interface with PulseAudio as well now.

Interesting. The source differences are only minimal so I'm going to try if the code compiled in Windows will also work with 4.34.

More interestingly than GZDoom running on a Mac. It looks like fmodex 4.34 is being used: http://code.google.com/p/gzdoom-macosx/source/detail?r=30099b4f8f7ff696fd16942efe328e4f68a2eb8b I downloaded it just to confirm and it is indeed running on 4.34.

Good question. I never heard from him.

Why didn't this guy propose patches for the main port instead of making a fork?

GZDoom for Mac!? OMG I gotta try that!

GPL V2?

[quote="Gez"]But that's not all -- GZDoom can be compiled for Linux and Mac too. Now the Mac part isn't very important because [s]Steve Jobs can suck it[/s] the OpenGL init code for that platform doesn't exist and ever since FraggleScript was added to ZDoom there's no real reason to use GZDoom on Mac instead of ZDoom; but it'd be a shame to lose crossplatform support for Linux.[/quote]
http://code.google.com/p/gzdoom-macosx/

[quote="DaMan"]If all you care about is Windows then OAL isn't a good choice. Most will be using the OAL to DSound wrapper. And MSDN has to have better documentation on Xaudio2/Dsound than [url=http://connect.creativelabs.com/openal/Documentation/Forms/AllItems.aspx]this[/url].[/quote]

None of these APIs really do the job.

DSound is obsolete, XAudio2, aside from being system-locked to Windows doesn't really seem to offer much and OAL is lacking any common sense of how to write an audio library. Notifications and callbacks are the backbone of any decent sound system and OAL has no support whatsoever for them, requiring constant polling instead. This places all the burden on the developer instead of having it handled by the library that already knows what's up. And the current ZDoom implementation was done with only Linux being considered as it can't do anything significant without the GStreamer library which on Windows is a mess to get to work and as such not an option to use.

So it should be obvious where this is heading (again.) Unless a professional quality free sound library gets made I see no chance of change.

But that's not all -- GZDoom can be compiled for Linux and Mac too. Now the Mac part isn't very important because [s]Steve Jobs can suck it[/s] the OpenGL init code for that platform doesn't exist and ever since FraggleScript was added to ZDoom there's no real reason to use GZDoom on Mac instead of ZDoom; but it'd be a shame to lose crossplatform support for Linux.

If all you care about is Windows then OAL isn't a good choice. Most will be using the OAL to DSound wrapper. And MSDN has to have better documentation on Xaudio2/Dsound than [url=http://connect.creativelabs.com/openal/Documentation/Forms/AllItems.aspx]this[/url].

[quote="Nash"]Mega bump!

So recently, it seems that "all renderer code has been separated from the rest of the code" - I wonder what this is in anticipation for? Or is it just for housekeeping?[/quote]



I did it because it really started to annoy me not being able to find the stuff that's not software renderer exclusive in the r_ files. It's also one of only 3 subsystems in ZDoom that contains GPL incompatible code - the others being the FMod based sound system and the OPL emulator. As such I always considered it particularly bad style that it was a hopeless mishmash of code for very different purposes that also contained some code under a problematic license.

Whether I ever get OpenAL to work I really don't know. I'm still not fully convinced that it's a good sound library for Windows use.

[url=http://forum.zdoom.org/viewtopic.php?f=4&t=30093#p574042]Here's a hint[/url].

Mega bump!

So recently, it seems that "all renderer code has been separated from the rest of the code" - I wonder what this is in anticipation for? Or is it just for housekeeping?

[quote="esselfortium"]Yeah, I somewhat wonder why, too. The new textures and the new maps to go along with them makes sense, both to "make Doom feel fresh again in 1997" and stylishly work around the hardware limits instead of running up against them trying to mimic the PC game. The new sprites I guess just go along with the desire to make it feel more like a new game.[/quote]
I'd say to have a consistent graphical theme. The original sprites wouldn't fit into the dark/glowy atmosphere of the new textures and maps, any more than the Doom64 sprites really fit with the original textures and maps (they are interesting to mix up, actually, but they stand out). Additionally, new sprites could be better designed to take advantage of a true-color display (256 colors per sprite, vs. 256 colors total), and make them look better when filtering is applied compared to the original sprites.