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

[Dageron]

Все проверил - изменил параметры флагов данной функцией и вместо zlib-запакованных данных поместил сначала распакованный sys, а потом gfx сегменты. Запуск ресурса без запаковки работает хорошо, только быстродействие запуска резко падает. Попробовал на loadingscreens.wtd - игра так и остановилась в загрузке на отображении лицензионного соглашения (очевидно, текстурный архив 36 мб размером получился). Зато небольшой fonts_streamed_1.wtd запустился отлично , так что даже не заметны изменения.

Простой пример (изменение параметра сжатия)
Флаги до работы функции:
00010000 00000000 01011000 11010100
Флаги после работы функции:
00010000 00000000 01011000 10010100
(со схемой что-то вообще не сходится)

[GooD-NTS]

Запуск ресурса без запаковки работает хорошо, только быстродействие запуска резко падает.
Попробовал на loadingscreens.wtd - игра так и остановилась в загрузке на отображении лицензионного соглашения (очевидно, текстурный архив 36 мб размером получился).

Никогда бы не подумал, что это будет медленней

Простой пример (изменение параметра сжатия):
Флаги до работы функции:
00010000 00000000 01011000 11010100
Флаги после работы функции:
00010000 00000000 01011000 10010100
(со схемой что-то вообще не сходится)

Эээ... нет, это ты видимо как-то не так биты смотришь. А точнее не в том порядке

Сообщение отредактировал GooD-NTS: 27 May 2009 - 11:47

[listener]

Никогда бы не подумал, что это будет медленней

А чтение+распаковка - всегда быстрее чтения непакованного ресурса (если есть хотя бы немного свободного процессора). Прочитать 36М в условиях работающей системы - это порядка секунды, а то и двух.

Кстати, в связи с анонсом EP2 стоило бы активизироваться.

[Dageron]

нет, это ты видимо как-то не так биты смотришь. А точнее не в том порядке

Я в 010 смотрел, режим View->LeftArea->Binary.

Кстати, в связи с анонсом EP2 стоило бы активизироваться.

Да, несколько отклонились от основной темы .

В любом случае теперь любой RSC можно держать будет и не запакованным (спасибо за функции).

Еще немного подправлю все и выложу (может еще что добавить?).

[listener]

"spesial data" => "special data"
Флаги стоит выводить в шестнадцатиричном виде.

А с пэйджингом что делать будешь? (Для PC это пока не особо критично, но не факт, что в очередном патче его не не включат).

[GooD-NTS]

Кстати, в связи с анонсом EP2 стоило бы активизироваться.

Не, ну так это... я уже

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

Тока старый OpenIV может с ними наверное глючить это надо проверять.

[Dageron]

"spesial data" => "special data"

Флаги стоит выводить в шестнадцатиричном виде.

Все поправил.

А с пэйджингом что делать будешь? (Для PC это пока не особо критично, но не факт, что в очередном патче его не не включат).

Пока с этим думаю можно повременить, добавить все равно никогда не поздно (Flags:= Flags AND NOT cFlagPaged;). Только я не понял, а на ПК разве это не используется сейчас?

Тока старый OpenIV может с ними наверное глючить это надо проверять.

В новом зато проблем не будет, надеюсь.

Про второй эпизод - это конечно R* придумали с названием, точно перебор. А вот что сборник "Episodes from Liberty City" на диске будет, не может не радовать.
Можно ли уже DLC1 запустить хотя бы "частями"? Скрипты, модели и текстуры без звуков и катсцен?

[listener]

Только я не понял, а на ПК разве это не используется сейчас?

Не скажу на 100%, но вроде бы нет. Надо будет залезть в стриминг и уточнить.

Можно ли уже DLC1 запустить хотя бы "частями"? Скрипты, модели и текстуры без звуков и катсцен?

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

Со скриптами - не хватает natives. Нужно делать .asi и выносить в нее недостающий код.

[Dageron]

Последние пару недель я занимался просмотрщиком *.xtd:

