search

JHGuitarFreak / UQM-MegaMod

A fork of The Ur-Quan Masters + HD-mod that remasters the HD graphics with a veritable smorgasbord of extra features, options, QoL improvements, and much more...
https://uqm-mods.sourceforge.net
GNU General Public License v2.0
80 stars 22 forks source link

Fix OpenAL on 64-bit builds #9

Closed Ala-lala closed 5 years ago

Ala-lala commented 5 years ago

The OpenAL audio driver was assuming that the size of audio_IntVal and audio_Object were the same as ALint and ALuint. This is wrong on 64-bit builds, as audio_IntVal and audio_Object are defined as intptr_t and uintptr_t while ALint and ALuint are defined as int and unsigned int. This caused a crash when playing any sound with OpenAL.

The MixSDL and nosound drivers were making the same assumption with mixer_IntVal and mixer_Object, but this wasn't currently an issue since they're also defined as intptr_t. I've added the same code to them to ensure they still work if audio_IntVal and _Object ever become larger than mixer_IntVal and _Object.

(This also affects base UQM; if I could, I'd submit the patch to their bug tracker, but it's down.)

Serosis commented 5 years ago

Wish GitHub didn't get rid of the private messages.

Could throw it on the UQM forums.

michaelcmartin commented 5 years ago

Doing the copies ends up making each audio buffer fill take three times the work -- for the MixSDL and nosound cases we should "fix" such potential future bugs by also expanding the mixer objects.

The OpenAL case is interesting because at the time we'd written the support we had not contemplated that 64-bit OpenAL would be an option. The base code has not been tested against OpenAL Soft at all -- except by intrepid modders, anyway.

I expect to incorporate some but not all of this patch into the vanilla codebase.

Ala-lala commented 4 years ago

Doing the copies ends up making each audio buffer fill take three times the work

Wait, what? I thought the audio_Objects were essentially pointers, and the samples themselves were passed to BufferData (which doesn't do any conversion). Am I wrong?

michaelcmartin commented 4 years ago

I'm basing this on the functions like nosound_Convert{To/From}AudioBuffer, which have a loop in them that does the copy; assuming that data is going through that in both directions that's two extra memcpy-like operations compared to the first. It's possible I'm less clear on the actual dataflow here, though; I don't really have any sharp memories of this code.