Это работает проще, или причем тут архитектуры CPU

Жизнь сообщества
1

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

Для начала представим, что у нас есть некая россыпь файлов. Файлы большие, внутри них находятся данные игры. Формат файлов известен. Начнем тему в формате QnA Вопрос-Ответ.

Вопрос: Как же получить доступ к модели персонажа A, лежащей в архиве B? Неужели этот архив необходимо разжать?
Ответ: А очень просто, и никакие архивы распаковывать для этого не надо. В произвольном месте архива (в каком именно - положено знать загрузчику файла) мы можем разместить своеобразную “карту” архива, где укажем, какие файлы содержатся внутри него, и в каком количестве, да какой они имеют объем. Само собой, все данные отделяются друг от друга отступами. Нам может потребоваться знать отступ от начала архива до модельки персонажа A и объем модельки. В большинстве случаев, модели легковесны, но об этом ниже. Таким образом, мы считываем из файла B по смещению Offset нашу модельку с объемом Len и записываем в буфер. Все, наша моделька прочтена, мы можем делать с ее данными все, что захотим.

Вопрос: Что будет, если мы все-таки станем разжимать архивы с игровыми данными прямо во время игры?
Ответ:
Ничего хорошего для производительности, поскольку алгоритмы, применяемые для упаковки\распаковки могут оказаться крайне ресурсоемкими, учитывая возможное количество данных внутри таких архивов. Распаковка данных станет очень заметна по снизившейся производительности и уменьшению места на диске (кто-то до сих пор игры ставит на системный раздел, и такой человек заметит распаковку данных игры моментально).

Вопрос: Сколько весит игровая модель и почему?
Ответ: Игровые модели, как я уже говорил выше, легковесны. Они могут быть представлены в виде одного файла, либо в виде нескольких. Допустим, у нас есть один файл A_ref и рядом A_anims. Это значит, что в первом файле лежит геометрия модели с различной технической информацией (например, список используемых материалов, которые мы в игре потом видим в виде наложенных на модель текстур с рельефом и светяшками-блестяшками различными), а во втором полный набор трансформаций, которые мы воспринимаем как анимацию, заставляющую персонажа двигаться. Анимации бывают вершинными и скелетными. Вершинная анимация требует больше памяти и используется, преимущественно, для анимации лиц в некоторых игровых движках. В основном, используется анимация скелетная. И та и та весят сравнительно немного, но об этом ниже. Для сравнения: модель в игре Heroes of the Storm может весить 2 мегабайта без учета текстур. То есть, это только ее геометрия и анимации. При желании, разработчик может оставить за собой возможность сжимать данные модели, в том числе геометрию и анимационные последовательности, и записывать их в бинарные файлы, но это уже тонкости реализации и у каждого разработчика свой подход к этому делу.

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

Вопрос: Сколько весят текстуры в компьютерных играх и почему?
Ответ:
Столько, сколько захотите. Реализация зависит от подхода разработчика и от рамок, которые он ставит. Если требуется максимально высокое разрешение текстур, то весить они будут много, а если требуется поскромнее - то и результат выйдет соответствующим. Также, текстуру можно сгенерировать на этапе загрузки игры или уровня в произвольном разрешении, если заранее известен и написан подходящий для ее генерации алгоритм. Тут определенных каких-то ограничений нет. Разрешение текстур героев в HotS, если мне память не изменяет, составляет около 2048х2048 точек. При этом, текстуры окружения куда как скромнее. Текстуры для графического интерфейса пользователя - тоже. В большинстве файлов с текстурами игры хранится также информация об их уровнях детализации, в простонародье названных MIP. Это чтобы память экономить и производительность в игре не страдала, превращаясь в слайдшоу при каждом удобном случае.