Если нужны какие-то извлеченные текстурки, обращайтесь, кончено.

На днях наконец полноценно взгляну на RSC ресурсы DLC, ведь теперь я тоже могу их распаковывать.
Основное внимание надо уделить тем, у которых основным отличием от ПК является порядок байт.

А вообще, странно что не видно желающих поучаствовать в разборе и портировании.

[BiDi]

Бы ли бы публичные просмотрщики\конвертеры текстур пока хотябы, может быть было бы больше людей, а так за каждой текстурой обращаться - это не то. Ладно редактор, но почему просмотрщик на публику выложить нельзя?

[Lego]

[offtopic]ололо все боятся 'гамерсупера' и его аналогов, ставят копирасты на всем, чем можно и там где не нужно. а то и вовсе "желающие" ни как не анонсируют свою программу.[/offtopic] в данном случае редактор никому и не нужен, т.к. задача - сделать TLaD на компе, собственно, у кого больше программ для промотра, тот и выйграл. к тому же, можно написать пару программ, а потом приманить ими хороших людей в команду.

[listener]

Да, чем дальше, тем чудесатее и чудесатее...
.text:0091BF4D 624 push offset aVisemeAnimatio ; "Viseme animation data"

Почему чудесатее? Потому что я посмотрел, что такое viseme (по идее, по русски это должно быть визема, по аналогии с фонема и лексема).
http://en.wikipedia.org/wiki/Viseme
Становится понятнее, почему R* не дали переводить озвучку.

Логично, что после этой строчки вызывается конструктор rage::crAnimation.

UPD: Вчера немного покопался в аудио-rpf от TLaD.
Как и ожидалось, звук запакован XMA1. Это не может не радовать, потому что, к нему есть унпакеры. Более того, если про xmaencoder.exe только ходят легенды (он есть только в XDK и запуганный NDA народ, у которого есть XDK, не делится), то на ctpax-x.ru лежит программа ToWav, которая замечательно декодирует XMA1.

Дело за малым: вытащить структуру bank/voice и собрать корректный WAVEFORMAT для файлов, а также блок seek.

Что касается viseme animation, которые также лежат в аудио ресурсах - конвертер xad->wad должен быть применим и в этом случае.

Сообщение отредактировал listener: 09 July 2009 - 11:37

[Akmal]

че за чудасатее визема такое? о_О

[Dageron]

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

[Akmal]

спс

[listener]

Итак, сегодня 28 августа. (Мне даже страшно вспоминать, когда здесь была последняя активность)
До релиза EP2 осталось ровно два месяца (1480 часов).

Если мы хотим что-то сделать - нужно это делать, а активности я не наблюдаю.
Требуется принять волевое решение: кто и что делает.

Для начала список вещей, которые, кроме меня вряд ли кто-то сделает:
1) скрипты (само-собой). В теории, их можно не трогать ценой некоторого увеличения дополнительных модулей
2) правка лимитов (количество моделей, количество типов обрабатываемых файлов в онфиге и т.д.)
3) Поддержка mission packs (по идее, можно обойтись докидыванием файлов в архивы, но возни будет не меньше)
4) недостатающие natives
5) правка физической модели байка (без этого оно будет неиграбельным - игра про байкеров, где нельзя нормально ездить на байке - это как-то странно)
6) перенос недостающих кусков (gang wars, новые formations и что там найдется еще)

(и это все, с учетом того, что к 19/09/2009 у меня по работе должен быть запущен новый проект)

Что остается:
1) форматы/RSC (в алфавитном порядке)
1.1) xad
1.2) xbn/xbd
1.3) xbs
1.4) xdr/xdd
1.5) xft
1.6) xhm
1.7) xnv
1.8) xpfl
1.9) xtd
2) форматы/прочие
2.1) anim
2.2) cut
2.3) xpl
3) звук (большая пачка самых разных данных: сам звук, xad к нему, индексы и т.д.)

Добровольцы будут?

PS. Вдогонку: список файлов, которые обрабатывае CConfigFileReader (содержимое default.dat/gta.dat)

// PC types [0x20]: 
// 0: "DELAYED_IDE", 1: "IPL", 2: "ANIMGRP", 3: "HANDLING", 
// 4: "VEHICLEEXTRAS", 5: "GXT", 6: "PLAYER", 7: "CARCOLS", 
// 8: "PEDGRP", 9: "CARGRP", 10: "RADIO", 11: "RADIOLOGOS", 
// 12: "RADARBLIPS", 13: "WEAPONINFO", 14: "THROWWEAPONINFO", 15: "HTML", 
// 16: "RMPTFX", 17: "PEDPERSONALITY", 18: "MELEEANIMS", 19: "ACTIONTABLE", 
// 20: "EXPLOSIONFX", 21: "VEHOFF", 22: "FMENUFILE", 23: "LBDATAFILE", 
// 24: "LBICONSFILE", 25: "PEDVAR", 26: "DISABLE_FILE"

// 360 types [0x30]:
// 0: "DELAYED_IDE", 1: "IPL", 2: "ANIMGRP", 3: "HANDLING",
// 4: "VEHICLEEXTRAS", 5: "GXT", 6: "PLAYER", 7: "CARCOLS",
// 8: "PEDGRP", 9: "CARGRP", 10: "RADIO", 11: "RADIOLOGOS",
// 12: "RADARBLIPS", 13: "WEAPONINFO", 14: "THROWWEAPONINFO", 15: "HTML",
// 16: "RMPTFX", 17: "PEDPERSONALITY", 18: "MELEEANIMS", 19: "ACTIONTABLE", 
// 20: "EXPLOSIONFX", 21: "VEHOFF", 22: "FDATFILE", 23: "FTXDFILE", 
// 24: "FMENUFILE", 25: "LBDATAFILE", 26: "LBICONSFILE", 27: "PEDVARS",
// 28: "POPCYCLE", 29: "TIMECYCLE", 30: "DISABLE_FILE", 31: "PLSETTINGSMALE",
// 32: "PLSETTINGSFEMALE", 33: "CREDITS", 34: "HUDCOLOR", 35: "HUDTXD"
// 36: "FONTDAT", 37: "FONTTXD", 38: "PLSETTINGSLIGHT", 39: "SAVEICON"

Сообщение отредактировал listener: 28 August 2009 - 16:44

[Dageron]

Ведь вот хочется помочь, а проявиться как всегда особо не в чем. По сути, раньше ощутимый вклад мог внести GooD, теперь же сам понимаешь... По этому, я вот думаю - может выложить по нескольку распакованных ресурсов на каждый тип? А то ситуация такова что люди может и хотят помочь, но своими глазами посмотреть на это все не могут. Особенно это моделей касается, вдруг да кто и захочет написать XDR2WDR, тем более в этом никаких майкрософтских копирайтных процедур задействовано не будет. В любом случае решать это уже не мне. Форматы, которые я пытался разбирать/разобрал (более-менее): 1.9) xtd - Мой просмотрщик нормально открывает и просматривает большинство текстур, остаток списывается на частые утечки памяти в Delphi и недостаток инфы по endian (точнее - какие именно текстуры нестандартные в этом плане). Корректный сбор dds-изображений в wtd, надеюсь, скоро буде (см. основную тему про WTD). Только уж тогда можно будет думать про прямой XTD2WDT. 2.3) xpl - Разобраны, сконвертированы мной уже давно. На наличие ошибок не проверял, это надо будет сделать когда решится вопрос с самими объектами. 1.4) xdr/xdd - Модели. Самое интересное что я ведь импортировал части xdr в макс, даже рассказывал об этом вроде. Без текстур, но все-таки. Что делать - не знаю. Тут по ходу нужно делать именно XDR2WDR, причем на C++ так как слишком много вложенных друг в друга шаблонов структур. Требуют изменения в порядке байт или минимальной конвертации: 1.1) xad 2.1) anim 2.2) cut (все это анимации, сконвертировать можно если разобрать структуру) 1.6) xhm - Игровой интернет. Я помню ты как-то уже давно говорил что есть шаблон для распакованных файлов. Хотелось бы взглянуть, надеюсь кроме непосредственной grcTexture отличий в ПК нет. Неразобранные: 1.2) xbn/xbd - Баунды. 1.3) xbs - ?? 1.5) xft - Машины. 1.7) xnv - ?? 1.8) xpfl - Насколько я знаю, это спецэффекты. Структура вообще непонятна, на gtaf начинали о ней говорить, но быстро закончили из-за сложностей (однако, grcTexture отыскать и извлечь можно). Мне кажется не критично будет вообще обойтись без этого файла. Со звуком понимаю - дело обстоит отдельное. В крайнем случае опять же - оставить это на потом, завязав все на скриптах. Перекомпилировать, сделав более-менее рабочий вариант без использования катсцен и озвучки, а потом наверстывать вырезанное.

