Console Texture Explorer (PSP/PS2)
#1
Отправлено 17 July 2012 - 12:33
С помощью данной программы можно извлечь (и заменить) порядка ~80% текстур разных видеоигр на PSP и PS2. Не так все просто, конечно, нужно знать адрес текстуры и ее параметры (подробности см. на wiki), но ручную работу, которую ранее приходилось делать в hex и каком-нибудь *.tm2-редакторе, программа должна существенно облегчить.
Несколько скриншотов:
В зависимости от конкретных условий параметры текстуры можно подобрать, а ее адрес и bpp определить "визуально" в любом hex-редакторе. Из размера палитры, например, следует bpp текстуры, она занимает 64 байта для 4-битных и 1024 байта для 8-битных (найти же ее достаточно просто по характерным симметричным данным со столбцами "FF" или "80"). Далее, указав в программе оффсет палитры и bpp текстуры, можно начать подбирать адрес начала графики и width/height. Делать это тоже лучше с умом - для 8-битных размер текстуры рассчитывается как "width*height", для 4-битных - как "(width*heigth) div 2".
И так далее.
К сожалению методы для разбора графики в двух словах не описать, они нетривиальны по своей сути и строятся в большинстве своем только на опыте, пробах и ошибках. И, в конечном счете, все определяется конкретной задачей и конкретными условиями. Если будет время, постараюсь описать что-нибудь подробно со скриншотами, чтобы новичкам тоже было понятно.
#4
Отправлено 17 July 2012 - 19:03
Пока что читаются параметры текстур из папки TXD без ошибок. Естественно, что готового описания формата текстур с PSP в свободном доступе нету, поэтому прищлось их придумывать самому (все необходимые параметры для просмотра текстур разобрал, а вот остальные данные заголовка проверять не стал - может быть они вообще игрой не используются).
Экспорт сделаю, а вот импорт обещать не могу, там возникнет проблема с альфа-каналом.
Ну хотя б можешь предложить какое-нибудь простое средство, чтобы любую 32-х битную текстуру можно было быстро пережать в tm2 в 4 или 8 бит. А то из простой рисовалки как текстуры в игру перегонять без использования промежуточных средств?
Сообщение отредактировал XEPOMAHT007: 17 July 2012 - 21:07
BETA 4.0 COMING SOON
#5
Отправлено 18 July 2012 - 05:25
- Списки содержимого (*.ini) подгружаются автоматически при открытии текстуры (если имена совпадают).
- Добавлен экспорт текстуры в *.bmp и *.cmpl (что за формат такой и где его удобно применять, расскажу позднее, импорт из него тоже будет реализован). При нажатии на кнопку "Export" должен появляться список с выбором (на версиях Windows ниже седьмой bsSplitButton не предусмотрены, поэтому по кнопке нужно щелкнуть правой кнопкой мыши).
Там должна быть таблица оффсетов, влияющая на распределения памяти при загрузке. К сожалению, игрой она используется, поэтому для полной пересборки ресурса надо вникать в ее устройство.остальные данные заголовка проверять не стал - может быть они вообще игрой не используются
Хорошо, постараюсь сделать, но не в ближайшее время (сейчас нужно еще много дел разобрать).Ну хотя б можешь предложить какое-нибудь простое средство, чтобы любую 32-х битную текстуру можно было быстро пережать в tm2 в 4 или 8 бит. А то из простой рисовалки как текстуры в игру перегонять без использования промежуточных средств?
#6
Отправлено 18 July 2012 - 08:13
при таком преобразовании (2^32 -> 2^4) получаются огромные потери, так что лучше делать это в фотошопе. тем более, что TM2 плагин есть.Ну хотя б можешь предложить какое-нибудь простое средство, чтобы любую 32-х битную текстуру можно было быстро пережать в tm2 в 4 или 8 бит. А то из простой рисовалки как текстуры в игру перегонять без использования промежуточных средств?
Проблема в том, что в текстурах с палитрой RGBA за альфу отвечает 4 компонент A. И альфа канал это тот же самый растр, только вместо RGB он использует AAA. Соответственно, для создания такого альфа-канала нужен алгоритм, который постороит специальную палитру, где у каждого цвета будет задана прозрачность. Такое извращение довольно неудобно, особенно если нужно иметь много цветов при мягких градиентах, поэтому в GTA3 PS2 почти все полупрозрачные текстуры были 32-битными.
афайк, ни один из известных TXD-редакторов для ПК не производит эту замену нормально. Но на компе-то это и не надо, там, в основном, беспалитровые текстуры.
к чему я это всё? к тому что, замена BMP, которую сделает Dageron (если не напишет /найдёт алгоритм) не позволит нормально работать с альфой - юзай сторонний софт.
пользуясь случаем, передаю привет своей бабушке:
- хех, если бы "ini" был программируемым, то почти цены бы проге не было (надо ещё допилить 16, 24 и 32 бита - они тоже существуют).
- и ещё я бы добавил в поля оффсетов стрелки, увеличивающие или уменьшающие адрес на байт - можно было бы "двигаться" по файлу - для "новичков" самое то. а текстуру рендерить по любому изменению, а не только по кнопке.
- почему так - если текстура содержит мипмапы, то палитра должна идти сразу за мипмапами? вообще, как связаны здесь мипмапы и палтра? O_o ответ на этот вопрос за гранью моего сознания. пример тому, скажем, текстура models/gta3.img/bones.txd из GTA SA PS2. палитра как отсчитывалась через N байт, так и отсчитывается, просто появились мипмапы и всё.
- а вот окошко "о программе" скучновато. непорядок.
Сообщение отредактировал Lego: 18 July 2012 - 09:03
#7
Отправлено 18 July 2012 - 11:46
- хех, если бы "ini" был программируемым, то почти цены бы проге не было
Главное, что прога умеет читать текстуру со свизилингом и палитру. Например, у меня есть распаковщик архивов от GTA CW, если добавить в распаковку генератор ini для всех текстур, то распакованные файлы с текстурами автоматически будут открываться в Console Texture Explorer, редактироваться, сохраняться, а потом файлик можно будет заменить в архиве той же прогой, которой архив был распатронен.
BETA 4.0 COMING SOON
#8
Отправлено 18 July 2012 - 17:20
В теории (и при очень большом желании) можно прикрутить что-то наподобие luadec и сделать команды для навигации по файлу, но для маленького проекта эта задача слишком большая и серьезная. Кроме того поддержка программируемых скриптов есть в крупных программах для разбора игровых ресурсов, вроде Hyper Ripper (см. форум XenTax - там любят подобные штуки).хех, если бы "ini" был программируемым, то почти цены бы проге не было (надо ещё допилить 16, 24 и 32 бита - они тоже существуют).
Поддержку 16bpp/24bpp/32bpp постараюсь конечно сделать, просто пока такие текстуры мне не попадались (и честно говоря я сомневаюсь, что можно собрать *.tm2 с такой глубиной цвета, так что экспорт/импорт придется переделывать основательно и додумывать).
Отличная идея с кнопками). В следующей версии обязательно сделаю. Пользователь сам сможет вводить размер данных, который будет прибавляться к текущему оффсету (или вычитаться). Это действительно удобно, например, если смещаться по блокам на число байт, кратное шестнадцати (или даже по секторам, т.е. по 2048).и ещё я бы добавил в поля оффсетов стрелки, увеличивающие или уменьшающие адрес на байт - можно было бы "двигаться" по файлу - для "новичков" самое то. а текстуру рендерить по любому изменению, а не только по кнопке.
Вопрос - нужно ли отображение (и редактирование) оффсетов в шестнадцатиричном виде?
Палитра обычно идет сразу после текстуры, к которой она относится. Если есть мипмапы, то после текстуры идут они, а за ними уже в таком случае следует палитра (для текстуры и ее мипмапов она общая).почему так - если текстура содержит мипмапы, то палитра должна идти сразу за мипмапами? вообще, как связаны здесь мипмапы и палтра? O_o ответ на этот вопрос за гранью моего сознания. пример тому, скажем, текстура models/gta3.img/bones.txd из GTA SA PS2. палитра как отсчитывалась через N байт, так и отсчитывается, просто появились мипмапы и всё.
San Andreas (и вообще RW) не слишком хороший пример, там палитра вообще хранится отдельно от графики, вне зависимости от того, есть у нее мипмапы или нет. Это, честно говоря, довольно странно выглядит, в других играх подобных случаев не встречал, даже в LCS/VCS/CTW палитра всегда идет сразу после текстуры.
Этот момент, кстати, тебе лучше поправить в TXD_2048. Применительно к тому PS2-изображению (плакат Мэдд Дога - пять уровней mipmaps, 4bpp) оффсет палитры получитcя: [оффсет начала изображения] + [(128*256) div 2] + [(64*128) div 2] + [(32*64) div 2] + [(16*32) div 2] + [(8*16) div 2]. В PSP-версии ширина при переходе на каждый "нижний" уровень мипмапов на два делится только до 32, дальше такое значение и остается (высота при том продолжает делиться, т.е. пропорции текстуры на "нижних" уровнях меняются).
#9
Отправлено 18 July 2012 - 21:14
1) 24 бита мне попадались только на икс-боксе. а вот 16 бит и 24 - полно, особенно в GTA3. если что тебе в помощь мои списки "специфичных" текстур в GTA3 и SA. по ним я тестировал TXD_2048.Поддержку 16bpp/24bpp/32bpp постараюсь конечно сделать, просто пока такие текстуры мне не попадались (и честно говоря я сомневаюсь, что можно собрать *.tm2 с такой глубиной цвета, так что экспорт/импорт придется переделывать основательно и додумывать).
2) насчёт TM2 я уже сам не помню, сделал ли я поддержку 16 и 32 бит, но дело не в этом. дело в том, что беспалитровые форматы (16, 32) без проблем конвертятся в BMP-шки (так что на TIM2 тут можешь, в принципе, забить).
3) Конечно в шестнадцатиричном. Хотя, у тебя сейчас работает и в шестнадцатиричном (0x10) и в десятичном (16) так что всё ок.Вопрос - нужно ли отображение (и редактирование) оффсетов в шестнадцатиричном виде?
4) как раз таки хороший. и не SA, а вообще весь RW3.San Andreas (и вообще RW) не слишком хороший пример
просто сделай галку "мипмапы после растра" и всё. оффсет палитры нужно всегда задавать вручную. (или он может быть вычислен автоматически, но, в последствии, изменён).
при этом в INI желательно задать смещение мипмапов относительно друг друга, если это ещё не реализовано (на ПК, вроде, 2 байта между мипмапами было).
5) на мою реализацию TEX лучше вообще не смотри: она ужасна. сделана была буквально за чашечкой кофе "just for lulz" и, толком, поддерживает только VCS PS2.
[оффтоп=Chipsman, сделай спойлер]
сейчас у меня тут работы дофига и ещё один проектик висит который для меня важен. как только появится время допилю TXD_2048 до нормальной кондиции.
[/оффтоп]
Сообщение отредактировал Lego: 18 July 2012 - 21:17
#10
Отправлено 20 July 2012 - 11:28
А что-нибудь известно об основных форматах текстур в играх на боксе? Ну там же не tm2 используется насколько я предполагаю? Например txd workshop поддерживает конверт в бокс формат начиная с вайса, но в других не гта играх все-равно tim2 используется разве?1) 24 бита мне попадались только на икс-боксе.
#12
Отправлено 20 July 2012 - 14:04
Попробуй использовать Xbox TXD Power Tool.
Эту программу я не тестировал, но по идее работать она должна).
#13
Отправлено 20 July 2012 - 22:17
SILENT_Pavel
Попробуй использовать Xbox TXD Power Tool.
Эту программу я не тестировал, но по идее работать она должна).
Она альфа-канал вообще читать (и возможно редактировать тоже) не хочет. Очень странная программа.
PS: теперь кстати возможна ПОЛНАЯ конвертация карты X-Box версии GTA3 например на СА:
1. Проверил эффект лайтинга по текстуре из икс-бокса в СА - как ни странно работает (на модели я не экспортировал тройной UV - для лайтинга движок СА использует как раз третий канал UV-координат. Соответственно, на сей момент тройной UV ни КАМом, ни Денискиным экспортёром перегнать из икс-бокса невозможно, т.к. они его просто не поддерживают).
http://s019.radikal....3e3a666d76d.jpg
2. Немного поразбирал секцию Native Data PLG от икс-гроба, написал иморт мешей. Неожиданным оказалось то, что формат очень и очень похож на то, что мы уже видели в формате моделей GTA4, вполе возможно, что вот оно, недостающее звено в эволюции
http://s017.radikal....67c7fd19ace.jpg
BETA 4.0 COMING SOON
#14
Отправлено 24 July 2012 - 05:50
Версия и ссылка старые, так как изменения небольшие.
Давайте все же обсуждать Xbox-моддинг в другой теме, например, тут).
Чтобы материал собирался структурно и потом было легче ориентироваться по форуму.
Ответить
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных