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

[listener]

Посмотрел я на это поле. Да, действительно - здоровенная сложная структура. Предположительно - prerendered раскладка объектов по странице. Для отображения это было некритично, а для конвертации придется разбирать. Там не просто коллекция, а коллекция связных списков.

[listener]

Все. Похоже, что вся структура разобрана. (осталось десятка два неназванных полей в HtmlRenderState и CHtmlTableElementNode, но для них известны типы, так что преобразованию это не помешает). CHtmlDocument::_f20 - это stylesheet. .bt выложу, как только приведу в порядок.

[BOPOH]

Здравствуйте! Начну с того, что выражу вам огромный респект за проделанную работу и за то, что вообще взялись за этот проект! Я бы и сам помогал бы, если бы разбирался в программировании, но я могу, лишь переводить, поэтому, чем и смог бы помочь, так это переводом игровых ресурсов\диалогов, после вашего замечательного порта на PC. Ещё раз огромное спасибо и чтобы вы не теряли интерес к своей работе.

[Dageron]

Если я не ошибаюсь, это вы планировали сделать видеопрохождение с русским переводом? (видел раздачу на torrents.ru) Хорошая идея, только вот желающих не особо много записать геймплей.

[Deep]

Зато есть много людей которые просто кидают записи на ютуб , и присоединяюсь к ВОРОНу, благодарю за энтузиазм и желаю успехов вашем деле!!!!

Сообщение отредактировал Deep: 11 September 2009 - 16:00

[BOPOH]

Если я не ошибаюсь, это вы планировали сделать видеопрохождение с русским переводом? (видел раздачу на torrents.ru)
Хорошая идея, только вот желающих не особо много записать геймплей.

Да, это я, кстати таки ещё 3-4 миссии достал, скоро продолжу перевод. Покамисть Rockstar перстали закрывать видео с прохождением, может быть и будет полное)

[Dageron]

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

[listener]

Как то все вялотекуще. До выхода ep2 остался месяц (760 часов), а мы все с первым разобраться не можем. Большинство ресурсов разобрано до уровня полей. Где конверторы? (или все собираются ждать милостей от R* ? ) что касается меня - я сейчас занимаюсь допиливанием недостающих вещей в поддержке DLC. ночью сделал config reader с поддержкой произвольного числа тэгов. Дальше буду допиливать CEpisodes (в PC-шной версии от него присутствует несколько ошметков, так что ожидается, что это будет просто). В процессе, будет восстановлено чтение update.img (в fiDevice::getDevice, там просто вырезана строка с обработкой путей вида update:/), так что моды можно будет подключать, не трогая игровые архивы. У кого еще есть какие планы?

[Chipsman]

ну у меня планы более какбы общие можно сказать.. лично я очень ждал (и жду дальше) обещанных нам тобой примеров на си++ по работе с ресурсами (чтение/запись и т.п.), ибо с си++ лично я не особо "на ты", и чтобы мне все полностью разобрать, как это все правильно делается, нужно много времени (+ особо много свободного времени даже нету (5й курс, + работа, + магистерскую делать, + я еще и ленивый очень)). Лично я хотел бы попробовать написать плагин для 3ds max'а, уже установил сдк, поверхностно посмотрел немного примеров, и если более глубоко разобраться, то думаю можно попробовать... + еще мысли вслух: так же я еще давно начинал делать редактор карт вроде того что для са был (Good возлагал на нас с Dageron'oм большие надежды.. ), ну и теперь думал продолжать разработку, но теперь когда появилась информация про коллизию моделей, и выяснилось что система тут уже не такая как раньше, то есть коллизия расставляется по координатам отдельно от моделей, то сама идея такого редактора отпадает (просто не вижу смысла передвигать модели а коллизия будет оставаться на месте, и даже можно сделать редактирование координат и того и того, но теперь не обязательно, что их размеры и расположение одинаковы и мне тяжело представить в голове процесс "угадывания" координат, чтобы все потом совпадало) а идею плагинов к максу, если все получится, можно разширять, вплоть до того чтобы прямо с макса оно само запаковывало все в архив, делало иде и впл кароче вот такие у меня мысли..)

[Dageron]

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

Есть pgBase с загрузкой *.wrd, но этого недостаточно чтобы понять как сделать то же самое, скажем, для моделей.

Большинство ресурсов разобрано до уровня полей. Где конверторы? (или все собираются ждать милостей от R* ? )

Последним чем я занимался был WTD Builder, могу его выложить. Структура ресурса строится нормально, но вот флаги - столь старая и трудоемкая задача. Корректно их рассчитать можно только на С++, но можно взять и другой вариант рассчета с более большим расходом памяти (но отображением хоть нормальным). Для чтения моделей (именно не геометрии, а самой структуры CPU) все равно придется использовать C++.

Good возлагал на нас с Dageron'oм большие надежды..

Фуф, вот это конечно получилось не хорошо. Все бы ладно, но я так и не смог нормально скомпилировать его Delphi-классы в совокупности с просмотрщиком карт (все апдейты ключевых юнитов стоят). В любом случае если надумаешь продолжать что-либо делать в этом направлении то я стану тоже.

[Seemann]

У меня тоже много планов, но они как бе совсем с GTA не связаны)

[listener]

Есть pgBase с загрузкой *.wrd, но этого недостаточно чтобы понять как сделать то же самое, скажем, для моделей.

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

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

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

Последним чем я занимался был WTD Builder, могу его выложить. Структура ресурса строится нормально, но вот флаги - столь старая и трудоемкая задача. Корректно их рассчитать можно только на С++, но можно взять и другой вариант рассчета с более большим расходом памяти (но отображением хоть нормальным). Для чтения моделей (именно не геометрии, а самой структуры CPU) все равно придется использовать C++.

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

Т.е., из этого следует, что ресурсная библиотека должна не только заниматься чтением/записью ресурса, но и менеджментом его внутренней структуры. В простейшем варианте: вызвали функцию чтения ресурса - получили объект (всю структуру) и дальше работаем с ним как с read-only (иначе начнутся проблемы с памятью). В функцию записи скармливается собранная полная структура, а дальше она копируется и в ней делаются необходимые перестановки. Минус варианта - в коде, работающем с такой библиотекой придется учитывать все структуры (типы полей, выравнивания и т.д.)

В более сложном варианте, должен быть API для работы не только с ресурсом в целом, но и с отдельными его компонентами. Здесь нужно подумать, как это все уложить на набор вызовов, которые можно использовать из любого языка (не закладываясь на объекты, шаблоны и прочий syntax sugar). Завтра выложу свежую баз - в ней я пометил еще несколько десятков автоматически сгенерированных функций - можно посмотреть и ужаснуться тому, сколько всего делает компилятор по своей инициативе.

Что касается коллизий и объектов - все просто: никто не мешает хранить отдельно коллизии на объекты и собирать их в общий wbn при сборке карты. В большинстве случаев, кол объекта можно тупо добавить в общий композит, не трогая внутренней структуры (при необходимости, пересчитывая AABB композита).

Ладно, это была лирика. А теперь несколько советов по общему подходу к делу.
Задач, на текущий момент много и даже слишком много. Если не получается одна - можно взяться за следующую. С одной стороны, не получается сидеть без дела, с другой стороны - рано или поздно, что-то получится. А дальше, на ощущении победы можно браться за следующую.
На эту тему, была хорошая статья у Джоэла Спольски: http://russian.joelo...eAndMotion.html

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

[listener]

Закат солнца автоматически (новая версия rsc_io, загрузка ресурсов 360-ки):

[MEM] memory manager initalized
FILE: 'C:/Users/.../Documents/Visual Studio 2008/Projects/openLibertyCity/Debug/loadingscreens.xtd' => dwMagick = 0x52534305, dwVersion = 7, dwFlags = 0xe04c0010
TRACE: [BlockMap::allocate] virtSize = 0x1000, physSize = 0x980000
TRACE: Processing Xenon resource ...
TRACE: [pgStreamable::pgStreamable] (Xenon) in = 1746231, out = 9965568, status = 0
TRACE: 000: hash = 0x416b2526 (1024 x 1024) 'pack:/5_1.dds'
TRACE: 001: hash = 0xd40f6f38 (1024 x 1024) 'pack:/5_2.dds'
TRACE: 002: hash = 0xcf79f540 (1024 x 1024) 'pack:/7_2.dds'
TRACE: 003: hash = 0x5b8aba5d (1024 x 1024) 'pack:/2_1.dds'
TRACE: 004: hash = 0xe42eff6f (1024 x 1024) 'pack:/2_2.dds'
TRACE: 005: hash = 0x4a69577a (1024 x 1024) 'pack:/3_1.dds'
TRACE: 006: hash = 0x6eaa4599 (1024 x 1024) 'pack:/7_1.dds'
TRACE: 007: hash = 0x10afbc9a (1024 x 1024) 'pack:/4_2.dds'
TRACE: 008: hash = 0xb6c28fa4 (1024 x 1024) 'pack:/4_1.dds'
TRACE: 009: hash = 0x9130f5c8 (1024 x 1024) 'pack:/8_1.dds'
TRACE: 010: hash = 0x155d37df (1024 x 1024) 'pack:/8_2.dds'
TRACE: 011: hash = 0x21cdc4ef (1024 x 1024) 'pack:/1_1.dds'
TRACE: 012: hash = 0x4456d3f0 (1024 x 1024) 'pack:/3_2.dds'
[MEM] memory manager terminated

Код который это выводит (загрузка xtd и вывод параметров текстур):

pgStreamable ps (pszFilename);
	g_pStreamedResource = &ps;
	x_pgDictionary<x_grcTexture> * xtd = new (ps.getData()) x_pgDictionary<x_grcTexture> (&ps);
	DWORD dwTextureCount = xtd->m_data.m_wCount;
	g_pStreamedResource = NULL;

	for (DWORD i = 0; i < dwTextureCount; i++) {
		DWORD h = *xtd->m_hashes.getElement(i);
		printf ("TRACE: %03d: hash = 0x%08x (%04d x %04d) '%s'\n", i, h, xtd->m_data[i]->m_wWidth, xtd->m_data[i]->m_wHeight, xtd->m_data[i]->m_pszName);
	}

Как уже говорилось, все обрабатывается автоматически, нужно только описывать структуры.
Для примера, grcTextureXenon (это весь код объекта, в нем отсутствует только swizzling (впрочем, он все равно будет в D3DTextureBase):

struct x_grcTexture : public x_pgBase {
	x_grcTexture () {} 
	x_grcTexture (pgStreamable * pStreamable) : x_pgBase (pStreamable), m_pszName (pStreamable), m_d3dResource (pStreamable) {}

	BYTE						_f8;
	BYTE						_f9;
	x_WORD					  _fA;  
	x_DWORD					 _fC;
	x_DWORD					 _f10;
	// >> grcTextureXenonProxy ends here
	x_pgPtr<char>   m_pszName;
	x_pgPtr<x_D3DTextureBase>   m_d3dResource;
	x_WORD					  m_wWidth;
	x_WORD					  m_wHeight;
	x_DWORD					 _f20;
	x_float					 _f24[6];
};

Все действительно страшные вещи находятся в pgPtr/pgObjectPtr/pgArray/pgObjectArray (вместе с pgStreamable - порядка 600 строк на обе платформы). Впрочем, реальная развлекуха начнется не на чтении, а на записи ресурса - я этот код еще не переносил в новую версию. К счастью, там тоже все будет в pgStreamable; в самих объектах будет по одной строке на каждый внутренний объект.

Собственно, к чему я так многословен: у кого-нибудь будут какие-нибудь мысли на предмет внешнего API к этому делу?
В каком виде это все отдавать во внешние программы и, что более важно, в каком виде принимать обратно.

PS. Порадовало, что код генерится в точности такой, как в игре. Это значит, что соответствующие классы воссозданы 1-в-1.
В связи с этим, есть идея-подозрение, что в R* вообще не заморачивались с бинарными форматами, а импортировали все из текста (как это выглядело в общем виде - можно посмотреть любой файл .tune). Возможно, что это будет оптимальный вариант?

Сообщение отредактировал listener: 02 October 2009 - 02:25

[Dageron]

Радует начало С++ описаний. Даже смотря на приведенный пример уже многое становится понятно (к примеру, как преобразовывать 010 шаблоны в классы). Если говорить о конечной разработке то лучше все это сделать все в виде *.dll (только с обязательным описанием функций), удобно тем что можно вызвать из-под любого языка. Сейчас же можно вообще обойтись просто исходниками с классами или же примерами классов (чтобы можно было расширять в соответствии с добавлением форматов) - по типу pgBase, но только обязательно откомментированными. Самому мне хочется во всем этом разобраться, чтобы не сидеть без дела.

[Chipsman]

поддерживаю выше сказанное p.s. на счет статьи.. то у меня почему-то все зацикливается на пунктах 7-8 с рандомными вставками пунктов 2-6, и очень изредка прорывает на пункт 9-10

[xerius]

Здравствуйте. Прочитал эту тему от корки до корки. Оч. интересно! Давно хотел покопаться в ресурсах х360 игр. Может ктонить поделиться xcomress32.dll? Многие х360 игры пакуют LZX, а без этой библиотеки никуда. У меня есть сдк х360, но откомпилировать xcompress.lib и xcompress.h в .dll знаний не хватает. Кому не трудно в личку, плиз. Извиняюсь, что немного не по теме.

[xerius]

Мда... Мертвые с косами и тишина... Чтож. Придется идти с протянутой рукой к иностранцам. От соотечественников помощи ждать увы не приходится. Всех благ.

[listener]

xerius
Ну, на буржуев в этом плане я бы надеяться не стал.
Здесь же - в данном конкретном вопросе тубе могут помочь три человека. Как минимум два из них - заняты. А характер вопроса такой, что ответить на него - создать повод для следующих вопросов.

OpenIV и SparkIV были написаны практически без использования XDK. По крайней мере, упаковка и распаковка ресурсов была сделана самостоятельно, без использования xcompress32. Я например, для распаковки используюю libmspack.
Не для того, чтобы обидеть, а для константации факта - отвечать человеку, который признается что не смог понять документацию на компилятор - это взвалить на себя дополнительный геморрой (чего совершенно не хочется делать).

Задача-то предельно проста: есть библиотека (с документацией на нее). Из нее нужно сделать dll. Все, что нужно сделать - это написать однострочные обертки к нужным функциям и объявить их экспортируемыми. В хелпах по MSVC это подробно описано (искать по слову dllexport). В хелпах по Delphi - тоже должно быть. (Если быть совсем честным, я не чувствую себя сейчас в адекватном настроянии для того, чтобы объяснять, как правильно читать хелпы).

------
Что касается текущего статуса, дела обстоят так.
Прошлую неделю, у меня был еще один небольшой проект, так что докода я практически не добирался. В выходные нормально отладил раскладку блоков. Убил сутки на то, чтобы разобраться с ошибкой раскладки, пока не выяснил, что в раскладке ошибок нет, а просто не получится на лету конвертировать структуры, если размер изменяется большую сторону. Это чуточку усложнит конвертер, но не сильно.

С записью ресурсов получается чуть больше возни, чем с чтением, но также достаточно красиво (5-6 строк на структуру + две-три строки на каждый указатель). Рабочая версия будет выложена, как только будет отлажена.

У кого-нибудь есть еще какие успехи?

Сообщение отредактировал listener: 12 October 2009 - 08:54

[Dageron]

Не знаю, отношусь ли я к этим троим, но одно могу сказать точно - xcompress32 очень глючная вещь. Разумеется, распаковку конкретную она дает, но в процессе появляются недочеты, связанные с размером распакованного файла (можно распаковать только лишь часть блока данных). Лучше действительно воспользоваться либо документацией по ссылке listener-а, либо набрать любом в поисковике "LZX compression" (найти можно много чего интересного, и довольно быстро). Кстати, что касается запада, насколько мне известно наш форум и эту тему особенно очень даже читают некоторые через переводчик (особенно с нынешнего modmygta.com).

[listener]

Относишься-относишься. Ты хотя бы с xcompress32 работал. Материалы есть. База есть. Даже XDK утек. Пока я навожу финальные штрихи на библиотеку, можно было бы сделать шаблоны для xenon-ресурсов (перетащить из d3d9.h/d3d9gpu.h определения индекного и вертексного буферов в 010 и попробовать собрать шаблоны для xdr и xft "по аналогии"). Теоретически, там должна быть такая же ситуация, как и с текстурами: вместо указателя на данные D3D - стандартный ресурсный объект.