[listener]

Для всех ресурсов лучше делать конвертеры. Если в ресурсе нет physical (GPU) части, структура и размеры объектов совпадают, т.е. нужно распаковать (lzx), поменять порядок байтов и запаковать (zlib). Для xtd, это применимо в том случае, если все grcTextureXenon и BaseTexture идут подряд (для большинства файлов это так). wdr/wdd и, возможно, wft придется пересоранять с коррекцией структуры. #bs - blendshapes - пероходы между анимациями. Структура та же, отличается порядок байтов. #nv - navmeshes - пути по карте (точки для путепрокладчика). Аналогично Вырезать звуки (и, тем более, катсцены) - тот еще не подарок. На них завязано достаточно много. Что касается желаний и возможностей - первое более важно чем второе (если, конечно, не переходит в пустые мечтания). Тот же GooD еще в прошлом мае задавал вопросы, как пользоваться дизассемблером (а в декабре - самостоятельно разобрал формат звуковых файлов). Я могу взять на себя координацию усилий/раскидывание задач. Но, в ответ, хочется каких-то результатов. Для начала - микрозадачка. Есть шаблон для wdr. Его нужно переделать в xdr-ный (по аналогии с wtd -> xtd, там должны быть отдельные дескрипторы для вертексных и индексных буферов). Шаблон для xhm болтался много где. Его нужно дополнить (текстура, возможно, какие-то CSS-ные селекторы) и, полезно было бы сделать whm. (И вообще, этот шаблон очень старый: дата последней версии - ровно год назад, 28/08/2008. С тех пор, многое прояснилось).

[Dageron]

Понемногу адаптирую wdr шаблон под xdr. Пока что заменил grcTexture и функции чтения указателей (с первого взгляда разницу в структурах заметить трудно). Одно я могу сказать - на Delphi конвертер написать будет невозможно, в моделях просто огромное количество вложенных друг в друга структур. Хорошо есть удастся реализовать на C++ через шаблоны (подобно pgBase). Теперь что касается XTD2WTD. Если не изменять параметры флагов, то такую программу будет написать не очень сложно, но вот указатели внутри CPU-части в любом случае надо будет править (так как grcTexturePC занимает 80 байт, а grcTextureXenon - 64 байта) + ненужные на ПК D3DBaseTexture приедтся заменить на padding. Но все-таки мне бы хотелось сделать нормальный WTD Builder из набора dds-изображений, такая вещь может сильно пригодиться в разных областях.

[Dageron]

Выкладываю в свою папку dropbox-а последние версии переписанных шаблонов (iv-xdr, iv-whm). В *.xhm/*.whm есть одна неизвестная struct CPtrCollection _f20, в ней содержатся указатели на FixupData. Я попытался немного расписать ее - она состоит из одного int, равного нулю, нового указателя на коллекцию - и двух short, первый из которых - количество составляющих этой коллекции. Сама коллекция состоит из указателей (часть из них - могут быть нулями), а вот ведут они на непонятные значения. Все что касается текстур переписано под ПК и выделено зеленым цветом.