Wing Commander IV: Цена свободы

Процесс перевода игры "Wing Commander IV: Цена свободы"- в разгаре. Желающие опробовать то, что получилось, могут добраться сразу до описания перевода и ссылок на его скачивание, щёлкнув по этой ссылке.

Желающим посоучаствовать в переводе - рекомендую: полезные для переводчика ссылки - словари, книги, статьи и прочие материалы. Пополнение копилки приветствуется!

См. также:
Самая свежая тестовая сборка и инструкции по её установке
Бета-тестеры, wэлкам!
31 дек 2016

Upd 1:
В связи с участившимися постами здесь "чисто для поржать" - вынужден объясниться.
6 янв 2014

Upd 2:
Приглашаю желающих поучаствовать в переводе. Отозвавшиеся будут увековечены в финальных титрах. (Никаких более материальных благ, к сожалению, обещать не могу. )
27 мая 2014

Upd 3:
Наконец удалось пробить барьер несовместимости моего перевода с версией игры от GOG!!! Желающим опробовать - wэлкам!
2 окт 2014

 

Слегка переделал большой шрифт, теперь вроде получше:

Плохо без кернинга, но чем богаты. :-

 

Уже нашёл причину. Всё куда хуже: функция xtre_decompress_2() дрищет даже не в стек, а в регистры. Поэтому под debug'ом всё работает, а release врубает регистровую оптимизацию переменных и туши свет. :-(
Выкрутился вот так: слепил свою функцию

Код:

void uncomp2( uint8_t *data, uint8_t *uncomp, int len ) {
	__asm {
		mov eax, 0
		mov ebx, 0
		mov ecx, 0
		mov edx, 0
		mov esi, 0
		mov edi, 0
	}
	xtre_decompress_2( data, uncomp, len, uncomp + len + TEMP_BUF );
}

Чищу регистры, компилятор это просекает и push-pop'ает те из них, которые для него представляют ценность.

---------- Сообщение добавлено в 15:15 ---------- Предыдущее сообщение размещено в 14:31 ----------

Прорабатываю очередную шизовую идею (не моя - где-то на днях подцепил): id'ом IFF'а в .tre-файле с т.з. .exe'шника является даже не смещение его описателя в заголовке 1-го уровня (что, кстати, блестяще подтвердилось!), а CRC-32 в том же описателе. Есть косвенное подтверждение: в language.tre нашёл несколько абсолютно одинаковых IFF'ов с разными CRC-32.
Если идея подтвердится экспериментом - это позволит пересобирать несколько .tre-файлов в один с целью экономии объёма, притом куда более существенной, чем сжатие (пример - файлы special*.tre повторяются на больше чем половину).

 

Рыжий Тигра, ну и в итоге-то - ты инициализируешь переменные. =)

 

Рыжий Тигра, щас дам тебе другую идею - покошернее. Вырежи нафиг код стандарного обращения к этим tre и замени его на обращение к zip. А потому засунь все туда. Ничуть не сложнее.

А что касается куска кода, то в объектниках где то по адресу 1F0 сидит команда leave...

 

Сделай лучше ты, будет быстрее - я не настолько силён во взломе форточных приложений.

Пробовал это сделать в перехватчике. Упирается в чтение IFF'ов не сначала и маленькими порциями (не больше 16 кил).

Не уловил: а что это даёт?

 

Слепил .tre-паковалку. Первый блин комом: игра болезненно реагирует на сдвиги/перетасовки записей заголовка 1-го уровня, вываливается и просить вставить правильный диск. Похоже, идентификатором IFF'а служит таки смещение в заголовке, а не CRC. Копаю дальше... :-

 

А если родные tre разобрать\собрать - работают?

 

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

 

Рыжий Тигра, может где то в экзешнике есть таблица с явным указанием на смещения в файле ?

 

Рыжий Тигра, так если я правильно помню, проблема в перепаковке файла была в вычислении новой контрольной суммы фраз.
Как ты решил эту проблему?

 

Х его З. М.б. и не в проге, а в другом .tre-файле, я не знаю как исследовать. Могу снять лог доступа к файлам, но не думаю, что это что-то даст.

Железно нет. Механизм подмены шрифтов и текстов, который я использую, изменяет данные, но никаким фигом не затрагивает заголовки первого уровня, а с ним всё работает. А стоит чуть попередвигать записи в hdr1, даже не меняя содержимого IFF'ов, - и привет. :-(
Это раз. А два - поле crc32 это вовсе не CRC: в language.tre есть с полдесятка абсолютно идентичных IFF'ов с разными значениями hdr1->crc32.

 

Ура! Свершилось. Блин второй, съедобный. Дарю обчеству, см. вложение.
Тут обе проги - trextra и tremake; как и в прошлый раз, вместе с исходниками.
trextra разбирает исходный .tre-файл (в командной строке) на IFF'ы в свежесозданный каталог с таким же именем и попутно рожает в том же каталоге файл files.bbs с инфой, нужной для обратной сборки (каждая строка - имя IFF-файла, имя исходного .tre-файла, порядковый номер в выводе (с учётом пустых записей в hdr1), CRC-32 из hdr1, смещение hdr1, смещение hdr3, смещение данных, если есть - имя из hdr2); более полная инфа выводится ещё и на стандартный вывод, рекомендую перехватывать в файл - на что-ньдь да пригодится.
tremake принимает в качестве аргумента командной строки имя каталога с результатами разделки .tre-файла, читает files.bbs, открывает последовательно перечисленные в нём IFF-файлы и складирует в область данных создаваемого .tre-файла, попутно заполняя заголовки. При работе не выводит ничего, кроме сообщений об ошибках (можно, конечно, сделать её более "болтливой", но зачем?). Файлы укладываются в порядке их следования в files.bbs; имя .tre-файла, порядковый номер записи и смещения hdr3 и данных игнорируются. Для получения .tre-файла максимально подобного исходному весьма рекомендую сначала пересортировать files.bbs по возрастанию смещения данных.
Всё! Пробуйте, тестируйте, отлаживайте.

PS. В исходники я не включил zlib 1.2.8, ибо здоровенный как сарай. Кто хочет перекомпилить по-своему - можно всегда взять с сайта разработчика.

 

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

 

Выложил разобранный на IFF'ы language.tre и готовые на данный момент субтитры.

(тонко намекает) Или! Берись потихоньку. Все инструменты, сделанные для разделки WC4, опен-сорсные и после чуточной доработки годятся для WC3; главная проблема - как впилить в него вызов своей функции.
Для начала бери уже выдранные тексты субтитров и переговоров и готовь подстрочник. Дальше будет видно.

 

Нуждаюсь в помощи!
Есть маленькая, но дурацкая сверхзадачка. Имеется:

• здоровенный как сарай (десятки мегабайт) файл, из которого программа читает небольшими кусочками (не больше 16 кил за раз) весьма хаотическим образом;
• большущий (сотни позиций) список замен - троек "смещение-длина-строка": строками надо при чтении подменять соответствующие участки файла.

Как удобнее реализовать? Перебором (по каждому запросу на чтение пробегаться по всему списку замен в надежде, что какая-ньдь подойдёт) не комильфо; битовую карту хранить негде. Нюхом чую, что стандартная программистская задача, но не встречал.
Какие будут идеи?

 

Рыжий Тигра, хеш-таблица?

 

Рыжий Тигра, ну на самом деле можно вообще без сравнений обойтись. Просто каждому случайному смещению (адресу) в первом файле будет однозначно соответствовать адрес во втором файле, который будет содержать смещение данных в файле со строками. Таким образом считывание нужной строки происходит фактически сразу и без поиска. Из минусов: второй (индексный файл) будет иметь такой же размер, как и первый с данными игры. Зато быстро.

Шучу. Количество позиций считывания конечно и однозначно, поэтому путём нехитрой математики можно уменьшить размер файла.

 

В общем случае - не годится: чтение может начаться и раньше позиции замены, и позже (т.е. посреди заменяемого блока).

Увы, паре адрес-длина. :-( Летмишоую:

Код:

-------------------ЖЖЖЖЖ--------------------
1)   ++++++++++++
2)           ++++++ЖЖЖ
3)              +++ЖЖЖЖЖ+++++++
4)                  ЖЖЖЖ+++++++++++++

А как? Хотя размер не так сильно бомбит, как время. :-( Могу выделить сотню-другую кил, я не настолько жадный.

 

Т.е. из произвольной пары смещение-длина получить список троек сегент-смещения-длина, где сегмент показывает, из какого блока - основного или замен - берется фрагмент?
Обычное сортирующее дерево.

 

Рыжий Тигра, gudleifr всё ещё проще, учитывая, что мы заранее знаем какие адреса в файле читаются:

1. Файл данных игры, допустим читается из позиции 80000h и 512 байт.
2. Ок. Перехватили, считали чего было надо в буфер.
3. Теперь берём этот же адрес 80000, лезем по нему в наш файл с таблицей указателей и читаем фактический адрес, где лежит длина, адрес подмены в буфере и сама строка, на которые всё будет заменено из другого файла или из хвоста этого же.
4. Производим подмену в буфере, закрываем файлы и отдаём управление назад.

Для сжатия используем тот факт, что указатель в файле имеет размер 4 байта. Поэтому смотрим на разницы между ближайшими считанными адресами из файла игры и мастачим некую формулу пересчёта этого безобразия, что бы на шаге 3 преобразовывать первоначальное смещение по ней до уровня указателя в компактной таблице в начале файла.