forum.boolean.name - Russian Sound System

forum.boolean.name (http://forum.boolean.name/index.php)

- Проекты C++ (http://forum.boolean.name/forumdisplay.php?f=56)

- - Russian Sound System (http://forum.boolean.name/showthread.php?t=15687)

Ответ: Russian Sound System

http://www.youtube.com/watch?v=XHosLhPEN3k
Имхо найболее удобными и правильными интерфейсами для выделенных библиотек (звуковая библиотека делает большинство операций внутри себя, а наружу прокидывает только функции наподобие проиграть звук и тд) являются процедурные интерфейсы, это позволяет не заморачивать пользователя своими уникальными познаниями в области ООП и значительно упрощает интерфейс библиотеки.

ps. самые профессиональные библиотеки имеют функции переопределения аллокаций на хипе или вообще работают с выделенным им буфером статического размера, библиотеки которые позволяют себе выделять память без разрешения пользователя показывают весьма посредственную инженерную культуру программиста в области приложений реального времени, которыми отчасти являются интерактивные игры :)

Ответ: Russian Sound System

В случае с Russian Sound System это можно назвать звуковым движком ( в перспективе ), если я правильно понимаю, там нужно создавать объекты источников звука, слушателей, объекты преграды и т. п. помойму ООП самый удобный вариант.

Вообще я помню Джон Кармак где то написал: если не уверен какой вариант лучше - сделай оба.

Ответ: Russian Sound System

ИМХО для каждого языка проще написать свою ООП обертку

Ответ: Russian Sound System

Цитата:

если не уверен какой вариант лучше - сделай оба.

Кстати да. В FMOD'e есть еще заголовочник FMOD.hpp для сиплюсов, там обернуты в классы функции из fmod.h.

Ответ: Russian Sound System

Цитата:

ps. самые профессиональные библиотеки имеют функции переопределения аллокаций на хипе или вообще работают с выделенным им буфером статического размера

А можно ссылку на какие-нибудь примеры как это можно сделать.

Ответ: Russian Sound System

Цитата:

самые профессиональные библиотеки имеют функции переопределения аллокаций на хипе или вообще работают с выделенным им буфером статического размера

хз.хз. я считаю что библиотека лучше знает как ей работать с памятью, чем клиентский код.

Ответ: Russian Sound System

Оба подхода хороши. Но мне просто сам механизм интересен.

Вот я правильно понимаю, что в куче находятся всякие методы класса и с помощью переопределения аллокаций, можно получать доступ к разному набору этих методов? Но ведь хедеры не меняются, как пользователь узнает ( до попытки скомпилировать ) к каким именно методам у него есть доступ? Или там находу генерируются указатели на методы?

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

Кстати какое мнение насчет COM?

Ответ: Russian Sound System

Samodelkin
а ?

пример кода библиотеки который позволяет переопределить аллокацию на хипе, плюс я в юзерской части кода показал как делать топорный аллокатор с статическим массивом

Код:

// ------------- lib



typedef void*(*mylib_mem_alloc)(size_t size);

typedef void(*mylib_mem_free)(void * ptr);



static mylib_mem_alloc mem_alloc;

static mylib_mem_free mem_free;



void mylib_setOverride(mylib_mem_alloc setA, mylib_mem_free setF)

{

        mem_alloc = setA;

        mem_free = setF;

}



struct mylib_context

{

        int a, b, c;

};



mylib_context * mylib_init()

{

        return (mylib_context*)(*mem_alloc)(sizeof(mylib_context));

}



void mylib_free(mylib_context * ctx)

{

        (*mem_free)(ctx);

}



// ------------- user code



static char mbuf[4096];

static size_t mpos = 0;



void * usr_alloc(size_t size)

{

        size_t mpos_old = mpos;

        mpos += size;

        return mbuf + mpos_old;

}



void usr_free(void * ptr)

{

}



int main()

{

        printf("mbuf ptr %p\n", mbuf);

        

        mylib_setOverride(usr_alloc, usr_free);

        

        mylib_context * ctx = mylib_init();

        

        printf("ctx ptr %p\n", (void*)ctx);

        

        mylib_free(ctx);

        

        return 0;

}

на выходе получаем два одинаковых поинтера в консоли, что означает что наш супер аллокатор памяти работает

ps. методы классов не находятся в куче, они находятся в скомпилированном коде, в куче разве что может находится vtable с указателями на методы для классов с виртуальными методами

Ответ: Russian Sound System

Докладываю. Полностью отлажен стриминг. Оставил классовый интерфейс - но с небольшими изменениями. Добавлены различные примитивы звукового окружения( RSSEnvironmentSphere, RSSEnvironmentCylinder ). Вскоре добавлю еще и выпуклые тела ( RSSEnvironmentHull ). Хотя с учетом множества бесплатных физ.движком есть возможность использовать их средства для проверки попадания точки в меш.

Почему я не выкладываю демку? Потому что учет геометрии окружения при прогрывании звуков довольно медленно работает и я так и не смог придумать нормальной функции затухания звука. Из-за этого получается что при загораживании слушателя небольшим объектом( к примеру, ящиком ) звук как-то не естественно себя ведет.

В итоге я опять не знаю что делать:
а) Добавлять поддержку еще кучи разных форматов
б) Пилить учет геометрии окружения. Там всякие октарные деревья для оптимизации и прочее.
в) Писать документацию

С удовольствием обсудил бы ситуацию насчет функции затухания звука.

Еще встает вопрос о лицензировании. Думаю вкрутить в двиг таймер как в Хорсе. Ну и ключики раздавать. Форумчанам бесплатно. Но это все перспективы, а нерешенные проблемы изложены выше.

Для демки уже имеется идея. Сделать что-то типа хоррора, где звук играет основную роль( ну вы же играли в Dead Space или инди SCP ).

Ответ: Russian Sound System

Цитата:

Добавлены различные примитивы звукового окружения( RSSEnvironmentSphere, RSSEnvironmentCylinder ). Вскоре добавлю еще и выпуклые тела ( RSSEnvironmentHull ).

Я думаю нужен бокс тоже.

Цитата:

Из-за этого получается что при загораживании слушателя небольшим объектом( к примеру, ящиком ) звук как-то не естественно себя ведет.

А ты только один луч трассируешь? Я думаю этого мало...

ИМХО:
1. Можно сделать медленную но точную трассировку, когда от слушателя во все стороны трассируются лучи до каждой стены, затем из точек пересечения со стенами трассируется до каждого источника звука и микшируется. Ну вобщем принцип тот же как при трассировке света. А прохождение звука сквозь стены можно сравнить с рефракцией лучей проходящих через прозрачные объекты. Возможно звук даже можно на шейдерах посчитать.

2. Упрощенный вариант - можно трассировать только один раз от слушателя и до источника как ты делаешь, но у тебя не учитывается дифракция - когда большие волны огибают мелкие препятствия. Я думаю тебе нужно просто считать размер объекта или его бокса и если он маленький то и коэффициент затухания будет меньше. Только еще нужно учесть когда много маленьких объектов стоят вплотную это будет один большой.

3. Еще проще - вот у тебя же есть боксы с характеристиками сцены (там где эхо и т п). Так вот туда нужно добавить коэффициент затухания. Дизайнер или мэппер сам установит нужный коэффициент затухания. Тут нужно еще одну вещь добавить - надо сделать возможность взаимосвязи двух боксов. Например есть две комнаты, каждая комната это бокс со своими настройками звучания. Между комнатами есть дверь - она представляется как связь между боксами. Если дверь закрыта, то слушатель в одном боксе, будет слышать источники из второго бокса с большим коэффициентом затенения звука, чем когда дверь открыта.

Вот ну еще стоит добавить что трассировку лучей в любом случае надо делать с помощью октри - сцены то могут быть большие.

И еще вот если возвратиться к варианту 1, ведь в случае с освещением делают лайт мэп. Может что то похожее можно сделать со звуком? Например есть сцена где очень много статических источников звука, это все можно с помощью трассировок рассчитать и сгенерировать объемную карту звука, где будут описаны результирующие характеристики звука в каждой точке пространства.

