Сообщений в теме: 783

[DenielX]

Щас на сборах в Кисловодске,кое что накопал про злиб,будет время-отпишусь.И ссылочкой поделюсь.
Кстати никто не знает функции в злибе которая при загрузке компрессированного файла позволяла бы копировать его словарь ?Кто хочет не вырезать пол игры что бы что-то заменить в game.dtz помогите мне.Акцентирую внимание на алгоритм статического сжатия Хаффмана.
Ссылка:http://www.compression.ru/download/articles/huff/yankovoy_2004_huffman/dynamic_huffman.html

Сообщение отредактировал DenielX: 10 November 2012 - 17:11

[DenielX]

11 дней не было интернета,пишу с чужого ноута(файлы потом прикреплю).11 дней назад должен был отписать вот это.
Всё!Накипело:
1.При запаковке оригинального меню/шрифтов без их изменения размер сжатого файла остаётся тот же,что и до его распаковки(самое начало,когда вытаскиваем из распакованного Zlib'ом GAME.DTZ),при малейших изменениях в меню/шрифтах размер при сжатии может менятся как в большую,так и в меньшую сторону.Это зависит от того,на какие символы (ASCII) вы заменили оригинальные и от длинны совпадений этих символов(допустим:ММММММММММММММММММММММВВВВВВВВВВВВВВВВВВВВВВВ,условно сжимает в 22М23В),чем длиннее совпадения,тем меньше размер сжатого файла(при условии что эти символы присутствуют в словаре сжатия),так как нули есть в словаре полюбому ,используют иммено их (так можно использовать любой из 255(6) символов ASCII),если знать наиболее встречающийся символ (и забивать его вместо 0) в меню/шрифтах можно сжать ещё раза в 2->т.е. в 2 раза меньше вырезаных текстур.
2.Можно обойтись без вырезания:
2.1.Не вырезать,а вставлять более простые текстуры(которые вам не важны и имеют множества совпадений символов) и за счёт этого заменить нужные вам текстуры(т.е. сложные текстуры компенсируют простые).
2.2.Из-за ввода новых символов запаковать полностью старым словарём нельзя , но так как даже при максимальном сжатии используется не слишком оптимизированный словарь,под модифицированный файл (меню/шрифтов) можно и нужно создавать свой оптимизированный словарь (т.е. для каждой модификации своя дата сжатия).Как я понял сделать это можно настроив размер буфера для сжатого файла(да,да,как оказалось так можно сделать),а конкретней ввести размер сжатого оригинального файла в байтах и за счёт этого можно либо получить новый сжатый файл (меню/шрифтов) с оптимизированной датой и нужным нам размером ,или в противном случае компрессор не сможет этого сделать и выплюнет ошибку,если совпадений ,чтобы сжать файл до нужного размера,нехватает.
Проще для понимания и с несколькими подробностями (и про использование буфера тоже) описано здесь: http://www.w3.org/TR...ransitional.dtd
2.3.Из предыдущего случая,если совпадений не хватает,придётся перепаковывать весь GAME.DTZ и в движке переписывать адреса затронутых конфигураций.
Вывод:размер сжатого файла зависит от сложности текстуры,самые сложные текстуры могут сделать нужный нам размер файла недосягаемым(из за чего,как я говорил выше,придётся делать перепак GAME.DTZ и всей игры).Это говорит о том,что при приготовлении GAME.DTZ делали с расчётом на модифицирование/исправление адресов и лежащих в нём ресурсов(и само собой чтобы с экономить память),в то время как шрифты и меню так же делались с расчётом на экономию памяти,но уже на века,без возможности глобального модифицирования(о добавлении чего то своего я вообще молчу),видимо это ещё и защита от таких как мы.
Немного информации про GAME.DTZ:
!!!!!!!!!!(здесь не прав,ошибся,но всё равно читать)В отличие от других запакованных текстурных директорий имеет полный словарь(все 255(6) символов ASCII) за счёт чего,что бы мы в распакованном GAME.DTZ не меняли (без его увеличения конечно) ,после его сжатия он будет иметь либо оригинальный, либо меньший размер,но никак не больший,что существенно облегчает его модификацию (если не считать меню и шрифты)(здесь не прав,ошибся,но всё равно читать)!!!!!!!!!!.Но к сожалению полного словаря нет у шрифтов и меню и даже если её сделать,размер сжатого файла будет больший,т.к. словарь сжатия в файле сжимается стандартным словарём и соответственно чем больше словарь,тем меньше размер сжатого файла,но + сжатый словарь всё портит.
Есть идея крепкого варианта моддинга всех ресурсов в GAME.DTZ,но она очень сложная,на PSP-версиях идея будет лагать,т.к. в PSP всего 64 мб внутренней памяти,из которых половина (30 с копейками) идёт на прошивку.Об идее раскажу позже.
Что забыл написать потом добавлю.
И кстати словари от PSP-версий(меню/шрифты) прикрепил.

Сообщение отредактировал DenielX: 26 November 2012 - 17:51

[SILENT_Pavel]

DenielX
В принципе многое из того, что ты сказал нам уже известно.
Но все равно спасибо за подробное разжевывание материала, полезное дело :-)

