[refactoring5/master]: Project is always generated without OpenAL support
Moderator: Raze Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
-
- Posts: 1349
- Joined: Tue Nov 05, 2019 6:48 am
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
[refactoring5/master]: Project is always generated without OpenAL support
Edited to reflect the actual issue at hand, please refer to my final post instead.
Last edited by sinisterseed on Sun Oct 23, 2022 10:06 am, edited 1 time in total.
-
- Lead GZDoom+Raze Developer
- Posts: 49204
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [refactoring5]: Duke: Sound practically broken
Sound is fine for me. I have no idea what went wrong here.
-
- Posts: 1349
- Joined: Tue Nov 05, 2019 6:48 am
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
Re: [refactoring5]: Duke: Sound practically broken
Strange, for me the sound is mostly borked, and in all games despite being enabled.
I'll try to see whether my build is broken somehow, although I doubt it. This was a relwithdebinfo build and perhaps something had an unfortunate fate.
I'll try to see whether my build is broken somehow, although I doubt it. This was a relwithdebinfo build and perhaps something had an unfortunate fate.
-
- Lead GZDoom+Raze Developer
- Posts: 49204
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [refactoring5]: Duke: Sound practically broken
Als check your OpenAL.dll.
-
- Posts: 1349
- Joined: Tue Nov 05, 2019 6:48 am
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
Re: [refactoring5]: Duke: Sound practically broken
Nothing, both Debug or relwithdebinfo are busted.
I did something more extreme, and went all the way back to 0.6.0 to check how the logs look like there for comparison. And I found a key difference. Now for some reason, in refactoring5 it doesn't look up the sound device, which makes no sense.
These lines are completely missing from the log when bulding from refactoring5 as of right now:
I did something more extreme, and went all the way back to 0.6.0 to check how the logs look like there for comparison. And I found a key difference. Now for some reason, in refactoring5 it doesn't look up the sound device, which makes no sense.
These lines are completely missing from the log when bulding from refactoring5 as of right now:
Spoiler:The log produced by my build makes no mentions of the sound device anymore. It wasn't like this last I self-compiled a week ago or so. Something changed. My .dlls haven't. When self-compiled the complete log looks like this:
Spoiler:Zero mentions about the sound device or even failure messages to be found, it's as if they're completely skipped.
-
- Lead GZDoom+Raze Developer
- Posts: 49204
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [refactoring5]: Duke: Sound practically broken
This is something you have to work out for yourself. It's surely not an issue with Raze.
-
- Posts: 1349
- Joined: Tue Nov 05, 2019 6:48 am
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
Re: [refactoring5]: Duke: Sound practically broken
But it surely worked fine last time.
Devbuilds from master also work correctly. So it looks like mine are just casually skipping over the audio now. But why, I'm clueless. Apart from newer builds of CMake and MSVC nothing that could interfere changed...
-
- Lead GZDoom+Raze Developer
- Posts: 49204
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [refactoring5]: Duke: Sound practically broken
Have you tried swapping around inis and DLLs?
-
- Posts: 1349
- Joined: Tue Nov 05, 2019 6:48 am
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
Re: [refactoring5]: Duke: Sound practically broken
Ini's, no, would that even be advisable?
Dlls I did, and same result. As I said it's as if it skips over sound devices and openal when self-compiling refactoring5. Just tried again, clean, and same thing. Maybe I forgot to check something in CMake when generating?
Dlls I did, and same result. As I said it's as if it skips over sound devices and openal when self-compiling refactoring5. Just tried again, clean, and same thing. Maybe I forgot to check something in CMake when generating?
-
- Posts: 1349
- Joined: Tue Nov 05, 2019 6:48 am
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
Re: [refactoring5/master]: Project is always generated without OpenAL support
And we elucidated the mystery.
It took a whole Saturday and sending over a self-compiled build, but we did it. It was a bad oversight. The backend update from a few days ago led to the accidental removal of the DYN_OPENAL support toggle, as its place is different in GZDoom, so it simply went missing in Raze. I thought it was replaced by NO_OPENAL which is disabled by default, but what instead happened, was that I was compiling without any OpenAL support at all, since CMake didn't include it anymore, naturally. This also explains why the devbuilds and 1.5.0 always worked fine, but mine did not, despite being based off of the same branch, or refactoring5.
Well, at least none of us is mad. It was fun debugging code that was perfectly functional over the internet lol.
It took a whole Saturday and sending over a self-compiled build, but we did it. It was a bad oversight. The backend update from a few days ago led to the accidental removal of the DYN_OPENAL support toggle, as its place is different in GZDoom, so it simply went missing in Raze. I thought it was replaced by NO_OPENAL which is disabled by default, but what instead happened, was that I was compiling without any OpenAL support at all, since CMake didn't include it anymore, naturally. This also explains why the devbuilds and 1.5.0 always worked fine, but mine did not, despite being based off of the same branch, or refactoring5.
Well, at least none of us is mad. It was fun debugging code that was perfectly functional over the internet lol.