Публикации
Мужчина
#10967 Моддинг LCS и VCS (PSP/PS2)
Написано
20 January 2012 - 14:29
На самом деле они не зашифрованные, просто их структура (с учетом структуры wrld), как говорится, is too complicated).
Для начала следует разделить задачи.
1. Задача первая - получить всю информацию о wrld-файлах, либо извлечь их из *.img/*.lvz "в открытом виде".
2. Задача вторая - получить необходимые данные из wrld-ов (например, текстуры).
Я подробно распишу первый этап, поскольку второй на самом деле очень объемный, с ходу весь процесс не описать.
В общем, допустим у нас есть некоторый *.img-архив и соответствующий ему *.lvz. Не важно, какой именной игры (LCS/VCS) и какой именно платформы (PSP/PS2). Для начала нужно распаковать *.lvz через какой-нибудь zlib-распаковщик и подготовить два файла - распакованный *.lvz и, собственно, *.img-архив.
В *.img де-факто хранятся wrld-ы без заголовков, при этом главная особенность *.lvz состоит в том, что этот файл не только сам является wrld-ом, но и содержит заголовки к wrld-ам из *.img.
Смещаемся в распакованном *.lvz на оффсет 0x24 и читаем следующие четыре байта. Полученное значение - указатель на таблицу заголовков к wrld-ам. Сама таблица - длинный-длинный список. Каждый заголовок занимает 32 байта, т.е. восемь полей по четыре байта. Третье поле - оффсет wrld-а от начала *.img, пятое поле - оффсет внутренней таблицы параметров wrld-а (о ней чуть позже, она пригодится при работе с содержимым непосредственно), седьмое поле - размер wrld-а. Остальные поля нам не нужны.
Далее можно поступить разными способами - либо составить в программе таблицу всех параметров wrld-ов, либо извлечь их "в открытом виде", разрезав *.img по тем параметрам и совместив все полученные фрагменты с соответствующими заголовками (т.е. добавив те самые 32 байта).
Так, если ситуация ясна, то можно приступать к wrld непосредственно, если нет, то лучше спросить что не понятно.
#5671 HEX-редактор...
Написано
22 August 2010 - 10:49
Хорошо, начнем с первого пункта.
Постараюсь объяснить весь ход работы, особенно отдавая должное логическим рассуждениям. Предупреждаю сразу - рассказ аналитический, здесь я все попытался расписать по-порядку сам подход к подобным задачам.
В любом текстурном файле (или же текстурной директории) надо уметь разграничивать "блок описателей" и "блок графики", поскольку подход к их изучению принципиально разный. Собственно, останавливаться сейчас на "блоке описателей" смысле нет по причине того, что *.chK - нехороший для этого пример. Я сам потратил уйму времени, прежде чем вывел приличную структуру. Гораздо лучше остановиться на консольных графических форматах, поскольку достаточно понять их устройство в одной игре, как это практически один-в-один наложится на любую другую.
Итак, не вдаваясь в конкретное строение *.chk, разберем все по-порядку.
Определить наличие графики в файле можно просто визуально. Наглядно она представляет собой большой набор "блоков", каждый из которых имеет много подряд повторяющихся одинаковых байт. К примеру, в файле MPLOAD1.CHK как раз и содержится такая текстура.
Открываем текстуру в 010. Что мы видим? Первые 96 байт сразу отбрасываем, поскольку это заголовок и блок описателей, сейчас он нам неинтересен. А вот дальше идет большой массив нулей и некие "жидкие" данные.
Раз файл с консоли (PSP/PS2), значит наличие "сжатой" графики весьма сомнительно и скорее всего текстура в обычном формате "битовая матрица+палитра".
В LCS/VCS так и есть - текстуры либо 8bpp, либо 4bpp ("Bits Per Pixel" - число бит, отводимых на один пиксель). Для 8bpp размер рассчитывается как "Высота*Ширину", для 4bpp - "Высота*Ширину/2".
Итак, допустим, что мы знаем, что текстура 512*256 и 8bpp (все равно в большинстве случаев при разборе консольных форматов все это определяется экспериментально и методом научного тыка). Следовательно, размер блока графики равен 131072 байт.
Нажимаем Ctrl+G, вводим в появившемся окне 131168 (131072+96=131168). Следует обратить внимание на то, чтобы стоял параметр Decimal, а не Hex - мы работаем не в шестнадцатиричной, а в десятичной системе счисления (для удобства восприятия).
Итак, мы попали на некие непонятные на первый взгляд данные. 8-битную палитру узнать легко - это большой массив, который визуально выглядит очень симметричным. 4-битную палитру обычно узнать еще проще - это маленький массив, визуально так же симметричный. Мы сместились на оффсет 131168, хотя явно видно, что палитра начинается с 131232. Это значит, что начальный блок графических данных начинается не с оффсета 96, а с оффсета 160.
Что же представляет из себя сама палитра? Массив цветов. На каждый цвет отводится 4 байта - "blue, green, red, alpha" (это на консолях, на ПК другой порядок - "red, green, blue, alpha"). Число элементов массива определяется по параметру bpp, для 8 бит - 256 (2^8=256), для 4 бит - 16 (2^4=16). Следовательно, 8-битная палитра занимает 256*4=1024 байта, 4-битная - 16*4=64 байта.
Теперь заменим текстуру, например, вот на эту:
Стоит помнить про то, что простого сохранения в raw-режиме недостаточно, ведь на PSP используется swizzling (грубо говоря и не вдаваясь в тонкости - это алгоритм адаптации графики для консоли). Надо пересохранить эту текстуру в нужном raw-формате и позволяет это сделать GIMP, со специальным RAWTex-плагином (нужно поместить файл RAWTex.exe в GIMP-2.0/lib/gimp/2.0/plug-ins).
Конечно это не идеальный и, возможно, некрасивый метод, но он работает и позволяет обойтись без написания своего софта.
Открываем GIMP, а в нем - нашу картинку. Теперь ее надо адаптировать под нужный режим цветов.
"Изображение"->"Режим"->"Индексированные"->"Создать оптимальную палитру" и в "Максимальном числе цветов" указать нужно 256 (т.к. у нас 8 бит).
Теперь сохраняем. "Файл"->"Сохранить как"->"RAW Texture"
В поле "Texture Format" следует указать "GU_PSM_T8" и установить галочку "Swizzle Mode (PSP only)". "Mipmaps" в данном случае - "none".
Должны создаться три файла:
texture.h - нам неинтересен, это C++ заголовок, в котором указываются все параметры и характеристки текстуры, это для тех, кто homebrew на PSP делает.
texture.raw - текстура.
texture.rawpal - палитра текстуры.
(Следует обратить внимание на то, чтобы в пути сохраняемого файла не было русских символов, иначе возникнет ошибка.)
Открываем *.raw и *.rawpal в 010, а так же наш оригинальный *.chk. Смещаемся в *.chk к оффсету 160 (это начало блока графики, как мы экспериментально пределили) и копируем туда все содержимое из *.raw. Если все получилось правильно, то мы должны были оказаться на оффсете 131232, т.е. начале массива цветов (палитры). Теперь копируем туда все содержимое *.rawpal.
Результат (готовый *.chk-файл).
Вот и получился достаточно стильный загрузочный экран, можешь проверить.
p.s. Если есть еще вопросы - задавай. Только если уж совсем ничего не понятно, то лучше начинать с вещей попроще вроде обычных *.img-архивов (не LCS/VCS!) или же подобных "не запутанных" вещей.
Постараюсь объяснить весь ход работы, особенно отдавая должное логическим рассуждениям. Предупреждаю сразу - рассказ аналитический, здесь я все попытался расписать по-порядку сам подход к подобным задачам.
В любом текстурном файле (или же текстурной директории) надо уметь разграничивать "блок описателей" и "блок графики", поскольку подход к их изучению принципиально разный. Собственно, останавливаться сейчас на "блоке описателей" смысле нет по причине того, что *.chK - нехороший для этого пример. Я сам потратил уйму времени, прежде чем вывел приличную структуру. Гораздо лучше остановиться на консольных графических форматах, поскольку достаточно понять их устройство в одной игре, как это практически один-в-один наложится на любую другую.
Итак, не вдаваясь в конкретное строение *.chk, разберем все по-порядку.
Определить наличие графики в файле можно просто визуально. Наглядно она представляет собой большой набор "блоков", каждый из которых имеет много подряд повторяющихся одинаковых байт. К примеру, в файле MPLOAD1.CHK как раз и содержится такая текстура.
Открываем текстуру в 010. Что мы видим? Первые 96 байт сразу отбрасываем, поскольку это заголовок и блок описателей, сейчас он нам неинтересен. А вот дальше идет большой массив нулей и некие "жидкие" данные.
Раз файл с консоли (PSP/PS2), значит наличие "сжатой" графики весьма сомнительно и скорее всего текстура в обычном формате "битовая матрица+палитра".
В LCS/VCS так и есть - текстуры либо 8bpp, либо 4bpp ("Bits Per Pixel" - число бит, отводимых на один пиксель). Для 8bpp размер рассчитывается как "Высота*Ширину", для 4bpp - "Высота*Ширину/2".
Итак, допустим, что мы знаем, что текстура 512*256 и 8bpp (все равно в большинстве случаев при разборе консольных форматов все это определяется экспериментально и методом научного тыка). Следовательно, размер блока графики равен 131072 байт.
Нажимаем Ctrl+G, вводим в появившемся окне 131168 (131072+96=131168). Следует обратить внимание на то, чтобы стоял параметр Decimal, а не Hex - мы работаем не в шестнадцатиричной, а в десятичной системе счисления (для удобства восприятия).
Итак, мы попали на некие непонятные на первый взгляд данные. 8-битную палитру узнать легко - это большой массив, который визуально выглядит очень симметричным. 4-битную палитру обычно узнать еще проще - это маленький массив, визуально так же симметричный. Мы сместились на оффсет 131168, хотя явно видно, что палитра начинается с 131232. Это значит, что начальный блок графических данных начинается не с оффсета 96, а с оффсета 160.
Что же представляет из себя сама палитра? Массив цветов. На каждый цвет отводится 4 байта - "blue, green, red, alpha" (это на консолях, на ПК другой порядок - "red, green, blue, alpha"). Число элементов массива определяется по параметру bpp, для 8 бит - 256 (2^8=256), для 4 бит - 16 (2^4=16). Следовательно, 8-битная палитра занимает 256*4=1024 байта, 4-битная - 16*4=64 байта.
Теперь заменим текстуру, например, вот на эту:
Стоит помнить про то, что простого сохранения в raw-режиме недостаточно, ведь на PSP используется swizzling (грубо говоря и не вдаваясь в тонкости - это алгоритм адаптации графики для консоли). Надо пересохранить эту текстуру в нужном raw-формате и позволяет это сделать GIMP, со специальным RAWTex-плагином (нужно поместить файл RAWTex.exe в GIMP-2.0/lib/gimp/2.0/plug-ins).
Конечно это не идеальный и, возможно, некрасивый метод, но он работает и позволяет обойтись без написания своего софта.
Открываем GIMP, а в нем - нашу картинку. Теперь ее надо адаптировать под нужный режим цветов.
"Изображение"->"Режим"->"Индексированные"->"Создать оптимальную палитру" и в "Максимальном числе цветов" указать нужно 256 (т.к. у нас 8 бит).
Теперь сохраняем. "Файл"->"Сохранить как"->"RAW Texture"
В поле "Texture Format" следует указать "GU_PSM_T8" и установить галочку "Swizzle Mode (PSP only)". "Mipmaps" в данном случае - "none".
Должны создаться три файла:
texture.h - нам неинтересен, это C++ заголовок, в котором указываются все параметры и характеристки текстуры, это для тех, кто homebrew на PSP делает.
texture.raw - текстура.
texture.rawpal - палитра текстуры.
(Следует обратить внимание на то, чтобы в пути сохраняемого файла не было русских символов, иначе возникнет ошибка.)
Открываем *.raw и *.rawpal в 010, а так же наш оригинальный *.chk. Смещаемся в *.chk к оффсету 160 (это начало блока графики, как мы экспериментально пределили) и копируем туда все содержимое из *.raw. Если все получилось правильно, то мы должны были оказаться на оффсете 131232, т.е. начале массива цветов (палитры). Теперь копируем туда все содержимое *.rawpal.
Результат (готовый *.chk-файл).
Вот и получился достаточно стильный загрузочный экран, можешь проверить.
p.s. Если есть еще вопросы - задавай. Только если уж совсем ничего не понятно, то лучше начинать с вещей попроще вроде обычных *.img-архивов (не LCS/VCS!) или же подобных "не запутанных" вещей.
