Видя исходный код я однозначно могу сказать, что происходит с данными разрабатываемого проекта. Загляну и в функцию decode на всякий пожарный.
Нет, не нужна. Исходники нашел, изучаю, и они убедительнее других доказательств говорят обо всем.
У тебя слишком рваные посты и мне не совсем понятно кто и что должен проверить? Для каждого блока любого файла может использоваться любой режим. Я даже больше скажу для хранения тонн xml-файлов там повсеместно идёт один блок и сжатие. Давай уже руби правду матку, как сложно и трудоёмко распаковывать zip архивы.
Лайков: 1
Не знаю какую правду-матку вы хотите, но мы сейчас выясняем хранятся ли файлы, содержащие модели хотса, в сжатом виде. Дело в том, что по политикам близов действия над этими файлами наказуемы, потому чтобы не делать эти действия нам самим - мы попросили знающих людей с обеих сторон проделать это. Пока информация противоречивая.
Господи ты боже мой. Считай что они хранятся в сжатом виде. Дальше что? И да если ты в России, то ты можешь забить болт на приписку что нельзя распаковывать ресурсы и делать дизассемблирование файлов, потому как у нас это разрешено, если ты никому не даёшь результаты своих действий. Т.е. если ты не даёшь всем на данные из архивов и не показываешь код, то ты не виноват.
Лайков: 1
Ну речь про санкции близов инициирована не мной, я лишь повторяю, чтобы не казаться грубым. Мне не лень.
Ну а если считать, что они хранятся в сжатом виде, то это противоречит тому, что написал МистерЧ, так как модели в сжатом виде необходимо не только прочитать, но и разжать. Про производительность и какая сторона вопроса этим занимается я не говорю, но про сжатие сейчас - принципиальный момент и я хочу, чтобы мы пришли к единому мнению, сжаты они или нет. Пока были все три варианта: они сжаты, они не сжаты, нам неизвестно.
А принципиально это потому что это написано первым пунктом ответа на вопрос:
И ответ:
Меня эта нестыковка смущает. Но чтобы все было точно и культурно - я спрашиваю издалека.
Вопрос: Что такое редактор компьютерной игры и для чего он нужен?
Ответ:
Наверное, правильнее было бы выразиться даже не редактор компьютерной игры, а пакет разработки. Это такой инструментарий, позволяющий добавлять в игру различный новый функционал и контент. Как правило, в такой пакет инструментов входят:
– Плагины для пакетов трехмерного моделирования и анимации, позволяющие переносить в игру новых персонажей.
– Редактор карт - приложение, позволяющее сооружать новые карты\уровни для игры, проверять их на ошибки, настраивать игровые события на них.
– Приложение, либо модуль редактора карт, где можно создавать новых персонажей и настраивать их поведение в игре.
Вопрос: Каким же образом настраиваются события и поведение персонажей в игре, если код игры уже скомпилирован?
Ответ:
Для этой цели существует язык внутриигровых сценариев, в простонародье называемый скриптами. Обычно на таком языке целиком пишется логика игры. Подобный подход нередко критикуют за то, что эти внутренние сценарии выполняются слишком медленно, за ограниченный функционал, и так далее, однако пока лучше и гибче ничего еще не придумали. Та же технология BluePrint в Unreal Engine 4 работает за счет остатка легендарной системы UnrealScript из предыдущих поколений движка.
Я знал, что мы к этому в итоге придем.
Изучение мной исходников говорит в пользу сжатия.
Это не нестыковка. Но мы до этого еще дойдем.
Хорошо. В таком случае этот факт зафиксируем. Мы же не ожидаем дополнений на этот счет?
Адд-онов к моему мнению пока не предвидится.
Вообще, модельки персонажей из HoTS-а уже выдёргивали и переносили их в какие-то самодельные ролики на движке Source. По сути, движок HoTS-а сделан на движке второго Starcraft-а, скорее всего и структура у них одинаковая.
Лайков: 1
Так их вроде до сих пор переносят. Весной проверял наборы моделек, ±все персонажи там были. Сейчас, скорее всего, и Малганис найдется.
В своё время возился с файлами Warcraft III, добавлял свои модели и текстуры. Был даже официальный плагин для 3D Studio Max-а, который позволял конвертировать max-овские файлы в формат третьего Warcraft-а. Сами же Warcraft-овские файлы хранились в архиве с расширением MPQ. В Starcraft II такие инструменты вроде тоже есть, но я уже не помню, какие там расширения, архивы, давно не ковырялся в этом.
Лайков: 1
Понятно.
Тогда ожидаю:
Если вы имели в виду, что инициатива дойти на вашей стороне. Если нет, то продолжу сам.
Когда мы говорим о доступе к игровым данным, мы можем поступить множеством различных путей. Например, мы можем единожды открыть для чтения архив или пак и не загружая его целиком в оперативную память загружать из него только нужные данные, руководствуясь его картой. Также мы можем, пользуясь все той же картой находить нужные нам данные и разжимать только их. При этом, файл архива\пака в память целиком не грузится, игра работает только с данными, лежащими на диске. Есть и другие пути добиться того же результата. А все, собственно говоря, почему? Раньше игры тоже были разными, очень разными и их данные могли занимать, скажем, 700 мегабайт пространства на жестком диске притом, что у пользователя, скажем, оперативной памяти было только 32 мегабайта а то и меньше. Если взять сегодня и распаковать все данные какой-нибудь игры того времени, мы можем получить в некоторых случаях около 2 гигабайт данных, и большую часть из них занимают текстуры, музыка, звуки, видео, лишь малая часть уходит на геометрические модели окружения, персонажей и так далее. Разумеется, компьютерная игра не располагала возможностями грузить в память сразу все данные, ведь для нее производительность стоит на первом месте. Чтобы ограничить расход памяти решили загружать только те данные, которые нужны на определенной карте в определенный момент времени. Ну и еще кучу других оптимизаций использовали вроде собственного менеджера памяти, отсечения невидимых игроку поверхностей и всякого такого. Ввиду необходимости разжимать данные, приходилось тщательно следить за расходом оперативной памяти, иметь собственный пул и всякое такое. Между уровнями частенько все ненужные данные из памяти подчищались, а на их место загружались новые. На компьютерах того времени по ряду причин, включая необходимость разжимать данные, загрузка того или иного уровня могла занимать приличное количество времени. Сегодня мы этого не замечаем, поскольку и скорость чтения жесткого диска стала выше и современные процессоры успевают провернуть все необходимые операции, включая тот же decode, намного быстрее. Также, спасибо надо сказать разработчикам библиотек вроде той же zlib за оптимизацию.
И также, исходя из этих и прочих знаний об алгоритмах компьютерных игр, я глубоко сомневаюсь, чтобы HotS, основанная на движке Starcraft II, вышедшей вот уже около 8 лет назад (а ее технологическая основа закладывалась и того раньше - как минимум, за несколько лет до выпуска игры и может основываться на переработанном коде движка Warcraft III вышедшего еще раньше) организовывала работу с медиа-контентом как-то иначе. Но, как показывает практика применения конечного продукта, а именно - игры HotS, она не выгружает данные ранее подгруженной карты из оперативной памяти, а держит там на случай, если они скоро потребуются вновь. И при этом она не выходит за рамки использования 4 гигабайт оперативной памяти, даже будучи запущенной в разрешении 4K.
Согласен.
В таком случае согласны ли вы, что в общем случае при использовании сжатия для работы с ресурсами движок обязан выполнить следующие шаги (не претендую сейчас на порядок и наличие/отсутсвие других шагов):
- считать данные с диска в ОЗУ, которые будут разжиматься, ЛИБО, если данные сжаты поточным алгоритмом, не требующим наличия всех блоков в ОЗУ, считывать их поточно по необходимости. Если данные сжаты целиком, то считать целиком, если сжата необходимая модель, то считать только данные необходимой модели. Считанные данные в ОЗУ для случая, когда нет поточного сжатия, назовем Encoded_data. Данные, которые можно распаковывать не храня их в ОЗУ целиком, назовем Encoded_stream.
- Получить из Encoded_data/Encoded_stream данные модельки с помощью операции DECODE. Понимаем, что операция DECODE МОЖЕТ реализовывать и чтение с диска, но на рассуждение это не влияет, так как в итоге будет и чтение, и декодирование, т.е. разжатие данных. Чтобы не путать DECODE с реализацией чтения с диска назовем операцию разжатия extract, таким образом окончательно определив DECODE с реализацией чтения как READ + EXTRACT.
- Полученные данные с помощью EXTRACT присутствуют в ОЗУ целиком (сразу после, мы не говорим о том, сколько времени) до тех пор, пока не решено будет произвести операции с этими данными, например, поместить их в видеопамять или что-либо еще, для чего их читал движок игры.
Т.е. согласны ли вы с тем, что в общем случае движок игры с наличием сжатия ресурсов соответствует этим трем пунктам? А если еще короче, согласны ли вы с тем, что распаковываемые в конкретный момент данные в общем случае после распаковки порождают распакованные данные, которые, в свою очередь, хранятся в ОЗУ (или в файле подкачки) до определенного момента, который определяет движок?
Если вы не согласны с каким либо пунктом - просьба развернуто указать на то, с чем несогласны и что является основанием для несогласия.
Не берусь задавать вопросы по выкладкам далее, так как будет каша, сначала с этим вопросом.
Движок разжимает нужные ему данные по мере подгрузки. Перешел на нужную позицию в файле - считал и одновременно с тем разжал.
Это работает не так. Операция decode уже выполнена при чтении нужного сегмента файла, а полученные данные можно направить куда угодно. Если считаны данные модели, они обрабатываются определенным образом. Если считаны данные текстуры, звук, музыка, или что-то еще, следует соответствующая обработка этих данных.
И да, и нет, поскольку движок может считывать определенный тип медиа-контента частями. Ярчайший тому пример - технология Megatexture в игровых движках id Tech. Упрощенно говоря, там используется технология огромнейшей текстуры около 128 000 х 128 000 точек. Это притом, что она в действительности не одна, их несколько, поскольку используется в шейдерных программах. Общим счетом таких “полотен” может быть от четырех штук (диффуз, нормал, спекуляр, освещение(было раньше), потом маска для самосвечения при необходимости, а сегодня еще модно использовать физически-корректное затенение, также добавляющее карты текстур, и я не исключаю того, что некоторые из этих карт могут запекаться в отдельные каналы одной, но суть дела это меняет не сильно). Может быть меньше, может быть больше. Учитывая, когда появилась такая технология (известно, что первые наработки по этой технологии появились еще на этапе разработки движка id Tech 3, о чем немало дискутировали программисты, занимавшиеся изучением исходников означенного движка), какое тогда было железо, какие скорости обращения к данным на жестком диске и какой объем оперативной памяти, говорить о присутствии медиа-контента игры в памяти целиком, мягко говоря, некорректно. Таким образом могут считываться также не только вышеупомянутые мегатекстуры, но модели персонажей, игровые уровни, музыка и много чего еще. Как пример считываемых далеко не целиком уровней, можно вспомнить такие игры, как Sacred, где присутствовал огромный игровой мир, доступный в реальном времени, но не способный уместиться целиком в оперативную память. Из игр более современных, можно привести какой-нибудь The Elder Scrolls, и в том числе Skyrim, так же хвастающийся своими просторами. Выбрасывать из памяти ненужное и считывать с диска только нужную информацию - это естественная механика работы любого игрового движка.
Есть целый ряд неточностей, и я их расписал.
Т.е. вы утверждаете, что ваши цитаты выше отличаются от того, что предусмотрено мной в:
?
Если да, то разъясните подробнее в чем по вашему отличие.
Давайте я на всякий случай поясню, что операцией чтения занимается условно низкоуровневая операция Read (условно, потому что она не так называется в системе), которой пользуются высокоуровневые языки. Суть ее заключается в считывании указанных байт с диска, будь то поток данных или блок данных, будь он сжат или не сжат. Операция DECODE приведенная мной выше в общем случае выполняется после, но я написал, что возможны случаи, когда внутри DECODE выполняется операция READ, а затем с полученными байтами выполняются операции, после которых мы и получаем DECODED_DATA.
Согласитесь или укажите ваше мнение по данному поводу.
И давайте не спешить объяснять наперед, вопросы задаются достаточно строгие, до различных технологий мы дойдем, если на то будут причины.
Да.
В том, что DECODE не осуществляет чтение с диска, но участвует при разжатии данных в процессе считывания.
В игровых движках присутствуют свои технологии файловых систем, и они могут пользоваться произвольными функциями для чтения файлов. Если бы пользовались только системными, то о переносимости игр и движков на различные игровые платформы следовало бы напрочь забыть.
Обычно происходит с точностью до наоборот - начинается чтение и уже внутри операции чтения нужный фрагмент данных разжимается при условии, если прочитаны сжатые данные.
Приведите пожалуйста пример такой функции чтения с диска, о которой вы говорите, которая не основана на системных вызовах Windows. Файловая система ntfs. Либо, если все они основаны, то скажите об этом факте четко. Это важно для дальнейшей дискуссии.
Помимо WINAPI еще существуют STL, STLPorts, boost, стандартные библиотеки в Mac OS X и других операционных системах и еще море других средств. Свои интерфейсы работы с постоянной памятью есть у консолей, XBox, PlayStation и других. И далеко не каждая операционная система работает с файловой системой ntfs, есть еще FAT, FAT32, Apple HFS, SFS, и много других, для работы с которыми есть свои библиотеки функций. Повторюсь: если бы таковых библиотек не существовало, то и перенести компьютерную игру с одной платформы на другую и запустить ее там после компиляции не представлялось бы возможным. На самом примитивном уровне для ответа хватит и какого-нибудь fstream из стандартной библиотеки, располагающего как раз-таки функциями read, write, look, и так далее.
Никто про WINAPI не говорит, тут стоит быть внимательным, а то можно и перепутать.
http :// math.kubsu .ru/Debian_Tanenbaum.pdf
Страница 86. Цитирую:
Корпорацией Microsoft определен набор процедур, названный Win32 API
(Application Programming Interface — интерфейс прикладного программирования). Предполагается, что программисты должны использовать его для доступа к службам операционной системы. Этот интерфейс частично поддерживается всеми версиями Windows, начиная с Windows 95. Отделяя API-интерфейс от фактических системных вызовов, Microsoft поддерживает возможность со временем изменять существующие
системные вызовы (даже от одной версии к другой), сохраняя работоспособность уже существующих программ.
Я говорю про системные вызовы, на которых
и в том числе WINAPI основаны. Не путайте.
Мы о Windows.
Далее ваш ответ пока не комментирую (вернемся).
Разбираемся с системными вызовами. Так как вы, по всей видимости, перепутали WINAPI и системные вызовы, то вопрос актуален.
Вопрос 10. Приведите пожалуйста пример такой функции чтения с диска, о которой вы говорите, которая не основана на системных вызовах Windows. Файловая система ntfs.
Вопрос 11. На каком уровне согласно рисунку Рис. 1.21. страницы 89 из той же книги будет работать приведенная вами функция (опустим монолитным или нет является винда)?
Вопрос 12. На каком уровне по вашему работает движок игры согласно модели архитектуры Windows? Чтобы не пользоваться разными вариациями модели рассмотрим следующую: Рис. 1.22. страницы 93 из той же книги. Данного количества уровней для рассуждения достаточно.