Вопрос: А причем в компьютерных играх архитектуры центрального процессора?
Ответ:
Разработчик в праве компилировать свою программу под любую процессорную архитектуру, под которую у него есть подходящий компилятор. Компилируя проект под большее количество архитектур, разработчик охватывает большую аудиторию своего продукта. На самом примитивном уровне, компиляцию под ту или иную архитектуру означает банальную возможность запустить продукт под операционной системой, заточенной для использования с процессором такой-то архитектуры. 64-разрядная архитектура позволяет быстрее выполнять код, написанный для 32-разрядной архитектуры и оперирует числами большей длины, что позволяет повысить точность и скорость в сложных расчетах. Большинство игроков этого всего может просто не заметить, поскольку разработчики игр всегда стремятся достичь максимальной производительности, тогда как подобная точность важна для совершенно иных задач, которые рядовой пользователь перед своим компьютером даже не поставит. В играх точность расчетов никогда не является идеальной, и это обстоятельство позволяет повысить производительность в игре.

Вопрос: Чем в процессе игры занимается центральный процессор?
Ответ:
Центральный процессор во время игры играет (пардон за тавтологию) роль менеджера, выдающего всем вокруг себя задания. За заданиями к нему выстраивается очередь, и CPU ее призван контролировать, направляя в один или в несколько потоков. Но, в случае с несколькими потоками на него также ложится задача синхронизировать данные между ними. Например, в одном потоке у нас физика, а в другом графика, а в третьем звук. Предположим на простом примере, что нам нужен падающий мяч со смешным звуком. В потоке с физикой у нас есть физическая модель мяча - пресловутая коллизия в форме сферы. Во втором потоке у нас графическая модель мяча - сфера с текстурой и эффектами, висящая над землей. В третьем потоке у нас задача воспроизвести звук сразу, как только мяч приземлится. Без синхронизации мы получим, что физическая модель мяча упала и приземлилась, графическая модель мяча осталась висеть в воздухе, а звук прозвучал до падения. Это я еще утрирую, поскольку в реальности программа может просто упасть без выполнения, если не случится синхронизации. Синхронизация, как раз-таки, необходима для того, чтобы все случилось в свое время. Поэтому, процессор видит падение физической модели и передает ее текущие координаты модели графической, и та движется вместе с физической моделью. Далее, физическая модель сообщает процессору о своем столкновении с поверхностью, и тот уже дает команду третьему потоку воспроизвести звук. И все это производится в цикле, например - 60 раз в секунду, или чаще. Частота синхронизации может быть привязана к частоте кадров, а может и не быть привязана к ней. В зависимости от того, какую реализацию выбирает разработчик, так она и работает. Примерно так функционирует многопоточность в компьютерных играх, и появилась она еще до начала нулевых.

О чтении игровых данных

Когда мы говорим о доступе к игровым данным, мы можем поступить множеством различных путей. Например, мы можем единожды открыть для чтения архив или пак и не загружая его целиком в оперативную память загружать из него только нужные данные, руководствуясь его картой. Также мы можем, пользуясь все той же картой находить нужные нам данные и разжимать только их. При этом, файл архива\пака в память целиком не грузится, игра работает только с данными, лежащими на диске. Есть и другие пути добиться того же результата. А все, собственно говоря, почему? Раньше игры тоже были разными, очень разными и их данные могли занимать, скажем, 700 мегабайт пространства на жестком диске притом, что у пользователя, скажем, оперативной памяти было только 32 мегабайта а то и меньше. Если взять сегодня и распаковать все данные какой-нибудь игры того времени, мы можем получить в некоторых случаях около 2 гигабайт данных, и большую часть из них занимают текстуры, музыка, звуки, видео, лишь малая часть уходит на геометрические модели окружения, персонажей и так далее. Разумеется, компьютерная игра не располагала возможностями грузить в память сразу все данные, ведь для нее производительность стоит на первом месте. Чтобы ограничить расход памяти решили загружать только те данные, которые нужны на определенной карте в определенный момент времени. Ну и еще кучу других оптимизаций использовали вроде собственного менеджера памяти, отсечения невидимых игроку поверхностей и всякого такого. Ввиду необходимости разжимать данные, приходилось тщательно следить за расходом оперативной памяти, иметь собственный пул и всякое такое. Между уровнями частенько все ненужные данные из памяти подчищались, а на их место загружались новые. На компьютерах того времени по ряду причин, включая необходимость разжимать данные, загрузка того или иного уровня могла занимать приличное количество времени. Сегодня мы этого не замечаем, поскольку и скорость чтения жесткого диска стала выше и современные процессоры успевают провернуть все необходимые операции, включая тот же decode, намного быстрее. Также, спасибо надо сказать разработчикам библиотек вроде той же zlib за оптимизацию.

И также, исходя из этих и прочих знаний об алгоритмах компьютерных игр, я глубоко сомневаюсь, чтобы HotS, основанная на движке Starcraft II, вышедшей вот уже около 8 лет назад (а ее технологическая основа закладывалась и того раньше - как минимум, за несколько лет до выпуска игры и может основываться на переработанном коде движка Warcraft III вышедшего еще раньше) организовывала работу с медиа-контентом как-то иначе. Но, как показывает практика применения конечного продукта, а именно - игры HotS, она не выгружает данные ранее подгруженной карты из оперативной памяти, а держит там на случай, если они скоро потребуются вновь. И при этом она не выходит за рамки использования 4 гигабайт оперативной памяти, даже будучи запущенной в разрешении 4K.

4 лайка
2

UPDATE

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

Ладно, подустал я потакать вашим капризам. Давайте я разом напишу все, что думаю насчет ваших выкладок. Кому надо из читателей – дочитают, решат для себя кто прав. Если вы, конечно, не сотрете тему и не исправите все написанное вами, не нарегаете ботов и не налайкаете себя (вы же не хотите санкций от близов за это, нет?)… Правда, есть тут такая штука, как история редактирования. Ну и запись никто не отменял, скрины. Ну, вы поняли.
Это не отменяет вышенаписанного про суперпозицию, вам стоит серьезно над этим подумать. Как и над следующим. Ответа не жду, а если будет - не смотрю. Имею ровно такое же право так сделать, как и вы, категорично отказав мне в обсуждении винды, без комментариев. Собственно, я мог и не заморачиваться, но по мне так лучше попробовать образумить человека.

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

  1. понимаете ли вы суть вопросов или просто зазнаетесь и много на себя берете, пытаясь отвечать.
  2. знаете ли вы ответ.
  3. как вы будете исправлять свой ошибочный или неточный ответ.

Пункты 1 и 2 я комментировать не буду. Но признавать ошибки вы не умеете. Более того, сознательно или нет, но все же вы включаете режим “обижусь на что-то”, “прицеплюсь к словам, хотя значение однозначно”, “сам буду употреблять обороты, трактуемые двояко и вообще ряд неверных”, хотя я говорю достаточно вежливо и этично, считая собеседника специалистом, исправляю слова на те, которые вы считаете правильными вне зависимости от того, считает ли ваш вариант верным большинство научного сообщества.

В конечном счете, у меня есть такое CASC хранилище, где медиа-ресурс сжат целиком без разбивки. Приводить его я не считаю нужным, так как мне не дадут нобелевку за публикацию таких “невероятных” сведений – это общеизвестный факт. Более того, кроме такого примера у меня есть и свой, который корректно читается и декодируется на тех же условиях. Хочется пруф - гуглите или сделайте сами, вы говорили, что вы - опытный разработчик, а такой пример может сделать даже студент начальных курсов.

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

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

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

Пять. В соседней теме вы не привели ни одного пруфа того, что хотс не держит в ОЗУ модельки/отрисованные модельки/текстуры/любые ресурсы из своей CASC, в то время как я показал косвенно, что занимаемый размер в ОЗУ аномально большой. Тем не менее, вы считаете, что, не зная кода игры, не зная о том, является ли текущий размер хотса в озу штатным или это следствие бага, вы говорите, что, разработчик на опыте и потому знаете, как обстоят дела. Лучше бы применили здесь свою суперпозицию и сказали, что все это там одновременно хранится и не хранится, так как наличие опыта не говорит ничего о стороннем проекте, который делали не вы, вне зависимости от того, есть ли исходники старого движка похожей игры или нет.

Шесть. Вы передергиваете и подменяете понятия.

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

Восемь. “Что будет, если мы все-таки станем разжимать архивы с игровыми данными прямо во время игры? Ничего хорошего для производительности, поскольку алгоритмы, применяемые для упаковки\распаковки могут оказаться крайне ресурсоемкими”. Из вышеизложенного факта того, что есть сжатие, получается, что если ресурсы хотса упакованы, а весит хранилище в запакованном виде 21 гб, плюсуя туда и музыку, и ролики, и все остальное, а держать все в памяти нельзя, то выходит, что хотс все-таки постоянно читает и распаковывает необходимые в текущий момент ресурсы… Возможно, он не читает хедеры и дескрипторы все время, так как в casc нет в этом смысла, но сжатые данные по дескрипторам для отрисовки надо-таки разжать… А диск для хранения разжатого не используется… Потому если хотсу нужны ресурсы при создании матча лиги героев, например, он обратится к сжатым ресурсам по дескриптору и разожмет их. А знаете почему вообще задались вопросом изменить старый формат хранения и перейти на CASC? Потому что именно использование CASC сокращает время, необходимое на постоянную распаковку и подгрузку ресурсов именно благодаря этой самой карте дескрипторов сжатых ресурсов, по которой он знает, что подгрузить. Снова вы неверно ответили.

Девять. “На самом примитивном уровне, компиляцию под ту или иную архитектуру означает банальную возможность запустить продукт под операционной системой, заточенной для использования с процессором такой-то архитектуры” - а что вы так упрощаете? Это же недопустимо. Я не буду говорить почему. Шучу, я же не вы, я сразу скажу, что мне не нравится упрек в мою сторону о недопустимости упрощения, а вы сами - упрощаете.

Десять. “Чем в процессе игры занимается центральный процессор?” “Но, в случае с несколькими потоками на него также ложится задача синхронизировать данные между ними”. А в случае временнОй многопоточности? Давайте вы не будете только говорить, что таких реализаций мало, что под них нет игр… Вы же решили поговорить о Mac OS когда я прямо указал, что мой вопрос касается строго Windows и после трех моих просьб после этого говорить о винде вы тоже не передумали, да еще и в грубой форме. Раз хотите обобщать - расскажите тогда и про то, как обстоят дела с многопоточностью, играми, и временнОй сложностью. А потом потрудитесь объяснить почему в пунктах настройки графики хотса имеется несколько таких, которые, как заявляет близзард, зависят именно от процессора. Только без самомнения пожалуйста, а то как в соседней теме ответите, мол, “на заборе тоже написано”.

Одиннадцать. Претендуете на то, что вы специалист, а не дилетант, ведите себя как ведут себя специалисты. А то пока прослеживается какая-то суперпозиция - затрудняюсь решить кто вы. Удачи вам.

Смотрите. У меня к вам вопрос. Представьте ситуацию, когда архив читается в память целиком и распаковывается в памяти так, что там остается и запакованный архив и распакованный. Тогда по этапам:

  1. Есть данные архива в виде байт, лежащие на диске. Данные D1.
  2. Есть данные архива в памяти (если прочесть его целиком) - D2.
  3. Есть данные архива в памяти, с наложенным преобразованием Decode - D3.
    Соотнесите, пожалуйста, эти три переменные. Равны ли они, какие-то может быть больше, какие-то меньше?

Если нам удастся найти общий язык, то я уверен, что будет целесообразно задать и другие вопросы по другим пунктам. А пока только один.

Лайков: 1
3

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

Для игры любой прочтенный файл суть есть поток, который можно представить и использовать произвольным образом. Можно загрузить в оперативную память содержимое файла целиком, можно только его часть. Компьютерные игры частенько читают большие файлы частями, загружая только небольшие кусочки данных. Так делать банально быстрее, чем загружать все данные игры в оперативную память, которой может оказаться значительно меньше, чем весят эти данные. Предположим, мы его загрузили, это и будет наш

Можно в память загрузить все содержимое отдельного архива - модели, текстуры, и так далее. Предположим, это и есть наш

Тогда как файл на диске это у нас

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

4

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

Нет, все поясню последовательно.

5

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

6

Понимаете, дело в том, что данные D1 и D3 не просто различаются по содержимому, но и D1 много меньше D3 в общем случае, не завися от того, где и как распаковывается. Это суть архиваторов. Потому когда вы говорите

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

Вопрос 1. Согласны ли вы с этим?
Я понимаю, что разные движки могут работать по-разному и некоторые могут не использовать encode и decode.

Вопрос 2. Согласны ли вы с тем, что я понимаю, что DECODE - не везде и не всегда?

7

На мой взгляд, это очевиднейшая вещь.