[DenielX]

Хаффман отвечает за систему словаря сжатия.Нужно придумать как генерировать оптимальную дату для каждого из модифицированных файлов(иначе никак).
Дело в том,что там всё состоит из динамически создаваемых кодов,но если при сжатии в блоке были заменены данные(а zlib сжимает поблочно),то именно в этом блоке динамика будет заменена фиксированными кодами Хаффмана(статика),из-за чего размер будет больше.Исходя из всего этого получается что можно заменить на текстуру любой сложности при правильном построении динамических кодов.
Пара вопросов:
1.Кто нибуть разбирал .chk от PSP?(желательно LCS)
2.Как быть на PSP с альфа-слоем?
Кстати 1 вопрос связан с тем,что я не могу понять где заканчиваются данные и начинается словарь сжатия(предположительно словарь находится в распакованных данных,в конце файла),поэтому дату из под файлов пока выкладывать не решусь.Кое какая полезная програмка,но не совсем то: http://www.soft-info...oads/1309370157

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

[DenielX]

Нашёл очень простую для понимания статью,про кодирование Хаффмана:http://algolist.manual.ru/compress/standard/huffman.php Форум спит....

Сообщение отредактировал DenielX: 26 November 2012 - 17:52

[SILENT_Pavel]

1.Кто нибуть разбирал .chk от PSP?(желательно LCS)

Это чуть ли не первое что Dageron и комьюнити разбирали и продолжаем разбирать уже не один год, результатом и стала программа GTA STE.

Поддерживаемые форматы: *.chk, *.xtx, *.dtz, *.img
Возможности программы:
Работа с файлами с сигнатурой «tex» — просмотр содержимого, экспорт и импорт (имеют расширение *.chk в LCS и *.xtx в VCS).

Можно сказать что с этим никаких проблем нет и все разобрано. Проблема в том, что chk встречаются только в gta3xxx.img и в GAME.DTZ, а в так называемых ворлдах их вообще нет, а есть ад, сотона и Израиль (Dageron в техническом плане подробнее пояснит, я в основном тестировал). В этом аду и разбираемся в последнее время, только благодаря этим последним наработкам удается вполне комфортно осуществлять снежный мод. А проблема вся в lvz что являются зазелибованными ворлдами и при этом часто содержат ключевые городские текстуры необходимые для моддинга снежного мода, из за них и приходится образ пересобирать.

2.Как быть на PSP с альфа-слоем?

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

Сообщение отредактировал SILENT_Pavel: 27 November 2012 - 07:07

[DenielX]

Это чуть ли не первое что Dageron и комьюнити разбирали и продолжаем разбирать уже не один год, результатом и стала программа GTA STE.

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

Сообщение отредактировал DenielX: 27 November 2012 - 11:19

[Dageron]

DenielX
Внимательно прочитал ваши публикации).

Вообще говоря довольно интересно, что вы попытались исследовать внутреннюю структуру zlib и вмешаться в ее работу, но это, пожалуй, не слишком удачное решение в данном случае.

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

