FWGS / xash3d-fwgs

Xash3D FWGS engine
1.56k stars 236 forks source link

Discussion about SoundAPI specification #762

Open SNMetamorph opened 2 years ago

SNMetamorph commented 2 years ago

Предлагаю разработать и ввести в движке новый интерфейс для возможности реализации звуковой подсистемы со стороны клиента игры, по тому же принципу как RenderAPI. Это потенциально намного расширяет возможности моддинга. Структура у всего этого должна быть примерно такая: изображение

mittorn commented 2 years ago

То есть предполагается вынести создание звукового контекста в клиент и реализовывать движковый звук на уровне миксера поверх него уже? А на ком должна быть загрузка звуков?

a1batross commented 2 years ago

Заменять микшер клиентом -- в целом идея хорошая.

Но как и в случае с рендерингом, хотелось бы оставить soundlib и вывод в движке.

Если тот же OpenAL Soft имеет возможность работать просто микшером, то это как раз то что я имею ввиду. Чтобы он сам не взаимодействовал с платформо-зависимым выводом аудио.

SNMetamorph commented 2 years ago

Чтобы он сам не взаимодействовал с платформо-зависимым выводом аудио.

А чем это плохо? У него куча бэкэндов под разные платформы. А вот насчет возможности его работы как микшера ничего не могу сказать, не шарю

a1batross commented 2 years ago

Аудио будучи одной из частей которую всегда можно улучшить (например уменьшать задержки), часто в итоге и переписывается с нуля.

Я напомню, что у Windows есть около двух или трёх способов вывести звук на аудиокарточку, в Linux около пяти, в Android три. Моды в отличие от движка могут не изменяться десятилетиями.

В любом случае, при возможности реализации микшера в клиентском коде ничто не запрещает выводить аудио самостоятельно. С этим просто наверное ничего не получится сделать. Но наша ответственность как разработчиков движка -- это дать интерфейс универсальный, и само собой постараться его не ломать.

mittorn commented 2 years ago

Для аудио возможно стоит и сделать возможность притащить в клиент платформенную реализацию. Главное чтобы такая функциональность была опциональной. В отличие от графики ситуация с аудио куда печальнее - кто-то тот же steam phonon захочет задействовать.То есть мы можем сделать что-то уровня OpenAL в интерфейсе, но даже в таком случае - сможем ли мы отдать буффер уже подготовленный steam audio движку? Если да и это предусмот рено - тогда действительно вывод можно оставить в движке. А так - openal обычно уже доступен на целевой платформе и в отличие от OpenGL не требует передачи ему платформенного окна, верно? Если недоступен - или это совсем какая-то ограниченная консоль или вообще дос какой-нибудь. То есть как я понимаю использование в моде OpenAL не потребует в интерфейс тащить платформенные объекты

a1batross commented 2 years ago

SteamAudio так может, я проверял. :)

А вот OpenAL судя по всему не похоже.

a1batross commented 2 years ago

Как вариант можно в движке перейти на OpenAL, если кому-то хочется его использовать, и тогда прокидывать интерфейс в клиентку.

Но это уже совсем безумие.

SNMetamorph commented 2 years ago

Ну у меня позиция такая: дать возможность моддерам перелопатить движковый звук насколько это вообще возможно. А ответственность на том, насколько оно будет переносимо на другие платформы и не отвалится ли через некоторое время по каким-либо причинам, лежит на самих разработчиках мода.

mittorn commented 2 years ago

Да в том то и дело что намного проще позволить клиентке перегрузить вывод, Так уж выходит что OpenAL сам по себе не является платформенной частью, хоть и взаимодействует с платформой. На android такая перегрузка тоже возможна - OpenSLES там не требует получать ничего от приложения

a1batross commented 2 years ago

насколько оно будет переносимо на другие платформы и не отвалится ли через некоторое время по каким-либо причинам, лежит на самих разработчиках мода

практика показывает что им пофиг

0x4E69676874466F78 commented 2 years ago

Если пытаться усидеть на всех стульях:

  1. Базовая реализация в движке, она же предоставляющая API для создания своих эффектов и предустановок (для 95% мододелов должно хватить). Это может быть абстрактный слой над OpenAL где OpenAL может заменяться другим аудио движком.
  2. Возможность моду переключить базовую реализацию на собственную (для тех самых 5%). 2.1. Автоматический fallback на базовую реализацию в случае ошибки инициализации (требует от мододелов правильную обработку ошибок, следовательно об этом надо написать большими красными буквами, иначе все забьют) и ручной запрет переключения через например консоль/конфиг "force_default_audio_backend".
a1batross commented 2 years ago

Possible reference:

https://github.com/a1batross/Xash3D_ancient/blob/master/source/public/vsound_api.h

https://github.com/a1batross/Xash3D_ancient/tree/master/source/snd_al

https://github.com/a1batross/Xash3D_ancient/tree/master/source/snd_dx

0x4E69676874466F78 commented 2 years ago

https://habr.com/ru/post/525946/