Не упускаю. Как минимум, я об этом уже писал здесь:

Внимательнее нужно быть.

Такие механизмы тоже существуют и очень давно. Они также распространены в игровой индустрии.

Я согласен с тем, что данные неизбежно будут различаться.

Вижу, что понимаешь.

8

Спасибо. Я имел в виду, что в ваших рассуждениях в шапке топика этого нет, к тому же приписал, что не буду вникать до конца в ответ, так как… Ну вы помните, я хотел абстрагироваться.

Я об этом не спорю. Есть и распространены.

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

9

Целенаправленно опустил.

10

Понятно.
Тогда раз мы говорим об играх, то давайте поговорим предметно о следующем моем вопросе (после него возможно снова в абстракцию уйдем, как знать). Поговорим строго о хотсе.
Вопрос 3. Вы согласны, что формат хранения моделек хотса - это формат https :// en.wikipedia .org/wiki/MPQ_(file_format) ?
Вопрос 4. Вы согласны с тем, что практически наверняка эти данные в хотсе - сжаты?

11

И да и нет. В HotS используется формат CASC. Непосредственно модели в HotS имеют формат M3, отличающийся от формата, использованного в игре Starcraft 2.

И да и нет. Во многом по причине высокой скорости работы с этим файловым форматом. Надо будет перечитать его спецификацию, чтобы ответить утвердительно.

Лайков: 1
12

Допустим. Но существуют обсуждения на специализированных форумах о рипе данных моделек из хотса и в обсуждениях фигурируют факты того, что люди используют редактор www. zezula .net/en/mpq/ для того, чтобы доставать/изменять модельки конкретно хотса. Есть примеры того, как оттуды вынимали карты, как их изменяли. Но вы справедливо заметили, что в нашем случае - CASC (на веру вашим словам), хоть он и пришел на смену MPQ. Тогда поговорим о нем.
В заголовке .XXX файла с данными первые значения - это Encoding key of the file.
Вопрос 5. Считаете ли вы, что это ключ, с помощью которого производится DECODE/DECRYPT моделей хотса (в данном случае опускаю идеалогическое значение слова “ключ” и слова “шифрование”, так как говоря об архивировании шифрование тесно связано с самим архивированием и не всегда можно обосновать где архивирование, а где шифрование, а сейчас в этом мы разбираться не будем) ?
Вопрос 6. Считаете ли вы, что в файлах хотса на данный момент есть этот ключ в заголовке?
Вопрос 7. Считаете ли вы, что этот ключ на данный момент используется по назначению с файлами хотса, т.е. участвует в процедуре DECODE тогда, когда этого просит движок?

13

Есть альтернативные редакторы специально для HotS.

Согласно имеющейся в Сети информации, CASC-файлы используются в качестве контейнера (утверждено в его названии) для объектов. Он стримится (как и архивы у Unreal Engine), обладает возможностью к расширению, высочайшей производительностью при работе с ним, и прочее и прочее. Так как к настоящему моменту я лично ознакомился со спецификацией формата лишь мельком, забегать с выводами не стану сильно вперед. Все может быть, так что и да и нет.

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

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

14

Абсолютно согласен.

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

Не обязательно так категорично. Достаточно взять файл и не вскрывая его подгрузить абсолютно все модельки из него, “подгрузить всю музыку” и т.д., а затем сравнить полученный размер с размером на диске. Я полагаю, что зная о различных редакторах конкретно для хотса вы умеете подобное делать, особенно учитывая, что вы, по словам ранее, имеете отношение к игропрому. К тому же, существует много подтверждений тому, что данные файлы сжаты на иных ресурсах (подтверждения на иных сайтах, имелось в виду это), отличных от этого.
Вопрос 8. Считаете ли вы достаточными подтверждения от других людей, которые уже залезали “внутрь” данных файлов и заявляют, что конкретно в этом случае - они сжаты?

По поводу проверки я задал вопрос 8. По поводу того, что параметр может использоваться иначе.
Вопрос 9. Вернее цепочка вопросов. Как по вашему этот параметр может использоваться и почему вы посчитали, что он может использоваться иначе? Ни в одной документации по формату и документации по работе с данным форматом не указано конкретно для каких целей данное поле? Если ответ на последний вопрос - “да, не указано однозначно”, то можно интерпретировать снова ваш ответ таким образом, что вы не знаете на данный момент, сжимаются файлы хотса или не сжимаются?

