[Dageron]

Это тема для обсуждения статьи: WTD

[listener]

К строке "Просмотр и редактирование консольных форматов невозможен" не хватает только скриншота OpenIV с открытой .xtd-шкой...
Например, этого: http://www.picamatic.com/view/637602_xtd/

На PS3, насколько я смотрел по коду, должны быть .ctd (Cell Texture Dictionary).

[Dageron]

а смысл писать что "возможен", но "типа запрещен"? всеравно свет не увидит вашу OpenIV с функцией редактирования XTD. Может только позже другие редакторы появятся. Про PS3 вообще лучше ничего не писать так как всеравно не получится запустить самопальный образ игры

[listener]

"невозможен" - это фактическая ошибка. (что подтверждается скриншотами)
"не поддерживается публичными версиями" или "реализовано во внутренних версиях" вполне корректные обтекаемые формулировки.

Насчет того, что появится - маловероятно. У меня, для того, чтобы привести xtd, к какому-то просматриваемому виду, ушло три ночи ковыряния в гугле, чтения ATI-шных мануалов, проб и ошибок. (Особая прелесть в том, что я сделал это, пользуясь только открытыми источниками). Если никто за полгода не смог этого повторить - маловероятно, что это будет сделано в будущем.

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

[Dageron]

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

P.S. Никто за полгода просто не мог извлечь их из Xbox360.rpf Благо теперь и SparkIV и ваша OpenIV его спокойно открывают и изменяют...
И не так уж и мало инфы по ксеноновому формату найти можно...

[listener]

Кстати, ведь люди с форумса их тоже разбирали вроде

Как бы это сказать... Знаешь, какое первое правило совпадает со вторым?

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

Тогда просто их не упомянать (чтобы не было вопросов :-) ). А то начнут спрашивать про доставание моделй из Midnight Club :-)

P.S. Никто за полгода просто не мог извлечь их из Xbox360.rpf Благо теперь и SparkIV и ваша OpenIV его спокойно открывают и изменяют...

С rpf-то все просто. У меня на него ушло 8 часов. Более того, я открою маленькую тайну: все имеющиеся сейчас программы для просмотра/редактирования rpf - модифицированные версии утилит, работавших с 360-ми форматами. Мне просто обидно: неужели кроме этих ~10 человек не нашлось никого, у кого бы "желания совпадали с возможностями".

Кстати, про "наш" OpenIV и "их" SparkIV. Не хвастовства ради, а точности для: в SparkIV 0.2.2 работа с xtd базировалась на моем коде.

И не так уж и мало инфы по ксеноновому формату найти можно...

По выводу - найти не проблема. Проблема - найти обратное преобразование: из xenos-овского фрэймбуфера в битмап. (Найти можно, но копать надо глубже).

[Dageron]

=======================================

Тогда просто их не упомянать (чтобы не было вопросов :-) ). А то начнут спрашивать про доставание моделй из Midnight Club :-)

Да, пожалуй, это действительно будет гораздо более правильно.

С rpf-то все просто. У меня на него ушло 8 часов. Более того, я открою маленькую тайну: все имеющиеся сейчас программы для просмотра/редактирования rpf - модифицированные версии утилит, работавших с 360-ми форматами. Мне просто обидно: неужели кроме этих ~10 человек не нашлось никого, у кого бы "желания совпадали с возможностями".

Да, и OpenIV и SparkIV идеально редактируют common.rpf и xbox360.rpf. Протестить работоспособность измененных архивов бокса пока не удавалось, но, думаю, получится на след. неделе Знаю только что там есть такой ньюанс - размер файла "до" должен быть равен размеру файла "после". Т.е. в идеале лучше чтобы измененный файл был меньше оригинального, тогда восполнить размер через HEX будет просто элементарно.

Кстати, про "наш" OpenIV и "их" SparkIV. Не хвастовства ради, а точности для: в SparkIV 0.2.2 работа с xtd базировалась на моем коде.

Да, даже если Aru не выкинул еще старую версию, врятли ее он выдаст когда-либо...

По выводу - найти не проблема. Проблема - найти обратное преобразование: из xenos-овского фрэймбуфера в битмап. (Найти можно, но копать надо глубже).

Вы сделали - молодцы. Надеюсь, будут и другие

=======================================
Ладно, это был оффтоп уже) По сабжу - вы собираетесь опубликовывать описания WTD формата и алгоритмы работы с ним?

[Dageron]

Итак, барьер XMemDecompress преодален (благодаря xcompress32.dll из Xbox Development Kit SDK).
Отныне и я могу распаковывать x360 RSC (правда, пока только big-endian) Если кто-то не верит, могу дать эту программу или же выложить распакованные.

Сообщение отредактировал Dageron - 23.6.2009, 6:56

[JNikc]

могу дать эту программу или же выложить распакованные.

Очень хочется это увидеть! (open, open) . Мне бы тоже хотелось разобраться в форматах игры.

[Dageron]

Продолжение (если не видел )