Цитата:

а) Добавлять поддержку еще кучи разных форматов

Я думаю можно обойтись wav и ogg, но использовать их на 100%. Лучше напиши рекомендации как и с помощью каких утилит конвертировать из других форматов в эти два.

Цитата:

в) Писать документацию

Обязательно!

Цитата:

Еще встает вопрос о лицензировании.

Главное чтобы пользователям разрешался профит от коммерческого использования движка.

Цитата:

Думаю вкрутить в двиг таймер как в Хорсе

Бред.

Ответ: Russian Sound System

Фух. Прямо таки мыслей подлил в голову. Твои мысли взяты на вооружение. Начинаю запиливать!

Цитата:

Бред.

Согласен. Просто лицензия на использование и все. Без ограничений

Ответ: Russian Sound System

Как идет разработка библы?
Для меня она была бы очень полезна.

Ответ: Russian Sound System

Проект переименован в ProjectF. Полностью переписан. Функциональный интерфейс. Тестировал много раз. Не факт что все баги нашел.

Новые фичи.

1) Препятствия для звуков. Obstacles.
2) Фильтры.
3) Атмосфера. В прямом смысле. На затухание высоких частот влияет сухость или влажность воздуха.
4) Группы звуков.
5) Поддержка разных систем координат.
6) Отладочный рендеринг.
7) Полная лояльность к ошибкам использования. Просто код ошибки ( pfSystemGetLastError() ) и никаких вылетов.
8) Воспроизведение файла по частям.
9) Мелочи.

Демки нет. Будет время - сделаю. Справки нет. В заголовочнике названия функций сами по себе справка.

Пример

Код:

#include "ProjectF.h"



void main()

{

pfSystemCreateLogFile( "ProjectF.log" );



pfSystemEnableMessagesOutputToConsole();

pfSystemEnableMessagesOutputToLogFile();



pfSystemInit();



SoundData data = pfDataLoad( "music.ogg", true );

assert( pfSystemGetLastError() == PF_NO_ERROR );



Sound music = pfCreateSound( data, true );

assert( pfSystemGetLastError() == PF_NO_ERROR );



while( !bbKeyHit( KEY_ESCAPE ))

{

        pfPlaySound( music, true );

}



pfSystemDestroy();



}

Ответ: Russian Sound System

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

* Планируется ли ОО интерфейс, для С++ или других языков? Или только функциональный будет для большей совместимости с разными языками?
* Что насчет компиляции под Linux или другие платформы? ( я так понимаю в ProjectF только OpenAL и VorbisOGG используется или еще что-то? ).
* Помнится предыдущая версия ( еще RSS ) вылетала без предупреждения если на компьютере не поддерживался EAX или еще что-то. Вот собственно в ProjectF будет режим без EAX или какой-нибудь софтварный? Ведь не на всех компьютерах есть аппаратная поддержка, и пользователь скорей выберет тот звуковой движок, у которого есть и софтварный режим и аппаратный, чем тот у которого только аппаратный.

Ответ: Russian Sound System

Цитата:

* Планируется ли ОО интерфейс, для С++ или других языков? Или только функциональный будет для большей совместимости с разными языками?

Нет. Не планируется.

Цитата:

Что насчет компиляции под Linux или другие платформы? ( я так понимаю в ProjectF только OpenAL и VorbisOGG используется или еще что-то? ).

Собрать под линукс без проблем. Используются только OpenAL и VorbisOGG. Загрузка wav сделана без windows.h

Цитата:

Помнится предыдущая версия ( еще RSS ) вылетала без предупреждения если на компьютере не поддерживался EAX или еще что-то. Вот собственно в ProjectF будет режим без EAX или какой-нибудь софтварный? Ведь не на всех компьютерах есть аппаратная поддержка, и пользователь скорей выберет тот звуковой движок, у которого есть и софтварный режим и аппаратный, чем тот у которого только аппаратный.

Софтварную реверберацию запилить не сложно. Но нужно ли? Creative же сделала эмуляцию EAX'a.