[Dageron]

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

[listener]

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

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

[Dageron]

А смысл писать? что "возможен", но c чего-то вдруг "запрещен"? Все равно мир не увидит вашу OpenIV с функцией редактирования *.xtd.
Может только позже другие редакторы появятся.

[listener]

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

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

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

[Dageron]

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

Никто за полгода просто не мог извлечь их из Xbox360.rpf, в результате это удалось только после того, как aru выложил SparkIV и вы выложили свою OpenIV.
И не так уж и мало информации по x360-форматам можно найти. Например, по сжатию.

[listener]

Кстати, ведь люди с gtaF их тоже разбирали вроде как?

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

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

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

Никто за полгода просто не мог извлечь их из Xbox360.rpf, в результате это удалось только после того, как aru выложил SparkIV и вы выложили свою OpenIV.

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

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

И не так уж и мало информации по x360-форматам можно найти. Например, по сжатию.

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

[Dageron]

Вы сделали - молодцы. Но, надеюсь, будут и другие.
Так как направление работы как нельзя более интересное.

[Dageron]

Итак, барьер XMemDecompress преодолен. Пришлось подгружать xcompress32.dll из Xbox Development Kit SDK.
Отныне и я могу распаковывать x360 RSC.

Если кто-то не верит, могу дать наброски своей программы или выложить распакованные ресурсы.

[JNikc]

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

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

[Dageron]

Продолжения обсуждения x360 ресурсов тут.

[Dageron]

Возвращаясь к теме (обсуждение *.wtd)...

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

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

[listener]

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

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

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

[Dageron]

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

[RussianCJ]

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

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

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

[RussianCJ]

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

[Dageron]

Перенес сообщение в нужную тему, чтобы обсуждение не разбивалось по всему форуму.
Я тоже делал своеобразный WTD Builder, но полнофункциональной работы достичь не удалось:

[RussianCJ]

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

[Dageron]

Очень хорошо. Теперь остается только понять смысл m_pPrev и m_pNext.

Судя по всему это указатели на предыдущую и последующую текстуры соответственно. Однако подозрительно то, что в некоторых *.wtd эти поля не инициализированы.
Так что не факт, что эти поля используются игрой (или вообще может они имеют другое назначение).

[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