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

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

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

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

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

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

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

 

Ура! Я таки доделал dwrap-подобный вывод картинки на широкоформатные дисплеи чистым 16-битным directdraw'ом, вылизал всё, передизайнировал под это дело dxmci'йный конфигуратор и уже сегодня хотел выкладывать очередную бету. Но напоследок окинул глазом табличку-дразнилку, которая выскакивает после некролога, и - "ой мамочки! а шрифт-то не кернёный!" (L) :-( Пришлось всё бросить и опять заняться кернингом. Тут ещё на пару дней работы, но кое-что могу показать - самые простые случаи, конечно: те, что слепились навскидку.

Картинки под катом

Кернёные места подчёркнуты тоненькими красненькими линиями - не стал как обычно делаю обводить рамочками, чтобы нагляднее.

PS. Самый тяжёлый случай обещает быть с Дином Макколом по прозвищу "Громила": с одной стороны, позывной сам просится чтобы его откернили, с другой стороны - кернить придётся в нескольких шрифтах (список лётного состава, меню коммуникатора, радиосубтитры...) одними и теми же кодами, с третьей - придётся придумывать извращённый алгоритм проверки чтобы кто-ньдь ненароком не зарегился Громилой в обоих вариантах - с кернингом и без... :-

 

Засада! :-( Свободных клеток в WC'шной кодовой таблице не хватает на все "плакатные" потребности, придётся использовать коды занятые еврозябрами. :-(
Переделываю декомпилятор IFF'ов под сбор статистики использования символов.

Upd 19/12: Статистику собрал. Ура, английские тексты в игре никакую евромаймуницу не используют - можно смело занимать все её позиции, "английский перевод" будет работать.

 

(мрачно пялится на стремительно разрастающийся бардак массив пар символов для кернинга) Не, нуеговболото:



Так дальше не пойдёт! (яростно умывает лапы) Надо как-то иначе. Нужен всего-то список пар символов, для которых надо корректировать расстояние между ними, а не сами эти символы.

2 All: Приглашается опытный хакер-взломщик-дизассемблщик на замещение вакантной должности хакера-аналитика. Задача: в коде wc4dvd.exe (есть также результат PE explorer'ного дизассембла) найти функцию, которая получает на входе картинку, координаты в ней, массив шрифта и текстовую строку и рисует по этой картинке эту строку этим шрифтом. В штатном расписании проекта финальных титрах на это дело отводится отдельная строка "Хакер-аналитик". Я сам эту задачку не потяну - улёжчивости не хватает. :-(
А дальше просто: нужно доработать эту функцию - добавить в неё ещё один параметр, таблицу коррекции межбуквенных расстояний, чтобы при прорисовке текста учитывала эти поправки. Ну, или написать свою функцию с нуля, имея найденную за образец. Это я уже сам.
Претенденты на вакансию, wэлкам! Честно - очень нужна помощь!

 

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

 

Типа "ладно, проехали"? Сенькс, тоже покатаю на языке.

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

Насчёт поиска функции вывода строк с кернингом - детализирую задачку.
Собственно, нужно найти точку входа в функцию, которая прорисовывает букву, разобраться в ней ("декомпилировать" из ассемблера в си-образный псевдокод, м.б. даже в C++-образный) и добавить функциональности. Разобраться и доработать - это я хорошо умею, а вот искать маленький неизвестно как выглядящий кусочек кода в большущем стогу дизассемблерного вывода (или непосредственно в машкоде) - увы, не знаю как. Никогда не приходилось.
Впрочем, насчёт как найти искомый кусочек - есть пара соображений.
Первое. Структуры шрифта и буквы в нём я давно уже вскрыл, и функция вывода буквы может быть примерно такой:

Код:

void draw_letter( // нарисовать букву
    wc4_font_t *font, uint8_t letter, // шрифт и буква
    uint8_t out_color, // цвет, которым рисовать букву
    uint8_t *picture, // массив 8-битных пикселов картинки
    int pitch, // расстояние в байтах между началами строк
    int x, int y // координаты левого верхнего угла буквы (y растёт вниз)
    ) {
    wc4_glyph_c *glyph = (wc4_glyph_c *) &( ( (uint8_t *) font )
      [ font->offsets[ letter ] );
  uint8_t *in_pixel = glyph->pixels; // [COLOR="Red"][B]*[/B][/COLOR]
  int jy = 0; do {
    uint8_t *out_pixel = &picture[ x + y * pitch ];
    int jx = 0; do {
      if ( *( in_pixel++ ) != font->bg_color ) // [COLOR="Red"][B]**[/B][/COLOR]
        *out_pixel = glyph_color;
      out_pixel++;
    } while ( ++jx < glyph->width );
  } while ( ++jy < font->height );}

Конечно, не факт что Origin'ские программисты будут писать настолько "в лоб", - скорее всего здесь должны быть ещё какие-то оптимизации.
Второе соображение - по методике поиска. Насколько я разбираюсь в механизме чтения данных игрой из .tre-файлов, прочитанное перед использованием "по делу" неоднократно копируется из буфера в буфер, сканируется на наличие каких-то сигнатур и т.д., так что сравнительно простой метод установки breakpoint'ов по чтению, увы, не годится из-за обилия ложных срабатываний и размножения прочитанного куска во временные буферы сканеров.
А вот что может помочь в нашем случае - это заранее изгадить значения в wc4_font_t:ffsets[] и/или wc4_glyph_t::width так, чтобы результирующие указатели не резолвились, - например, попадание в область выше двух гигабайт очень даже годится. Дальше запускаем всё это под отладчиком, игра при попытке выбрать букву* или поковыряться в ней** падает и вуаля - сразу видно кусок кода, который эту букву обрабатывает.
Как общество считает - годится техника? Я сам пока не проверял, только что навскидку придумал. Прошу кидаться тапками. И идеями, ясен перец, тоже.

 

Применил трюк номер * к ровно одной букве ровно одного шрифта - и игра упала как раз перед выводом ровно этой буквы. Это хорошо. Упала по адресу 00491365 по листингу. Ищу дальше. И заодно думаю - а как проверить, может, таких мест не одно? :-/

 

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

 

nop, wэлкам! :-)

Не все отладчики одинаково удобны. :-( Например, последних два месяца, как начал ломать directdraw, я не вылезаю из двухмашинной отладки, а она проста и удобна только под штатным отладчиком MSVC6. :-(
Да и хардверных брейков всего три штуки аж, а WC4'шная обработка прочитанных данных в первые же миллисекунды после чтения успевает наплодить с десяток копий прочитанного. А ещё один трюк из ollydbg - останов через доступ к странице - у меня почему-то постоянно рожает ложные срабатывания. :-(

Не понял вопроса. Во-первых, отдельного "файла шрифтов" у WC4 нет - шрифты вкраплены в файлы globals.iff, install.tre и missions.tre. А во-вторых, иллюзия "регулярных смещений" - естественное следствие того, что первые 0x20 знакомест каждого шрифта имеют одинаковую ширину в байтах (0 столбцов глифа плюс перед ними 4-байтное целое с количеством столбцов).
Присмотрись внимательно к файлу globals.iff - первый шрифт в нём начинается со смещения 0x694, а уже с 0x72С видно, что размеры знакомест таки прыгают.
А почему все поля в заголовках шрифтов 32-битные, даже те которым по самые уши хватило бы 8 бит, - тут ХЗ, может чтобы быстрее доступаться? :-/

Использую аналогичную фишку: весь перевод (патченые шрифты, тексты на подмену и т.д.) zlib'ом ужимается грубо вшестеро и разворачивается уже при чтении в момент запуска игры.

P.S. Oфтоп, но существенно.

Э... давай меня "на ты", пожалуйста. Видишь ли, Тигры - народ пугливый и каждый раз, когда им "выкают", думают что попали "на ковёр" к Очень Злому Начальству. :-(((

 

Гы, с прототипом букворисовательной функции я почти угадал:

Код:

int SUB_L004912A6( uint8_t ***picture, int x, int y, wc4_font_c *font, uint8_t letter, ... );

- в picture не совсем уверен, с цветом и pitch'ом неясно, но в целом где-то так. Возвращает, натурально, ширину свежевыведенной буквы.
Ага, совсем забыл: есть ещё запрос ширины буквы, его тоже надо подхимичивать. Вот он:

Код:

int SUB_L00491283( wc4_font_c *font, uint8_t letter );

 

Припоминаю, если убрать флажок эксклюзивного режима, (и сидеть на старом 9x виндовсе) не будет зависаний дебагера, пока приложение находится в Lock()

Сейчас реверсю цикл блита. Там есть два варианта внутреннего цикла, с прозрачностью и без (просто вывод прямоугольника). Причем вариант с прозрачностью не просто выводит байтик а делает так:

Код:

function (.. , BYTE table[256])

..
for(i=0;i<width;++i) {
  BYTE x = table[*src];
  if(x != 0xFF)
     *dest = x;
  ++src;
  ++dest;
}
src += src_pitch;
dest += dest_pitch;
...

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

Фишка была в том, чтобы разжимать RLE непосредственно в цикле рисования

 

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

В смысле - IDirectDrawSurface::Blt()? Зачем??? Он в WC4 нужен для строго одной цели - очистки экрана, "больше, кажется, ни на что не годен" (L).

Хм. Однобитная прозрачность. Не люблю.
Кстати, в первом WC была забавная фишка - шесть (!) кодов прозрачности: фонарь плюс передний сектор радара, задний сектор, боковые и верхний-нижний. При попадании вспыхвал малиновым тот сектор, в который попали. :-)

Ага-аа! Остроумно. "На что только русские не пойдут, чтобы денег не платить!" (L) похабный анекдот :-)

 

Неа, блит обозначает циклическое копирование пикселей. то, что я там написал. http://en.wikipedia.org/wiki/Bit_blit
Кстати не в курсе был, что та табличка именно для однобитной прозрачности. Для нее по идее такой подход не нужен. Сложно разве просто проверить бит в считанном байте?
Тут, я так понял, хитрость в том, что в зависимости от выбора таблички можно отдельные цвета в одной и той же картинке делать прозрачными, анимировать, перекрашивать..

Во-первых идея не моя, во-вторых - это даже быстрее. Выводя, скажем, окно из 20 прозрачных пикселей, не только не нужно их хранить в памяти, но и проверять каждый байт на прозрачность при рисовании.

 

Трудно сказать... Мне лично, например, PNG'шная идея отдельного альфа-канала в среднем симпатичнее, чем GIF'овая "прозрачного цвета", - можно менять контуры дырки не трогая картинку или, к примеру, делить картинку на передний-задний планы с целью воткнуть между ними средний (типа пейзаж с домиками или интерьер с мебелью, а между ними ходит персонаж).
Кстати, я обратил внимание - в wc4dvd.exe есть библиотеки, прилинкованные в статике (stdlib, к примеру); может, Bit_blt() тоже из какой-то либы и её проще найти в сырцах этой либы, чем париться с реверсированием?
Вообще, если в коде напарываешься на предположительно известную функцию из известной либы - записывай её (адрес точки входа, имя, прототип) в отдельный список и периодически скидывай его сюда. Здорово облегчает раскопки в коде.

---------- Сообщение добавлено в 01:53 ---------- Предыдущее сообщение размещено в 01:41 ----------

Upd. Ё-пс, вчитался в твой кусок кода. М-да, это я в штангу. :-( Не альфа-канал, а переменный (задаваемый табличкой) набор прозрачных цветов. Хотя, по идее, тоже можно использовать с толком - например, в кабине помигивать лампочками индикаторов или даже целыми надписями (как индикатор захвата ракетой или автопилота) - это проще и может быть быстрее, чем вклеивать маленькую картинку.
Я про вот эти: http://www.old-games.ru/forum/showthread.php?p=1062984#post1062984 - обведенные рамочками слова это точно не надписи шрифтом, это именно картинки.

 

Рыжий Тигра, Такое делают в 256-цветовых играх довольно часто, чтобы перекрашивать шрифты и, например, врагов в разные цвета. Ну и да, табличка задает также, какие именно цвета будут считаться прозрачными в этот раз. А если указатель на нее null, рисование идет простым копированием без прозрачности в другом цикле.
Если брать более жирную таблицу, то можно и прозрачность замутить почти настоящую, как в Starcraft, а не только 0/1:

Код:

for(i=0;i<width;++i) {
  *dest = table[*src][*dest];
  ++src;
  ++dest;
}

table предварительно рассчитываем по любой нравящейся нам формуле. Хотим - делаем суммирование/усреднение цветов, хотим - по формуле альфаблендинга, считая несколько битов исходной картинки за альфу итд.
Но табличка жирная получается, кэш крошит даже у новых процессоров, да и памяти жрет немало. Хотя, если точно знаем, что в спрайте только 16 цветов, она может быть [16][256] итд.

 

nop, сенькс, буду иметь в виду. Возможно, пригодится потом - в дальних планах у меня, как покончу с WC4, взяться за WC3, а у него есть режим с настоящей кабиной, а не только с НUD'ом на лобовом стекле. И лампочки там мигают по-настоящему.
(закопался обратно в отладчик, только кончик хвоста торчит наружу и иногда непроизвольно подёргивается)

 

Придумал "визуальный" интерфейс для кернения шрифта: вместо сочинения руками кучи пар букв с поправками растояния между ними "откусываю" от знакомест слева-справа кусочки - на картинке

Символы с зелёной закраской справа в диапазоне 0x9F..0xBF - это тоже кернинг, но по старинке, "плакатным" способом.

показаны серым:



А компилятор шрифта уже из них соберёт пары и подготовит их к скармливанию программе рисования текста. Собиралку, скармливалку и рисовалку я ещё не написал, но уже в основном придумал.
Фрагмент процесса сборки строки "в лоб" (без промежуточной генерации пар) и результаты:



Для наглядности картинка увеличена вдвое, а фоны соседних букв закрашены разными оттенками красного, чтобы не сливались и видно было где стыки.
Всё делалось в старом добром mspaint'е. Хотя, конечно, не помешал бы специализированный картиночный редактор с возможностью на лету пересчитывать табличку с глифами в шрифт и по нему тут же выводить несколько строк-образцов. А то шрифтов откернить надо кроме этого ещё 11 штук, а вручную всё ж геморройно.

 

Посмотрел еще тот код. Большинство строк там потрачено на clipping - обрезку выводимой области, если она выходит за пределы окна вывода. Есть подозрение, что на выходе функции в EAX возвращается смещение к следующему символу, но пока не факт. Код в целом довольно плотный, утрамбовать туда новую функциональность вряд ли получится.
Первым параметром передается какая-то структура, где есть размеры выводимой области, указатель на нее и еще всякое. Потом x,y, потом еще структурка..

 

Ага. Но это несложно, разберусь: структуры IFF'ов, где хранятся шрифты, я ещё в прошлом году повскрывал. Мне главное было - найти саму функцию.

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

Ха, это вообще не проблема, способ уже обкатан: в dxmci.dll добавлю naked-функцию, управление на неё заведу call'ом или jmp'ом из обсуждаемой и там сделаю все нужные дообработки. Я таким образом, например, например, патчил поведение функций toupper() и tolower(), когда добавлял поддержку русского ввода с клавы.

 

Рыжий Тигра, В некоторых случаях та функция возвращает ширину -1.
А я патчил, вписывая асмовый код в пустые места образовавшиеся из за 4-килобайтного выравнивания. А иногда удавалось прямо на месте.
Я пытался переводить Daggerfall когда-то - там пришлось пропатчить использование знаковых char, чтобы рисовались 8-битные символы.
.. код замера поищу. Но я пока не разобрался в структурах, есть непонятные моменты.

 

Типа ошибка? ОК, завтра покопаю.

Тоже неплохо. Но в данном случае изначально была возможность инъекции кода (через опен-сорсную dxmci.dll), вот я и не парился. :-)

Делюсь:

Код:

typedef struct /* wc4_glyph_s */ {
  int32_t width;
  uint8_t pixels[ 0 ]; // wc4_font_t::height * width
} wc4_glyph_t;

typedef struct /* wc4_font_s */ { // всегда выравнивается по чётному адресу!
  uint32_t signature; // 31 2e 00 00 
  int32_t glyphs; // кол-во глифов
  int32_t height;
  uint32_t bgnd;  // младший байт - код фона
  int32_t offsets[ 0 ]; // [ glyphs ] - массив смещений к глифам
//  wc4_glyph_t data[ 0 ]; // собственно глифы, но каждый переменной длины, так что. :-(
} wc4_font_t;