Comments 22
Понять бы ещё анатомию того же Геншина. Аудиоархивы обфусцированы вдоль и поперёк, найти нужный файл среди кучи "номерков", да ещё и расшифровать его - та ещё головная боль. Уже несколько месяцев пытаюсь разыскать единственный звуковой эффект...
а вы не пробовали
1) записать этот эффект на внешний микрофон (с мобильного)
2) поискать записанный звук среди номерных ? (хоть самописно - для этого куча алгоритмов есть, хоть готовыми решениями, типа такого https://www.alldup.de/en_download_alldup.php)
Этот звук в абсолютной тишине выловить нереально. Это звук именно HUD'а, и срабатывает он только посреди всего остального шума. Какого "качества" будет этот звук, если его хватать ещё и третьими средствами, я, пожалуй, умолчу...
А если записать программными средствами весь звуковой поток, который подаётся на звуковую карту? Думаю если удастся поймать нужный звук посреди шума и отдельно в чистом виде звуки шумов, то вычитая одно из другого может получиться выделить чистый интересующий звук.
а вам не нужно найти 100% совпадение, вам должно быть достаточно получить из аудио с шумами маркеры вашего нужного эффекта - так чтобы потом (например)
1) нарезать записанный звук-с-шумами на кусочки 100-200мс
2) найти спектр частот (привет БПФ), отфильтровать нижние\средние\верхние (чтобы оставить как можно больше нужного эффекта и убрать лишний сигнал с шумом), нормализовать\бинаризировать компоненты полученного вектора (снижаем порог совпадения - нам не страшны ложноположительные, главное - чтобы не было ложноотрицательных исходов)
тупым перебором поискать, какие номерные звуки имеют похожие на ваши кусочки участки - чем больше совпало кусочков на одной записи, тем лучше, если они попарно последовательные (т.е. 101,102,103) то вообще отлично
и потом уже вручную поискать среди найденных.
Аудио хранится в Genshin Impact\Genshin Impact game\GenshinImpact_Data\StreamingAssets\Audio\GeneratedSoundBanks в .pck архивах. Напрямую формат вроде никто не разбирал, но как минимум есть скрипт для QuickBMS.
Я уже минимум тремя разными скриптами для QuickBMS, включая базовый wavescan, прошёлся по этим банкам, перерыл уже больше 12к файлов совокупно. No dice. Видимо, придётся запрашивать помощь у тех, кто на этом собаку съел, тем более что многие из них пишут, что файлы с каждым новым патчем шифруются как-то по-новому. Головная боль, в общем, с этим Wwise.
А что если бы наоборот, не шифровать свои творения, дабы права защитить. А делать их максимально открытыми. Да ещё инструменты создать по переделке своей игры. Это даже некий спорт получится, творческий. Каждая следующая версия/ветка может быть интереснее.
Nintendo и им подобные удавятся раньше, чем даже задумаются об этом.
Следующий шаг -- создать нейронку для переделывания игр(ы).
<joke>Тогда, получается, разработчики уже не будут нужны</joke>
Посмотрите Neverwinter Nights, например. Они как раз так и делали. И до сих пор люди создают свои модули по этой игре.
Я всячески приветствую подобные по смыслу статьи (так как в своё время именно с них я и начинал изучать реверс), но есть несколько серьёзных поправок.
Упаковка файлов в архивы служит для нескольких важных целей: a. Абстракция от локальной файловой системы — это упрощает портирование, позволяет обойти ограничения (например, максимальную длину путей, число файлов в директории и т.д.) b. Можно добавить метаданные (зависимости, приоритет загрузки и т.д.) c. Возможность отобразить архив в память, что кратно ускоряет доступ к подфайлам (более эффективное кэширование) d. Возможность сжатия большого числа данных сразу (более эффективно, чем отдельных маленьких файлов)
То есть, игровой архив — это эффективная упаковка ресурсов для конкретного движка.
Про DDS информация сильно упрощена и не очень правильная.
Это межплатформенный формат текстур с блочным сжатием. То есть, в отличие от форматов изображений общего назначения он изначально рассчитан на использование для текстур. Блочное сжатие аппаратно ускорено на видеокартах, так что такая текстура сразу загружается в VRAM и распаковывается на лету при обращении к пикселям, то есть, экономится не только место на диске, но и в видеопамяти. Тот же JPEG в этом плане сильно неэффективен, так как хотя изображение на диске будет сильно меньше, для использования в видеокарте его придётся распаковать в сырые пиксели. Для стандартного RGB изображения DXT1 кодирует блок 4х4 пикселя в 8 байт, т.е. ровно в 6 раз.
Естественно, что реально DXT вариантов сильно больше, да и DXT3 — это разновидность DXT1 с альфой; DXT10 - вообще не формат, а указание на более новый заголовок с поддержкой большего списка вариантов сжатия. См. S3TC/BCn/DXTn и спецификации DDS https://learn.microsoft.com/en-us/windows/win32/direct3ddds/dx-graphics-dds-pguideПро "многоэтажную компрессию" - сильно, но оно работает немного не так. Эффективно сжатые данные повторно сжать не получится, поэтому правильнее вложенные контейнеры - сжатие наверняка выполнено либо на самом высоком, либо самом низком уровне.
То, что мы видим в Noesis и что реально в архиве - очень разные вещи. Например, очень многие движки адресуют файлы по их ID (тот же Skyrim оперирует именно хэшами в консоли). Но это уже детали внутренней реализации архивов.
Если мы откроем какую-нибудь компьютерную игру 80-х годов выпуска (например, почти любую игру Super Mario Bros),
Но как? Марио же никогда не выходил на ПК, а ромы для эмуляторов это совсем другая сущность
Спасибо за статью. Как раз недавно думал над тем, как запаковывают ресурсы игры.
И, пользуясь случаем, спрошу: а как влияет на производительность архивация игровых файлов? Ведь, наверное, один большой архив проще считать один раз в ОЗУ и там с ним работать, чем кучу раз обращаться к диску за маленькими файлами. А какие еще могут быть оптимизации при архивации (которые именно ускоряют/упрощают работу с ресурсами, а не просто экономят место)?
Спасибо за такой вопрос!
В зависимости от шифрования конкретного архива и размера этого арзива на производительность игры это может влиять по-разному
Допустим, игра небольшая, и тогда действительно один крупны архив будет проще держать в памяти ОЗУ, чем обращаться к нескольким маленьким, загружая и выгружая их
Но в случае с большими проектами, содержащими разнородные ресурсы и большое количество моделей, проще иметь несколько архивов, соответствующих биомам или локациям. Так, при перемещении из одной зоны в другую раньше был необходим экран загрузки как раз для того, чтобы дать ОЗУ время выгрузить одни архивы и загрузить другие
Сейчас этот вопрос (количества архивов) стоит не так остро из-за того, что электроника сильно продвинулась вперед, поэтому запаковывать один большой архив или много маленьких теперь вопрос вашей файловой системы (некоторые все еще с трудом читают цельные архивы по 10+ гб) и конкретного инструмента запаковки. Ну и удобства разработчика, конечно
Например, в играх From software над архитектурой, доспехами и монстрами работали разные художники, поэтому удобнее (скорее всего) было разделить эти архивы по рабочим группам)
Анатомия игры: строение файловой системы на примере Elden ring и не только