В итоге вы пришли к тому же выводу, который в общем-то еще был сделан ~ в 2009 году, - логично, что чем больше повторяющихся байт в незапакованном файле, тем меньше будет файл запакованный. Мы, например, использовали этот вполне очевидный нюанс в наших локализациях для упаковки шрифтов и меню (иногда имеет смысл адаптировать изображения так, чтобы они имели больше "заполненных одним байтом" областей), используем и в *.wrld/*.lvz.

Пара вопросов:
1.Кто нибуть разбирал .chk от PSP?(желательно LCS)
2.Как быть на PSP с альфа-слоем?

Ну структура *.chk разобрана достаточно, чтобы извлекать и заменять текстуры. Из неразобранного остается только логика построения таблицы оффсетов в заголовке, применяемая для более экономичного распределения памяти на консолях (что-то вроде relocation table), но ее и менять-то не слишком нужно. Вам нужно описание или подробно про что-то конкретно? Сжатия там никакого нет, равно как и чего-либо похожего на словарь, применяемый при сжатии.

На PSP альфа-слой такой же, как и на PS2, с тем лишь отличием, что максимальное значение альфы не 0x80, а 0xFF.

[DenielX]

Спасибо за ответ Dageron. Насчёт структуры .chk- сам разбирал знаю какие байты указывают на блок описателей,какие на битность текстуры,какие на начало блока графики,вобщем разобрал почти всё за исключением некоторых байтов,текстур с альфой (сообщение прочёл,но ещё не приступал) и наконец не разобрался с битами где длинна и ширина хранятся(вот про них я и хотел бы узнать). Зарание спасибо.

[Dageron]

Очень хорошо, что по текстурам так продвинулись).
С тем, как текстуры в циклический список с указателями выстраиваются, вы тоже разобрались?
(это в LCS/VCS на обеих платформах так)

Да, и вот, если что, чтение параметров на PSP (фрагмент кода из Stories Texture Explorer):

WorkFile.Read(iBPP, 1);
WorkFile.Seek(WorkFile.Position-1, 0);
iBPP:=iBPP and $0F;
iMipMaps:=iMipMaps shr 4;
WorkFile.Read(iWidth,1);
WorkFile.Seek(WorkFile.Position-1, 0);
WorkFile.Read(iHeight,1);
iWidth:=GetParam(iWidth shr 4);
iHeight:=GetParam(iHeight and $0F);
{функция GetParam - возведение 2 в степень аргумента}

[DenielX]

Спасибо Dageron Что как и что отвечу завтра т.к. поздно уже .Я разбирал .chk от VCS(PSP)(без мипмапов),думаю что LCS не сильно расходятся и разбирал досконально (это мой первый самостаятельный разбор,но учитывая что я с хексом давно вожусь думаю всё верно).Кстати указатели что в конце могут оказаться и в начале(за это отвечает кое какие байтики),всё как всегда в Double words.Завтра то на чём разбирал,на том и расскажу-радары от VCS.

[DenielX]

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

[gouranga]

DenielX, к чему такое повышенное внимание к алгоритму компрессии Zlib? В ЛСС/ВСС им запаковано очень маленькое количество ресурсов - DTZ и LVZ. Чтобы редактировать в них данные, вполне достаточно выставлять максимальный тип сжатия при упаковке - размер файла при этом получается практически равным оригиналу. Зачем копаться в том, что уже давно раскопано 4 года назад (читай сообщения Даге).

[SILENT_Pavel]

размер файла при этом получается практически равным оригиналу

Нет, не получается, у меня любая модификация из снежного мода, даже самая минимальная на 3-7% увеличивает каждый этот архив зелибованный существенно.
Я нашел лишь один выход - каждый раз с нуля пересобирать образ игры на пс2 через официальный генератор и на псп через UMDGen.
Это соответственно снова сильно отдалила релиз мода. Ибо некоторые сборки перестают работать на ps2 opl например, но работают с диска. в общем новые дебри пересборки
еще дамп с лицензии содержит в себе более 2 гигов пустых файлов которые при пересборки самоуничтожаются (скрин приклепейтед) и генерируют новые проблемы, но это уже другая история

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

Прикрепленные изображения

• 

Сообщение отредактировал SILENT_Pavel: 02 March 2013 - 17:11

[gouranga]

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

Они всегда есть:

1. В DTZ встречается мусор, который не используется игрой, если его обнулить, то размер архива станет меньше.
2. Манхунт 2 понимает распакованные ресурсы, возможно ЛСС/ВСС тоже, т.к. там используются похожие движки.
3. Можно сократить количество текстур в LVZ за счёт редактирования ссылок на текстуры в материалах моделей игры.

[SILENT_Pavel]

gouranga
Первый вариант отпадает, я говорил про LVZ архивы.
Второй не пробовал, а третий интересно, можно поробнее? Про последнее ничего не слышал.

[gouranga]

можно поробнее? Про последнее ничего не слышал.

http://gtamodding.ru....81.D0.B8.D1.8F

[DenielX]

Я нашел лишь один выход - каждый раз с нуля пересобирать образ игры на пс2 через официальный генератор и на псп через UMDGen.

Можно подробней про пересборку на PSP версиях ?

[SILENT_Pavel]

DenielX
C псп все проще, через UMD ген нет ограничений размера, по крайней мере в том диапазоне, в котором у нас погрешность.
Но и с пс2 в общем-то разобрались уже.
Скоро будет новое видео.

Сообщение отредактировал SILENT_Pavel: 11 March 2013 - 08:36

[DenielX]

Всем ку!)
Решил проблему альфа слоя на PSP!
1.Отрываете png с альфой (или если альфы нет,то делаете её) в GIMP'е (Raw-плагин установлен).
2.Изображение->Режим->Индексированное...(ставите кол-во цветов в соответствие(я без смешивания цветов ставлю))
3.Файл->Сохранить как...
4.Выбрать тип файла (По расширению)->RAW Texture (raw)->Сохранить
5.{Параметры в соответствии с текстурой}->ОК
6.Открываем хекс-редактор
7.Открываем текстуру,палитру(rawpal) и нашу текстуру(raw) из GIMP'а
8.Остановимся на палитре (при этом пикча в GIMP'е открыта).В GIMP'е : Инструменты->Пипетка.Щёлкните на альфе.
9.В хексе (в палитре) найдите значения цвета альфы,обычо альфа первая в палитре(в GIMP'е показывалась информация о цвете альфы,раздел Hex) и замените эти числа(обычно это цвет 010000,а в просматриваемой в хексе палитре 010000FF) на 00000000,пересохраните палитру.
10.Теперь вставте в текстуру палитру и пикчу соответствено.
Откройте заменённую текстуру в проге и узрите чудо!!!)))
P.S.Сие открытие сделал как Колумб-случайно
Видео: