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

[XEPOMAHT007]

Я ведь скидывал летом свои актуальные на тот момент наработки по коду для обработки текстур. Из них не удалось тогда соорудить что-нибудь?) У меня сейчас в текущей версии Texture Explorer-а используется фактически тот же код с некоторыми преобразованиями (в основном по mipmap-ам), скорость работы вполне приличная.

Твой код очень большой и мне не удалось с ним разобраться. Я у себя написал очень простой и низкоуровневый попиксельный вывод текстуры на форму - в полном соответствии с CHK насколько это возможно реализовать на дельфе, используя мои знания (весь код чтения текстуры и вывода её на форму - 16 строчек всего, правда от этого и работают он очень медленно - видно как на экране отрисовывается текстура, может быть из-за того, что перекрашивается сама форма, причём если ткнуть мышью по форме, то рисунок пропадает, не знаю, с чем это может быть связано...).

[Lego]

> strtohex и hextostr
глаза. боль. you're doin' it wrong. эти функции нужны для преобразования числа в массив символов, но ни как не для того, чтобы заменить побитовые операции.

> очень и очень медленно из-за того, что Дельфой нельзя прочитать полбайта за раз
я те больше скажу (особо не вдаваясь в подробности) минимальной адресуемой единицей информации на твоём компе является БАЙТ, поэтому ты никак не сможешь считать полбайта попросту потому что ты не можешь их никак адресовать. и все оффсеты в функциями работы с файлами тоже используют байтовые оффсеты. (то есть конечно можно путём каких-нибудь нетривиальных извращений считать ровно 4 бита с твоего винта, но это нужно быть знатным извращенцем).
поэтому ты должен считать байт полностью, а потом побитовыми (ну или двоичными) операциями обнулить ненужную тебе половину байта [и сдвинуть нужно на полбайта]. ну как-то так (на си):

int a = 0x12;
int b = 0x0F & a; // 0x02
int c = ( 0xF0 & a ) >> 4; // 0x01

Сообщение отредактировал Lego: 11 January 2012 - 04:32

[XEPOMAHT007]

> strtohex и hextostr
глаза. боль. you're doin' it wrong. эти функции нужны для преобразования числа в массив символов, но ни как не для того, чтобы заменить побитовые операции.

Как тогда 16-ти разрядные числа дельфой читать? Она зараза только значение из байта извлекает, которое приходится операцией strtohex перегонять в 16-ти разрядное, что соответственно замедляет работу программы.

[Lego]

если честно, не очень понимаю что ты спрашиваешь. если ты хочешь вывести на экран (форму) то норм. если тебе нужно 4 младшиих или старших бита, то я уже расписал как это сделать без использования строк (на дельфи разве что вместо & будет and, вместо >> будет shr, а вместо 0xNN вроде будет $NN)

Сообщение отредактировал Lego: 11 January 2012 - 07:27

[SILENT_Pavel]

Провел свой маленький мини-тест порта деревьев с нуля. В этом тесте я ничего не изменял кроме размера, оказался конфликт альфы, её необходимо было модифицировать для более корректного отображения на псп, после этого там обнаружилось аж целых 7 мип-мапов, последние из которых адовые, но тем не менее перерисовав обнаружил что мипы далее пятого, четвертого номера все еще не корректны (при отдалении от деревьев артефакты), надо будет дорабатывать...

Прикрепленные изображения

• 

Сообщение отредактировал SILENT_Pavel: 18 September 2012 - 05:37

[Dageron]

Судя по всему ты тоже не те деревья заменил на новые . Я когда менял просто извлекал с PS2-версии текстуру начиная со второго уровня мипмапов. На PSP, соответственно, менял начиная с первого (т.к. на PS2 текстура просто в два раза больше - значит первый уровень с PS2 не нужен). Дальше третьего уровня на PSP можно даже не соваться, заменять "нижние" уровни смысла нет).

[SILENT_Pavel]

Да, вот альфы всех основных деревьев псп.

Прикрепленные изображения

• 
• 

[XEPOMAHT007]

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

[Lego]

почитай хотя бы про device-independent bitmap (DIB), он будет рендерится за доли секунд и альфу ты сможешь сделать нормальную а не 1/0. > Домучил свой код свизлинга для всех 4х-битных текстур ЛСС <...> из строк формируются прямоугольники, а из прямоугольников формируется сама текстура, не удивительно, что на эмуляторе ЛСС так жестоко тормозит...) ну ты сравнил, на PCSX2 твой свиззлинг написан на ассемблере, а рендер происходит на DirectX, лол.

Сообщение отредактировал Lego: 16 January 2012 - 23:05