Весь смысл в том что я не хочу распространять распаковщик и, в особенности, LZX dll. Будет крайне нехорошо если информация попадет на публику и еще до кучи потом скажут что я ее слил (хотя достал ее сам...).
Другое дело если найдется человек, реально способный помочь с x360 swizzling-ом и вообще разбором графических данных непосредственно... В теме про портирование DLC listener выкладывал распакованные ресурсы, посмотри их если интересно:
http://forums.gtamodding.ru/index.php?s=&a...post&p=2007
Под основу изучения можно взять и wtd, но на PC текстурные RSC отличаются и гораздо проще по строению, а так же графическим данным +запаковка всего лишь zlib.

p.s. Странно, второй день и не одного коммента от тех кто еще год назад с XMemDecompress разобрался.

Сообщение отредактировал Dageron - 24.6.2009, 15:49

[Dageron]

Выкладываю в wiki шаблон для 010 Editor - wtd.bt. Статус beta, соответственно приветствуются исправления (см. комментарии). Запускать рекомендуется на sys (cpu) части распакованного RSC.

Базировалось на:
http://public.sannybuilder.com/GTA4/rsc_en.txt
http://gtaivtools.googlecode.com/
(часть названий и структур взята именно оттуда)

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

Сообщение отредактировал Dageron - 13.7.2009, 11:30

[listener]

Угу, хорошо.
Есть несколько замечаний: во-первых, имеет смысл сделать отдельную структуру для CSimpleCollection (как бы его обозвать более адекватно: datArray, sysArray или memArray ?). Аналогично - для CPtrCollection.

После этого,
GetOffset TextureListOffset;
short TextureCount3;
short TextureCount4;
Превратятся в один CPtrCollection, из которго и будут браться смещения для grcTexturePC.

Во-вторых, GetOffset RawDataOffset; имеет смысл сделать просто числом, т.к. это смещение в GPU блоке.
В-третьих, в GetOffset имеет смысл проверять старшие четыре бита: в них должно быть 5, иначе это смещение невалидно.

[Dageron]

Исправил многие недочеты, в частности, теперь есть чтение и HashTable и TextureOffsetTable => нормально читаются все остальные параметры.

Теперь главное вывести иерархию и правильное название классов.

Сообщение отредактировал Dageron - 14.7.2009, 6:41

[RussianCJ]

Мож быть кто подскажет...

Я пишу конвертёр TXD2WTD. Но возникла проблема с конвертированием несжатых текстур. Дело в том, что я не могу понять, как нужно вставлять экспортнутый из TXD массив пикселей в GPU часть WTD файла. Ни SparkIV, ни G-Texture при обычном импорте массива не хотят нормально прочесть получившийся WTD. Каким образом нужно делать правильную запись несжатых текстур?

Если это никому неизвестно, то объясните хотя бы, как нужно правильно записывать DDS с несжатой текстурой?

[RussianCJ]

Доброго времени суток. У меня возникла проблема с сохранением WTD через свою программу. Дело в том, что при входе в игру одни и те же текстуры как будто рассыпаны, иногда могут появляться цветные квадратики - одним словом, с глюками, но иногда некоторые из них рендерятся целыми. При проверке через всевозможные редакторы WTD не было выявлено ни одного подобного глюка. Программа написана на Delphi, некоторые исходники взяты из справочного материала этого сайта. Прошу помочь как можно скорее.

[Dageron]

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

Мне тоже очень интересны возможные причины проблем с отображением текстур и возможные варианты их решения. Все дело в том что тоже для себя сделал/делаю достаточно простой WTD Builder. Вот простой скрин:

(как выглядит пример работы с программой - иными словами я извлек все текстуры из loadscreens.xtd и собрал new.wtd через программу)

Сообщение отредактировал Dageron - 27.8.2009, 10:53

[RussianCJ]

Я внёс небольшие изменения в шаблон в статье WTD. Была поправлена неточность насчёт байтов, относящихся к уровням текстур. На самом деле, к уровням текстур относился только четвёртый байт. Первые 2 байта - это количество байтов, затраченных на строку пикселей в изображений (при создании WTD вычислить крайне просто: во всех типах сжатия, кроме DXT1, это число будет равно ширине изображения, а при DXT1 - половине ширины изображения), а третий байт - это тип текстуры (1 - cube текстура, 2 - volume текстура, другие числа - regular текстура; чаще используется последнее).

[Dageron]

Очень хорошо. Теперь остается только понять смысл m_pPrev и m_pNext.
m_pPrev - оффсет какой-то grcTexturePC, но не предыдущей как предполагалось.
m_pNext - всегда нуль.

[RussianCJ]

Насчёт своей проблемы: выкладываю скрин...



...и текстурный архив, который при этом использовался:
http://www.rapidshare.ru/1149437

[listener]

При работе, структуры в памяти собираются в связный списк. m_pPrev, m_pNext - это оно и есть.
В файле можно не инициализировать (как и m_piTexture (_f18)).

что касается бьющихся текстур - пробовать мне сейчас некогда, так что ограничусь несколькими предположениями:
* выход за границы страницы (построить из флагов карту страниц и проверить)
* некорректно положены mip-ы (я не помню, как у них берется выравнивание, нужно смотреть загрузку grcTexturePC, благо, что там каждый левел грузится отдельно)
* некорректное выравнивание (если мне не изменяет мой склероз, размер строки должн округляться то ли до 32 байт, то ли до 32 текселей)


Еще, в тему - для volume/cube текстур, назначение полей width/height/depth/levels может отличаться.
Тип для Volume текстур - не 2, а 3