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

[Chipsman]

та счет xpl, сейчас докачаю архив и тоже буду смотреть...

Так в ПК версии же лежать все xpl от бокса.

точно)

[Dageron]

А чем, кстати говоря, default.xex распаковывается?

[listener]

А чем кстати говоря default.xex распаковывается?

XexTool-ом.
xextool -b gtaiv_360.exe -i gtaiv_360.idc default xex

[Dageron]

Сконвертировал все *.xpl из DLC в формат *.wpl для ПК. В прикрепленном архиве: все оригинальные *.xpl, полученные *.wpl, сгенерированные *.dat-файлы (может пригодятся кому, в "блокноте" все-таки удобнее смотреть и анализировать структуру). Что самое интересное - ко всем хешам объектов основной секции нашлись названия. Есть какие-то сдвиги с конвертированием текстур? Что будет если извлечь CPU и GPU блоки из lzx и запаковать их в zlib (т.е. можно ли будет увидеть текстуру хоть в каком-то виде при этом)? Ведь опять же параметр флагов нельзя трогать, получится ли просто из одного пиксельного формата в другой перегнать?

Прикрепленные файлы

•  DLC_Placement.rar   816.46К   16 загрузок

[GooD-NTS]

Что самое интересное - ко всем хешам объектов основной секции нашлись названия.

Не может быть, т.к. клуба The Lost точно нет в оригинальной игре... или значит, интерьеры находятся не в основной секции.

Есть какие-то сдвиги с конвертированием текстур?

хм... а какие сдвиги должны быть? никто этим не занимается.

Что будет если извлечь CPU и GPU блоки из lzx и запаковать их в zlib (т.е. можно ли будет увидеть текстуру хоть в каком-то виде при этом)?

Ничего не будет, потому что ты забыл про порядок байт и про то, что структура ПК текстур отличается.

Ведь опять же параметр флагов нельзя трогать, получится ли просто из одного пиксельного формата в другой перегнать?

Вроде конвертировать xtd в wtd можно и без "пересчета" флагов. Да и "пересчет" флагов для текстур не такая уж и не выполнимая задача сейчас.

[listener]

Что касается конвертирования тестур - никаких проблем нет. Это полностью решенная задача. Если понадобится, я напишу конвертор за полчаса. Флаги, там, практически нигде, пересчитывать не придется (Как правило, вся virtual часть помещается в 4К, что дает нам одну lpage минимального размера) Размер пиксельных данных не меняется, меняется только порядок текселей. Но, поскольку эта задача полностью решена - приоритет у нее минимальный. Что очень нужно сделать - разобрать формат vertex declaration в wdr. А также, плотно заняться wft (а то в нем назначение большей части структур пока неизвестно). Радует, что есть какой-то прогресс. Если так будет продолжаться и дальше, я засяду за недостающие natives.

[Dageron]

Что касается конвертирования тестур - никаких проблем нет.
Это полностью решенная задача. Если понадобится, я напишу конвертор за полчаса. Флаги, там, практически нигде, пересчитывать не придется (Как правило, вся virtual часть помещается в 4К, что дает нам одну lpage минимального размера)
Размер пиксельных данных не меняется, меняется только порядок текселей.

Можно быстрее сделать через G-Texture от REspawn. Ведь в этой программе есть правильный пересчет флагов, основанный на твоем коде?

Радует, что есть какой-то прогресс. Если так будет продолжаться и дальше, я засяду за недостающие natives.

У архива с *.wpl все еще гордо "одно скачивание".

[Chipsman]

Можно быстрее сделать через G-Texture от REspawn. Ведь в этой программе есть правильный пересчет флагов, основанный на твоем коде?

не думаю что вручную через G-Texture будет быстрее по одному архиву делать чем скопом сразу все..

[BiDi]

Это полностью решенная задача. Если понадобится, я напишу конвертор за полчаса.

Конвертер чего, текстур? Если да, тогда отлично.

Можно быстрее сделать через G-Texture от REspawn.