15

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

Отказываться от ответственности перед Blizzard я не собираюсь, чай не маленький уже. Но, допустим, я уже поинтересовался у людей, готовых мне помочь с установлением некоторых фактов и узнал вполне определенные сведения, такие как:
– Базовая модель персонажа N весит что внутри архива 404кб, что снаружи.
– Диффузная текстурка этого же персонажа весит 683кб и там и там.
Явно показания не в пользу того, что CASC-файл это архив. Скорее это и есть тот самый контейнер без сжатия, так что DECODE тут не используется.

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

Опыт и годы практики, в течение которых я насмотрелся всякого кода и увидел невероятные вещи. Там порой такие вещи проскакивали во вполне рабочем коде большого коммерческого проекта, из разряда “смех сквозь слезы”. Вроде серьезный проект, а кто-то взял и отчебучил. Обойдусь без подробностей, поскольку коммерческая тайна.

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

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

16

Смотрите. Ответа может быть три: сжатие есть, сжатия нет, не знаю. Отказаться - не значит найти еще один ответ. У вас есть знания, которыми можете пользоваться, вы вполне можете использовать документацию и делать умозаключения. Основываясь на них можно смело сказать что-то вроде “я знаю это, потому да/нет” или “я не достаточно знаю на данный момент, чтобы что-то ответить”. Ваш отказ склоняется ко второму варианту. Вы согласны?
Кроме того, существует вот такая вещь. Это один из множества рабочих примеров. aHR0cHM6Ly90aW55dXJsLmNvbS95YWxicHVvMg==
Предлагаю изучить часть документации касательно заголовка “Data”, перейдя по ссылке, скрытой за base64. Считаете ли вы, что в строке
data.XXX files contain the compressed files themselves, along with small headers определено достаточно однозначно, что CASC сжатие использует? Считаете ли вы, что по названию проекта очевидно, что применимость данной документации к настоящим файлам с моделями очень вероятна?
Считаете ли вы, что как следствие - вполне можно считать, что если мы еще не определились с тем, есть сжатие или нет, то наличие сжатия как минимум очень вероятно, так как:

  1. упоминается во многих документациях
  2. упоминается безоговорочно, т.е. без возможности “не сжимать”
  3. на основе кода из проектов, которые приводились в пример, можно судить, что операция decode/decrypt как минимум существует

?
Не считаете ли вы случайно, что весь код, все примеры иного кода в сети, все примеры людей, которые “заглядывали внутрь” - это все ошибки?

В догонку к:

А как разница размера доказывает факт того, что сжатия нет? Вы утверждаете, что в данном случае D1=D3, отбрасывая заголовочные данные?

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

Ну мы же не говорим о различных ревизиях. У нас есть конкретная. И знающие люди у обоих, которые могут проверить. К тому же, отсутствие чего-то в конкретной документации не означает, что этого нет в коде. Вы же согласны с этим? Тогда корректнее остановиться на том, что это - необязательный параметр, если об этом прямо сказано. Можете мне предоставить документацию, в которой прямо сказано, что это необязательный параметр? И если да, то как вы объясните тот факт, что проекты, использующие парсинг данных файлов в хотсе используют функцию decode, что легко подтвердить, открыв ida pro, например, если уж нельзя делать отсылки к исходникам? Данный вопрос был от знающих людей.

Предложение дискутировать далее было чутка выше, не дублирую.

17

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

Выглядит именно так.

Вероятность присутствует, отрицать не буду.

Отнюдь.

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

А вот это извечная история из моей практики. Мимо документации частенько очень яркие вещи пролетали, по разным причинам.

Мне такая документация не попадалась.

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

18

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

19

В CASC файлах каждый фал разбивается на блоки и каждый блок может быть зашифрован ил не зашифрован и сжат или без сжатия.
https ://wowdev.wiki/BLTE

Смотреть всё что DATA

20

Супер. Таким образом, знающим людям достаточно проверить вот этот факт, чтобы понять, используется ли DECODE на конкретно файлах хотса, верно?
N: Plain data.