[LEX SAFONOV]

Меня всегда интересовали зашифрованые архивы LCS\VCS, на вики вроде особо нет никакой инфы по ним(по офсетам и т.п., как в архивах сана например). Будет ли когда нибудь информация выложена в свободный доступ?(если она конечно есть, хоть какая).

[Dageron]

На самом деле они не зашифрованные, просто их структура (с учетом структуры wrld), как говорится, is too complicated). Для начала следует разделить задачи. 1. Задача первая - получить всю информацию о wrld-файлах, либо извлечь их из *.img/*.lvz "в открытом виде". 2. Задача вторая - получить необходимые данные из wrld-ов (например, текстуры). Я подробно распишу первый этап, поскольку второй на самом деле очень объемный, с ходу весь процесс не описать. В общем, допустим у нас есть некоторый *.img-архив и соответствующий ему *.lvz. Не важно, какой именной игры (LCS/VCS) и какой именно платформы (PSP/PS2). Для начала нужно распаковать *.lvz через какой-нибудь zlib-распаковщик и подготовить два файла - распакованный *.lvz и, собственно, *.img-архив. В *.img де-факто хранятся wrld-ы без заголовков, при этом главная особенность *.lvz состоит в том, что этот файл не только сам является wrld-ом, но и содержит заголовки к wrld-ам из *.img. Смещаемся в распакованном *.lvz на оффсет 0x24 и читаем следующие четыре байта. Полученное значение - указатель на таблицу заголовков к wrld-ам. Сама таблица - длинный-длинный список. Каждый заголовок занимает 32 байта, т.е. восемь полей по четыре байта. Третье поле - оффсет wrld-а от начала *.img, пятое поле - оффсет внутренней таблицы параметров wrld-а (о ней чуть позже, она пригодится при работе с содержимым непосредственно), седьмое поле - размер wrld-а. Остальные поля нам не нужны. Далее можно поступить разными способами - либо составить в программе таблицу всех параметров wrld-ов, либо извлечь их "в открытом виде", разрезав *.img по тем параметрам и совместив все полученные фрагменты с соответствующими заголовками (т.е. добавив те самые 32 байта). Так, если ситуация ясна, то можно приступать к wrld непосредственно, если нет, то лучше спросить что не понятно.

[XEPOMAHT007]

В программу добавил чтение радар-прикреплённых WRLD и безрадарных WRLD, назначение которых буду проверять. С помощью радаров, как вы поняли, можно узнать, где примерно на игровой карте используются модели и текстуры из того или иного WRLD (что сильно облегчает поиск нужного ресурса при конвертировании строесов на ПК).



Так же для LVZ глобальный заголовок (единый для всех ресурсов LCS/VCS/Manhunt2) разобран на 100%, заголовок мастера WRLD разобран на 50% (на изменение остальных данных игра никак не реагирует, возможно это просто мусор). Атомик моделей WRLD мне разобрать пока не удаётся - там всё довольно туманно закодировано, намного сложнее, чем в атомике MDL.

[solom]

Ну возможно ниже эти ворды хранят в себе мелкие модели для карты, я так думаю..

[XEPOMAHT007]

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

[SILENT_Pavel]

Наглядный пример работы мипов, для начинающих.

Прикрепленные изображения

• 

[XEPOMAHT007]

Заменил id материала в одной модельке





Если id выставить больше общего количества материалов, произойдёт вылет.

Неизвестная цифра перед id портит материал:

Сообщение отредактировал XEPOMAHT007: 26 February 2012 - 15:27

[SILENT_Pavel]

XEPOMAHT007
Интересно, а таким образом можно ускорить процесс снежного мода к примеру, внедрив всего десяток снежных текстур и раскидав их id по всем дорожным полотнам?

[XEPOMAHT007]

Можно, только это гемморой, т.к. замучаешься с поиском моделей (а они если знаешь повторяются в img в среднем по 18 раз).

[solom]

А как активировать Debug меню?

[XEPOMAHT007]

А как активировать Debug меню?

Хексом. Почти так же как для GTA3 (SB ни там ни там их не открывает).



И для Вайса тож опткодов дебаггера в базе нету.



Поковырялся немного в месте, где лежат хеши имён, соответственно, если составить таблицу имён (в гта4 умные разработчики оставили её на растерзание моддеров, а в лсс и всс рокстар леедз показала кукиш), то можно хотя б просто заменять некоторые объекты (все хэши моделей, как известно, лежат в огромной тпаблице в GTAGAME).

Сообщение отредактировал XEPOMAHT007: 30 April 2012 - 13:07