А что в этой программе такого хорошего? Там просто редактор .wtd текстур и всё, и никаких флагов там по мойму нет ( версия 0.1)

Сообщение отредактировал BiDi: 31 March 2009 - 13:25

[listener]

Итак, что получается по форматам:

'RSC':
*.xad -> *.wad -- отличаются порядком байт, конвертация тривиальна
*.xbd -> *.wbd
*.xbs -> *.wbs
*.xdd -> *.wdd -- см. xdr
*.xdr -> *.wdr -- общий смысл ясен. Не хватает нескольких структур (все упирается, в основном, в vertex declaration)
*.xhm -> *.whm -- (+) разобран до уровня, на котором его можно спокойно сконвертировать
*.xft -> *.wft -- предположительно, это самый сложный из всех форматов
*.xnv -> *.wnv
*.xpfl -> *.wpfl -- назначение и структура неизвестно
*.xpl -> *.wpl -- (+) предположительно разобран (или я что-то путаю?)
*.xtd -> *.wtd -- (+) разобран, конвертер изготавливается с минимальными усилиями

Бинарные файлы, либо не нуждаются в конвертации, либо требует замены порядка байт:
*.srl - ?
*.cut -> no convert
*.nod -> no convert ?

Неизвестно:
*.anim -> ? -- в PC версии отсутствуют (но код для чтения 'ANI8' есть)

Но это все, как говорится, цветочки.
Ягодки находятся в каталоге audio.
Формат audio-файлов слабо изучен. Метод компрессии - неизвестен (предположительно, это xWMA). На аудио-файлы завязано очень многое в коде, плюс в них, помимо звука, находится достаточно много данных (например, предположительно, анимация для lip-sync)
Кроме самого звука, есть несколько файлов каталогов (.dat15, dat16) по которым у меня нет никакой информации.

Что осталось в сухом остатке.
Как минимум ~50 natives, предположительно, некоторое количество кода, добавленного в CBike, gang wars, новые гонки и новое оружие.

"Сухой остаток" я могу взять на себя (т.к. я не наблюдаю большой толпы желающих копаться в PPC-шном коде).
Остальное - распределяйте.

А что в этой программе такого хорошего? Там просто редактор .wtd текстур и всё, и никаких флагов там по мойму нет ( версия 0.1)

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

Сообщение отредактировал listener: 31 March 2009 - 17:03

[GooD-NTS]

*.xad -> *.wad -- отличаются порядком байт, конвертация тривиальна

*.xbn -> *.wdn -- отличаются порядком байт, конвертация тривиальна
*.xbd -> *.wbd -- отличаются порядком байт, конвертация тривиальна

Неизвестно:
*.anim -> ? -- в PC версии отсутствуют (но код для чтения 'ANI8' есть)

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

Но это все, как говорится, цветочки.
Ягодки находятся в каталоге audio.
Формат audio-файлов слабо изучен.

Я как раз пару дней назад пытался посмотреть, что там да как.
По структуре файлы такие же, как на ПК, только порядок байт другой.
Кстати я бы не сказал, что там уже и слабо изучено я процентов +50% полей и их назначения знаю

Метод компрессии - неизвестен (предположительно, это xWMA).

А вот сжатие да, это что-то интересное. Мне все-таки кажется, что там вместо ADPCM используется XMA, а не xWMA т.к. тогда бы они использовали его на обеих платформах (см. XACT).
Также в игре есть некоторые маленькие звуки, которые просто в PCM (и там и тут) так вот в них тоже порядок байт разный.

[Dageron]

*.xpl -> *.wpl -- (+) предположительно разобран (или я что-то путаю?)

Не только разобран, но и сконвертированно уже все.

[listener]

Из свежих новостей: xdr практически разобран (все, кроме той части, что относится к шейдерам). Изменения очень небольшие (в основном, порядок байтов). Самая сложная часть - вертексные декларации - вгера была разобрана. Если не найдется ничего страшного в shader group, то можно будет заняться конверсией.

[listener]

