search

ec- / Quake3e

Improved Quake III Arena engine
GNU General Public License v2.0
1.16k stars 150 forks source link

Feature Request: OpenAL backend #33

Open ensiform opened 4 years ago

ensiform commented 4 years ago

Would like to have some additional feature parity by having OpenAL support. Maybe improved from ioquake since it had limitations?

VoIP can be excluded for now unless you want it

ghost commented 2 years ago

Currently I have a Q3e fork using openal (eventually + efx + voip + vorbis) and I'm a bit hesitant if it is worth to add openal support to Q3e at all. Is this still something of interest? Are there any other suggestions concerning OpenAL-Soft support? @ensiform I inspected a few games and how there implementation is done, but I still don't see which one is the 'best', or better than the one from ioquake3. To me quake2xp isn't really much better as well (referring to https://github.com/etfdevs/ETe/issues/6). Speed comparisons gives me neither more nor less FPS using openal-soft vs. dma sound. I also tested Q3e with Openal + enabled efx effects using boomstick (Q3Reaction) mod with compiled efx contents, and it works well. Since I saw that @BidyBiddle managed to get dmaHD working with Q3e I would also highly appreciate his opinion about the current Q3e sound status. @ec- What do you think about Openal-Soft support? Any suggestions are welcome!

ensiform commented 2 years ago

I can't just drop in whatever you come up with for quake3e because there's significant portions of ET sound features that need to be implemented as well.

ghost commented 2 years ago

You mean scripted speaker (volume/range). Music streams, etc. If I have a basic concept I consider to make a seperate PR for ETe considering the necessary API differences (trap calls). If you want you can also make some special requests for ETe, though it would be also okay if ETe will use a different implementation than Q3e. I just thought it would be recommended that both (Q3e and ETe) stay close to each other. Extending the API shouldn't be too hard. The AL-efx effects are API independent. Thanks for the response!

ensiform commented 2 years ago

Scripted stuff is all cgame really. It's the volume control, fading, different flags and other features with channels that must be used.

ghost commented 2 years ago

None of the things you mentioned is causing troubles with OpenAL soft (with the exception of fading stereo sounds, but this is not Q3e/ETe related). Special API calls should work fine, I even saw the 'lip-sync' feature (RtCW) fixed recently. Or is your statement a suggestion to implement OpenAL the way ioq3 did it? This way it's granted that all idtech3 engines are supported. I can confirm that basically all of these API calls are supported by OpenAL-Soft: https://github.com/zturtleman/spearmint/wiki/id-Tech-3-Engine-Features#New_cgame_to_client_calls-2 (ET API sound related overview).

ensiform commented 2 years ago

It's not a trouble with openalsoft but must be implemented in snd_openal as well so I have lot more work unless I straight up copy etl. I'm well aware they can be supported but it's the implementation I'm avoiding doing that work

ec- commented 2 years ago

@ec- What do you think about Openal-Soft support?

Very, very skeptical

ghost commented 2 years ago

Thx