Частота аудио интерфейса в системе 48кГц
Все варианты на output buffer count 4 буффера (больше или меньше не влияют на результат) Контейнер по trigger rate вызывает звук выстрела раз в 100мс
В теории break с задержкой до 99 мс (включительно) должен вызывать только один звук, но тесты показывают что в зависимости от буфера интервал для break-а с одним вызовом выстрела уменьшается пропорционально размеру буфера
По тестам получается такой расклад
буфер в 256 сэмплов - двойной вызов начинается с задержки вызова break 90мс (т.е. от 91мс до 99мс вызывается два звука вместо одного)
буфер в 512 сэмплов - двойной вызов начинается с задержки вызова break 85мс (т.е. от 86мс до 99мс вызывается два звука вместо одного)
буфер в 1024 сэмплов - двойной вызов начинается с задержки вызова break 63мс (т.е. от 64мс до 99мс вызывается два звука вместо одного)
При этом важный нюанс, каждый вызов идеально отрабабатывает break при задержке старта стрельбы по таймингам в 1 буфер
буфер в 256 сэмплов - старт задерживаем на 6мс break (округленная в большую сторону длина буфера в секундах (5,3333333 мс при 48кГц) вызываем через 100 мс Т.е. звук стартует на таймлайне 6 мс, break вызывается на таймлайне 106мс (но в рамках ивента это будет ровно 6мс - старт первого выстрела и 100мс break первого выстрела) - играет 1 выстрел
буфер в 512 сэмплов - старт задерживаем на 11мс break (округленная в большую сторону длина буфера в секундах 10,6666666 при 48кГц) вызываем через 100 мс Т.е. звук стартует на таймлайне 11 мс, break вызывается на таймлайне 111мс (но в рамках ивента это будет ровно 11мс - старт первого выстрела и 100мс break первого выстрела) - играет 1 выстрел
буфер в 1024 сэмплов - старт задерживаем на 22мс break (округленная в большую сторону длина буфера в секундах 21,3333333 при 48кГц) вызываем через 100 мс Т.е. звук стартует на таймлайне 22 мс, break вызывается на таймлайне 122мс (но в рамках ивента это будет ровно 22мс - старт первого выстрела и 100мс break первого выстрела) - играет 1 выстрел
Про лаги стрельбы - часть 1
Итак я все же созрел написать про нюансы таймингов. Готовьтесь к серии (не очень регулярной) отборной порционной духоты
Думаю что все кто работал с автоматической стрельбой сталкивались с проблемой лишних выстрелов и залипания очереди.
Сегодня начнем с ситуации:
1 тап - двойной выстрел
Не все и не всегда это замечают, но бывают такие ситуации что мы тапаем 1 раз, HUD нам рисует расход 1 патрона, вылетает один прожектайл, а слышим мы при этом два звука
Долгие рисерчи привели меня к тому что вся проблема кроется в аудио буфере и том как считаются аудио кадры.
Подкапотные подробности я все еще жду от кинтетиков, так что сегодня пока что без тех базы
Главное! Никаких Sample Accurate MIDI решений (об этом каргокульте в другой раз) для лечения этого городить не нужно.
Просто задерживаем старт лупа с триггер рейтом на размер буфера (аудио фрейма) и получаем нужный эффект
В упрощенном варианте мы просто делим размер буфера (ваши программеры точно знают где взять uNumSamplesPerFrame) на сэмпл рейт системы конечного игрока и вуаля - чистейшие (практически идеальные) ваншоты на один тап.
Почему практически идеальные?
Проблема кроется в специфике таймингов ввайза, а именно в том что он или окргуляет или транкейтит (я все еще жду ответа кинетиков) тайминги меньше 1 мс, в этой связи иногда все же можно вызвать ложное срабатывание.
Условные 5.33 мс буфера у вас станут 6мс задержки. Попадая антапом в этот короткий промежуток от 5.33 до 6мс два буфера успеют посчитаться и уже будет детектиться брейк на второй, уже успевший срендериться SFX.
А ну и дополнительно еще лаги и падение FPS могут слегка подгадить
Главное! В стерильных условиях синглплеера и стабильного FPS с данным сетапом 1 тап будет = 1 выстрелу
Так же важным считаю отметить, что аналогичные проблемы у меня еще появлялись при использовании scatterer sound в FMOD
На сегодня всё
Всем четких ваншотов и стабильных очередей!
Заметки по мотивам презы кинетиков Wwise 2026.1 (Beta 1)
Я уже говорил что немного угнетает их маркетинговый подход и все эти сегменты больше выглядят как продающие свистоперделки
Короче погнали
## Shared Segment
В целом выглядит как треки муз системы
Изобрели компоновку в стиле Fmod
Надеюсь это будет первым шагом по выпиливанию раковых бленд контейнеров
Пропки
- Сегмент - выглядит как все свойства сегментов муз системы (хз что там будет с обычным контентом, скорее всего все что есть в редакторе SFX) + добавлен функционал работы из муз системы
- Track - из того что видно по скринам это или что-то свое или обертка для рандомов, секвенций и свитчей
- Интересно можно ли делать рандом степ или свитч в рамках трека или все же они просто рандом контейнер или свитч натянули. Т.е. под капотом у нас тот же свитч контейнер, секвенция или рандом внутри которых просто пачкой лежат sfx
Скорее всего (и судя по тому что показали) они просто поменяли отображение контента
Каждый SFX это теперь волна на треке
А каждый трек это теперь соответствующего типа контейнер
Из плюсов всего этого я вижу только удобство лееринга т.к. с таймлайном в разы удобнее вместо дилеев работать
Но все же, мне кажется леерить нужно на этапе работы с секвенсором, а не в миддлваре
К тому же хз как они таймлайн с паузой в начале считают как прямой аудио поток или как initial delay вызова контейнера в стандартной версии
Про проблемы рендера тишины, я вроде уже говорил, но на всякий напомню.
Рендер всегда дороже задержки вызова, потому что вы считаете по этому таймингу нулевой сэмплик для каждого голоса с такой тишиной, вместо того что бы просто подождать.
Короче пока выглядит как прогрев гоев с изображением активной деятельности
## Navigation and Selection
Опять интерфейс
Secondary editor - Чем их кастомные табы не устраивали я не понимаю. Ну черт с ним пусть будет второй редактор
Табы для эфектов - какие-то с виду не очень удобные выпадающие списки с байпасом и рендером
## Replay
Надо тестить, но вектор развития хороший
- Replay captured Audio - тут все понятно пишем звук и играем его (никакие правки по горячему на него не влияют)
В фмод было такое, было тухло
Я такое не очень одобряю так как без визуала, это смысла имеет мало
- Simulate API Calls - интересный вариант, но как по мне это нужно писать на уровне движка и воспроизводить хотя бы с записанным видео. В целом это можно считать расширенной версией профайлинг сессии с возможностью воспроизведения всего с убитым движком
- Лупы (зачем-то) - ну ок можно как-то приспособить для сведения в слепую
## Usability
- Music Seek - знаю что многие рады, наконец-то добавили статус клипов как в Ableton
- Новые иконки - это же самое важное? Ведь да?
## Acoustics
- активно тащат на свой тех, но я сторонник того что такие вещи нужно писать под себя (тем более с учетом того сколько проблем я периодически слышу об этом тулсете)
- остальное
- - оптимайз (из того что слышал там больше багов чем проблем с производительностью)
- - новая визуализация геометрии (ну наверное кому-то это очень важно)
Короче 50 на 50
Есть потенциально интересные штуки, но так это стремление напихать побольше продающих свистоперделок каждый год расстраивает...
А вы что думаете? Кинетики действительно пошли не в ту дверь?