Я наблюдаю на gtaf какую-то нездоровую активность на тему 360-х форматов. Если какие-то ресурсы нужны в распакованном виде - могу выложить (могу даже сразу сконвертировать)

[Dageron]

Я наблюдаю на gtaf какую-то нездоровую активность на тему 360-х форматов.

Почему такая активность может считаться нездоровой? (Что, интересно знать, по поводу всего этого в приват-разделах говорят?..) Просто люди заинтересовались X360 наконец и TLaD послужил хорошим толчком.
Однако, ничего вразумительного по поводу метода упаковки там так ничего и не сказали, разве что дали ссылку на LZX-распаковщик Amiga (бесполезная вещь, для Win95) и что-то про XeXDK говорили. Кроме того один человек вообще сказал что это не сжатие а шифровка, но это уже запредельство.

Если какие-то ресурсы нужны в распакованном виде - могу выложить (могу даже сразу сконвертировать)

Мне честно говоря давно хотелось на XTD в распакованном виде взглянуть (sys/gfx segments), просто сравнить чем от WTD отличаются по большому счету, даже от оригинального IV можно, те же HUD или BLIPS.
Сконвертированные RSC тоже хотелось бы увидеть конечно же, особенно модели. (их-то никто толком не менял вообще )

Сообщение отредактировал Dageron: 24 May 2009 - 15:28

[listener]

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

В любом случае, однго описания работы XMemDecompress мало. Для текстур нужны еще формат пикселя и метод swizzling-а. И то, и другое - достаточно сложны.

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

Распакованные hud.xtd и blips.xtd из TLaD: http://public.sannyb...d_blips_360.rar
Основное отличие - rage::grcTextureXenon вместо rage::grcTexturePC (отличается парой полей).
Сами пиксельные данные - swizzled и, обычно, big-endian (описывается в поле формата текселя)

[Dageron]

Распакованные hud.xtd и blips.xtd из TLaD

Спасибо, очень интересно взглянуть на них. Давняя мечта так скажем
Кстати, это правда что в третьем поле RSC имеется значение, отвечающее за то, запакован ресурс или нет?

В любом случае, однго описания работы XMemDecompress мало. Для текстур нужны еще формат пикселя и метод swizzling-а. И то, и другое - достаточно сложны.
Основное отличие - rage::grcTextureXenon вместо rage::grcTexturePC (отличается парой полей).
Сами пиксельные данные - swizzled и, обычно, big-endian (описывается в поле формата текселя)

Вот что нашел в исходниках SparkIV касательно X360 текстур.
DXT-decoder и TextureDecoder (процедуры закомментированы, но ничего не удалено).
LZX-распаковка тоже там есть, но, как ни странно, основная часть кода удалена, остальное закомментировано.

По понятным причинам, люди, имеющие доступ к XeDK не торопятся об этом заявлять.

Но форумы где они собираются и говорят есть и довольно интересные...

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

Можно все-таки пояснить с чего это все началось? Просто не понимаю какие такие причины могут столь препятствовать распространению информации.
Проблема с пиратством - истинно Российская. Врят ли gtaF staff стали бы вести разработки в секрете из-за предотвращения какой-то русской версии GTA IV (которая кстати все равно была создана хз кем).
Проблема с борьбой на консольные любительские моды (+использование взломанных консолей)- не мешает сделать публичный просмотрщик тех же .xtd (думаю, все помнят ps2textureviewer для III/VC/SA от steve-m и gtastoriestex от aru). Кроме того, что-то не особо они предотвращают темы о консольном моддинге когда кто-нибудь спрашивает как модифицировать X360 версию (и про PS3 спрашивали как-то, даже дали мне common.rpf и ps3.rpf тамошние где совсем новое шифрование; но разговор это уже отдельный...).
Был однако один инцидент когда когда человек задал вопрос про простые dat-моды и как корректно диск записывать - я постарался все более-менее разъяснить, но его разговор зашел про лайв-читерство и тогда мне осталось только про бан предупредить, что, мол, как пользователя пираток. Тему внезапно снесли, а мне вот такое вот письмо пришло; не предупреждения, ни чего более не выдали. Но и то, все это произошло из-за того что коснулись столь больной для gtaF темы как сетевое читерство... Вообще, никогда сам читеров не понимал - очень неприятно смотреть видео на YouTube в последнее врея где видео X360 Live-модов уже за десяток перевалило (причем не только где RPF редактировано, а еще и хак через Grand Theft Modification).
На gtaF нигде в правилах не висит запрет на консольные модификации, будь то старых игр, будь то IV. Зато висит предупреждение о сетевых модах.
Конечно, те решения, которые принимаются в закрытых разделах могут остаться загадкой для простых людей навсегда (кроме того, абсолютно не понятно по какому критерию людям туда доступ дают, за какие заслуги), но все-таки хотелось бы узнать обоснование этому.

Сообщение отредактировал Dageron: 25 May 2009 - 03:43

[listener]

Кстати, это правда что в третьем поле RSC имеется значение, отвечающее за то, запакован ресурс или нет?

Да, два старших бита поля флагов - RSC_PAGED и RSC_COMPRESSED (не залезая в исходники, не вспомню, точные значения).

Внутри audio-rpf есть ресурсы, которые PAGED, но не COMPRESSED (предположительно, анимация для lip-sync)

У aru нет нормальной работы с xenon-овскими текстурами (по крайней мере, я этого не видел). У него есть несколько наиболее распространенных случаев. (Сначала не было полной информации, потом - похоже, просто заломало приделывать)

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

Со всякими SDK - еще хуже. Поскольку они предоставляются только под NDA, появление любой информации из SDK - однозначно свидетельствует о том, что имел место факт нарушения NDA.

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

[Dageron]

Что касается распространения информации, основная ограничивающая вещь - это DMCA. Ключи шифрования, алгоритмы и и т.д. - по буржуйскому законодательству, являются объектами авторского права (по российским законам - нет, кроме того, у нас законодательно разрешен reverse engineering, хотя и с некоторыми ограничениями).
Со всякими SDK - еще хуже. Поскольку они предоставляются только под NDA, появление любой информации из SDK - однозначно свидетельствует о том, что имел место факт нарушения NDA.
Начала истории с консольными модификациями на gtaf я не застал. Возможно, были какие-то наезды, возможно - народ просто решил подстраховаться.

Спасибо за ответ. Значит шифровка содержалась в секрете так как извлечение PPC exe из .xex нелегально, а распространение ключа и подавно... LZX спорная вещь поскольку описание входит в состав XeDK. Ну что же, теперь основания становятся понятными. Но все-таки держать информацию о разработках программ (и самое главное - описания форматов) в секрете не очень хорошо. По этому возникает вопрос за какие заслуги можно получить доступ в эти самые разделы? (открытие там какое сделать в сфере изучения форматов, программу особенную)

Да, два старших бита поля флагов - RSC_PAGED и RSC_COMPRESSED (не залезая в исходники, не вспомню, точные значения).
Внутри audio-rpf есть ресурсы, которые PAGED, но не COMPRESSED (предположительно, анимация для lip-sync)

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

Сообщение отредактировал Dageron: 25 May 2009 - 16:54

[GooD-NTS]

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

Можно, сделать так, например вот у тебя есть функции для проверки флагов на сжатие и "страничность":

const
  cFlagPaged = $80000000;
  cFlagCompressed = $40000000;

function IsPaged(Flags: DWORD): Boolean; InLine;
begin
 Result:= (Flags AND cFlagPaged) = cFlagPaged;
end;

function IsCompressed(Flags: DWORD): Boolean; InLine;
begin
 Result:= (Flags AND cFlagCompressed) = cFlagCompressed;
end;

//  Для того чтобы убрать флаг сжатия, надо сделать так:
Flags:= Flags AND NOT cFlagCompressed;

По идеи должно работать, только я не проверял. Проверяй