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

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

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

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

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

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

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

 

НА КОЙ?!! Основная доработка GOG'нутого WC4 заключается в удалении нахрен главной его изюминки - dxmci.dll и dwrap.dll - и замене их на мои. Соответственно, для русифицировать и поиграть отлично годится DVD-версия или даже "каноническая" шестидисковая DOS'овая с DVD upgrade patch'ем.
Кроме того, наложение перевода на GOG'овую лицуху напрочь убивает её вторую (а для кого и первую) по главности изюминку - лицензионность, превращая её в банальную пиратскую копию. :-( А ты, соответственно, становишься соучастником. Выбирай... :-
(В скобках: если выберешь соучастие - заодно поделись версией от Origin, у меня её ещё нет. Выкладывать киноролики не обязательно - вряд ли они хоть байтом отличаются от остальных версий; а вот всем остальным файло́м - делись!)

А насчёт

или

я ж уже выкладывал инструкцию по установке.

Увы. Перевод кинороликов с диалогами подзастрял на середине, хочу сначала догнать его переводом вылетов, а потом уже продолжу синхронно.

--- добавлено 31 дек 2016, предыдущее сообщение размещено: 31 дек 2016 ---

Кстати, рождественских/новогодних каникул не будет - третьего опять на работу. :-( Соответственно, полноценная выкладка опять откладывается. Пока собираю 14-ю бету, надеюсь где-то завтра-послезавтра выложить.

 

(голосом Джея из "Догмы") Ну, типа я Дед Мороз, а это от меня новогодний подарок - 14-я (надеюсь, последняя перед серьёзным выпуском) бета: wc4dvd-rus-beta14-7z



Отличий от предыдущей выкладки - много описано тут и ещё несколько:

• самые свежие финальные титры со списками участников создания перевода;
• 16-битные видеорежимы заменены на 32-битные;
• в очередной (вроде бы наконец последний) раз изменены формат и содержимое индексных субтитровых дорожек в "матрёшках"-кинороликах;
• вроде бы доведён до ума вывод субтитров к кинороликам при их просмотре directshow'ным плеером (Media Player Classic, mplayer2, graphedit);
• убрана пара ошибок (старых, ещё от Origin Systems), приводивших к падению игры при отсутствии/нечитаемости некоторых файлов;
• исходники переехали под SourceSafe: теперь в каждом исходном файле ведётся history его правок и вообще можно в случае чего взять "снимок" исходников за любую дату и посмотреть - что когда изменилось и в результате каких именно изменений появился (или исчез) такой-то глюк;
• в архив с исходниками dxmci.dll добавлены выдранные из микро$офтовких SDK куски и несколько сторонних библиотек, чтобы для компиляции это всё не разыскивать и не устанавливать;
• шрифты поделены на страницы, чтобы можно было собирать xlat*.iff-файлы с переводами на разные языки с разными кодовыми страницами (в планах - испанский перевод, но можно делать хоть на иврит хоть на грузинский);
• изменён формат файла files.bbs при разборке (утилитой trextra) / сборке (tremake'ом) .tre-файлов;
• добавлен перевод списка пушек на борту самолётов соответственно языку, на который настроена игра (т.е. в английской версии список будет английским, в русской - русским), до сих пор этой фишки не было;
• убрано несколько десятков мелких ошибок, накопившихся за несколько лет;
• это ещё не все изменения, но больше навскидку не помню...

В раздачу включены также .torrent-файл раздачи .mkv-файлов кинороликов (misc\wc4-indexed-20161231-2114.torrent), исходники всех программ (src\dxmci*.7z), исходники русского перевода и английского "перевода" плюс шрифты (src\xlat*.7z), мои savegame'ы (save\*.wsg) и .reg-файлы настроек directshow-фильтров, задействованных в игре для воспроизведения кинороликов (reg\*.reg).

Магнитная ссылка на раздачу кинороликов: magnet:?xt=urn:btih:22C2F1224BF27C6CCA4D816594C56EC19F454DD3
Прошу качать и оставлять на раздаче. Я буду сегодня раздавать до упора - минимум где-то до полуночи по Гринвичу и завтра весь день, так что помощь в раздаче мне очень даже пригодится.

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

С Новым Годом!

P.S. Чуть не забыл. Инструкция по установке, в общем-то, принципиально не изменилась:

• установить игру (любую windows-версию - "каноническую" с DVD upgrade patch'ем, DVD'шную или GOG'овскую) и проверить, всё ли работает;
• поверх развернуть из архива с бетой файлы из корневого каталога (оригинальные файлы dxmci.dll и dwrap.dll (если есть) рекомендую перед перетиранием сохранить - вдруг что-то не пойдёт и придётся восстанавливать);
• создать подкаталог mkv и в него переписать ролики из раздачи по магнитной ссылке выше или по .torrent'у из архива с бетой (это одна и та же раздача и, соответственно, одни и те же файлы);
• dxmcicfg'ом подправить настройки (пути к роликам, язык субтитров, видео- и аудиорендереры и т.д.) по вкусу;
• установить, настроить и проверить Haali media splitter, CoreVorbis, ffdshow и DirectVobSub;
• mcitest'ом проверить работоспособность кинороликов и субтитров;
• начать игру.

P.P.S. Ё-пс, извиняюсь: впопыхах выложил неправильный архив. Сейчас он правильный; кто уже стянул - берите снова.

Upd. Добавил финальные титры.

 

взял вот так и переименовал тему. простите, но новый год же и желания должны сбываться.
@Dimouse, не мог бы закрепить первое сообщение, пожалуйста?

 

его бы сперва в божеский вид привести, а то последнее больше смысла закрепить первым.

 

Кстати, имеет смысл.
Кстати-2: @Dimouse, неплохо бы дать мне возможность редактировать мои старые (до переезда на новый движок) посты - тот же первый особенно.

 

За два дня отоспался - и вернулась старая шиза: сделать вывод картинки через оверлей. Предыдущий опыт с размазыванием цвета под YUV'ом учёл - можно просто удвоить ширину (для YUY2) или ширину-высоту (для YV12).
@nop, ты как считаешь - имеет смысл?
Пока лежу разбираю примеры от микро$офта - в SDK на DirectX 7.0a нашёл какого-то mosquito, на нём тренируюсь. :-)

--- добавлено 1 янв 2017, предыдущее сообщение размещено: 1 янв 2017 ---

@Dimouse, thnx, ща опробую.

 

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

Upd: Ага, вижу: IDirectDrawSurface::UpdateOverlay() первым параметром принимает исходный прямоугольник - вот тут и можно будет обрезать. Ща обкатаю на "моските"...
Ура, нормально обкорналось.

 

Есть идея: поскольку попытка преобразовать картинку из RGB в YUV directdraw'ным Blt()'ом провалилась, припахать для этого дела Avisynth. В идеале - не из исходников выдрать кусок с перекодировкой (там своё дерево классов и придётся трансплантировать приличную его часть), а как-то присосаться к avisynth.dll и вызывать из неё функцию ConvertToYUY2().
Второй вариант - налабать avisynth'овый скрипт, им сгенерировать таблицы перекодировки RGB->YUV и включить их в dxmci.dll. Для RGB16->YUY2 такая табличка завесит всего четверть мегабайта - чуть меньше, чем сейчас весит релизная сборка dxmci.dll; для палитрового RGB8 ситуация не настолько радужная - рожать килобайтную табличку придётся под каждую палитру, а для этого их придётся сначала все найти в игре и выковырять... :-(

 

Сделал на пробу. Есть два неприятных эффекта:

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

Первая грабля, по идее, должна легко лечиться удвоением также и высоты картинки, т.е. до 1280*960; вторую, похоже, исправит только отключение оверлея. :-(
Зато в YUV при удвоении ширины цвета не "мажутся", что ИМХО весьма плюс, к тому же оверлейная картинка заметно резче просто увеличенной.

Upd. Попробовал удвоить оверлею высоту. Шикарно получилось! Аж сам себе завидую. :-) И потребление процессора - всего ничего: преобразование одного кадра из 640*480 8-битной палитровой картинки в системной памяти в YUY2'йный оверлей 1280*960 в видеопамяти занимает где-то 500-800 микросекунд. (16-битную преобразовывать ещё не пробовал.)

Upd2. А вот писать по оверлею DrawText()'ом (в сцене с некрологом) не получается хоть тресни: не берётся device context от оверлейной поверхности. :-( Хоть бери и опять вводи промежуточное преобразование в что-ньдь вроде 640*480*32 RGB из уже из него в YUV. :-(

--- добавлено 6 янв 2017, предыдущее сообщение размещено: 5 янв 2017 ---

Хм. За почти неделю - никто ни одного байта не стянул. :-( Если кто-то пытается, но не выходит - пишите, покумекаем...

 

Опробовал. На весьма нехилой тачке - от 6 до 15 миллисекунд на кадр (оно и не удивительно - 9 32-битных умножений на пиксел...). :-(
Можно, конечно, не весь кадр в лоб перегонять RGB8 -> RGB32 -> YUY2, а только кусочек с надписью; можно сделать т.н. "тройную буферизацию" - картинку из RGB8 транслировать одновременно в YUY2 и в две копии RGB32, в одну копию рисовать текст, потом сличать со второй и перегонять из RGB32 в YUY2 только изменившиеся пикселы... но всё равно это время. Надо искать, как впилить текст непосредственно в YUY2. Что-то похожее я видел в софтинке по имени xy-vsfilter...

 

Блин. С фига я парюсь: 640 * 480 = полмиллиона с гаком пикселов, но цветов-то всё равно не больше 256, если никакие доп-субтитры со сглаживанием не выводить, и аж (на глазок) пара тысяч, если выводить. Так что можно просто завести хэш на тыщонку-другую цветов - конечно, каждый цвет надо будет перевести из RGB в YUV, но только один раз...

 

В ходе работы над оверлейным выводом опять понадобилась двухмашинная отладка. Реанимировал старый комп, запустил, опробовал и сильно расстроился: его AGP'шная видеокарта захлёбывается при передаче YUY2'шного оверлея с разрешением 1280*960 - один кадр передаётся 25-30 миллисекунд. Про вывод 32-битной картинки, софтверно растянутой до того же размера, я вообще молчу. :-(
Учитывая, что вся возня с оверлеем затеяна чтобы аппаратный ресайз не замыливал картинку, а программный - не жрал процессор, пребываю в растерянности и не знаю что делать. :-(

Во-во, тут именно тот случай, когда без аппаратного ускорения никак - или игра будет на AGP'шных машинах ползать как мокрая муха, а чем тогда мой вариант лучше GOG'овского dwrap'а? :-

 

@Рыжий Тигра, прошу прощения, лежал в больнице со средней ЧМТ. Такие вот каникулы.
Что касается ускорения блита из системной памяти - практически всегда можно самому копировать данные в видеопамять не медленнее. Именно это я имел ввиду, говоря про "неактуальность". Да, при этом задействуется процессор, но его можно при этом обычно загрузить чем-то еще, например, ресайзом или конверсией формата.

--- добавлено 10 янв 2017, предыдущее сообщение размещено: 10 янв 2017 ---

Я ведь писал уже . Ни в какие быстрые и специализированные форматы нельзя выводить графику системными средствами. Я предлагал поэтому отдельный Surface специально для рендера текста, потом конвертировать/объединять его с основным.

--- добавлено 10 янв 2017 ---

Я предлагал сделать. Но сейчас не могу обещать сделать быстро, пока еще инвалид

--- добавлено 10 янв 2017 ---

Прости, но это малость

 

@nop, сочувствую. Вычухивайся, ты нужен нашей цивилизации! :-)

Да это-то понятно. Я о том, что скорость упирается в пропускную способность AGP'шной шины (при пересылке одиночных 32-битных значений - всего 133 МБ/с), поэтому чем меньше размер просовываемой в видеопамять картинки и чем больше работы удастся спихнуть на процессор видеокарты, тем лучше. В идеале, видимо, сгружать в видеопамять картинку 640*480*8[*], а там уже серией directdraw'ных операций распяливать её до 32 бит, дорисовывать субтитры и растягивать до нужного размера.
С другой стороны, если видеоконтроллер встроен в процессор, то пропускная способность шины уже не самое узкое место и можно таки все дообработки делать программно. Но тогда вопрос в том, как отличить первый случай от второго. :-(
(Например, вручную - в dxmcicfg сделать не два варианта, а штучек пять-шесть

Например, такой набор:

• 640*480*16 - самая чёткая картинка, самый простой и самый быстрый для медленной шины, только для мониторов 4:3;
• 640*480*32 - тоже для 4:3;
• 640*480 RGB-оверлей (если поддерживает видеокарта; интересно также поиграться с оверлеем YUV 4:4:4) - чёткость поменьше, зато без переключения разрешения экрана и требования к шине такие же как для предыдущего режима;(
• 1280*960 YUV 4:2:2-оверлей - видимо, потолок для AGP: под 60 МБ/c. Годится и для широкоэкранных мониторов (но при ширине экрана меньше 1024 начинается "кирпичный" эффект), даёт максимальную (после 640*480) чёткость картинки;
• без переключения разрешения, 16 и 32 бита: для ш/э мониторов, максимальная нагрузка на шину, самая замыленная картинка - в общем, последний шанс для тех, у кого оверлей никак не работает.

и опытным путём подбирать наиболее удобный.)
Над AGP я ещё поэкспериментирую - старая тачка работает стабильно, мониторов тоже два - 4:3 и 16:9 и могу их переключать как хочу.

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

Насчёт хэширования цветов:

Да не, пересчитать 256 цветов из RGB в YUV занимает жалкие десятки микросекунд, выигрыш будет весьма существенный по сравнению с полным пересчётом.
----------------------------
* Тут тоже, хм, есть интересный вопрос. Прикол в том, что в "статической" части игра может формировать картинку либо 16-, либо 8-битную, причём по умолчанию как раз 16-битную. А где/как/чем переключает битность - я пока не нашёл. :-( А то давно бы отрубил нафиг 16-битную ветку - в 8-битке и перехват проще, и возможности дообработки побогаче.

 

Это означает относительно новую систему, которая в серьезных оптимизациях уже не нуждается(Кроме экзотичных mediaGX). Как цель оптимизации следует выбрать именно самую медленный. Неважно, что на более быстрых решение будет менее оптимально.

Эмм. Ты измерял? Почему одиночных? Пиковая скорость 528MB/s у AGP1.0.

Ты делаешь очень оптимистичное предположение, что целевая видеокарта умеет аппаратно, из видеопамяти в видеопамять, конвертировать палитровую текстуру в RGB. Интуиция подсказывает, что это, скорее всего, неверно, и ты от драйверов получишь очень медленную конверсию из видеопамяти в видеопамять процессором. Пусть даже такие карты есть, и это какая-нибудь 2D-шная Trident, Ati Mach 64, Tseng или Cirrus Logic. Но они ведь уже экзотика!
Если уж ты решил привязываться к настолько старым картам, поделюсь проверенной на практике сверхполезной фичей. Cirrus Logic умели выводить RGB-оверлей!

--- добавлено 11 янв 2017, предыдущее сообщение размещено: 11 янв 2017 ---

Кстати, для старых компов можно еще попробовать 24-битные (не 32-битные) режимы. Экономит пропускную способность за счет процессора. Но вообще, настолько все плохо было лишь во времена PCI и ISA.

 

В burst-режиме, когда сразу после адреса данные валят подряд потоком. Обычно это легко реализуется через DMA. А вот чисто программно - увы, каждая запись DWORD'а - это отдельная операция: сначала DWORD адреса, потом DWORD данных, а между ними ещё ожидания с подтверждениями. PCI при таких условиях обеспечивает ну аж 33 МБ/с; AGP, по идее, должен давать вчетверо больше.

(пожимает плечами) По умолчанию. Контроллер PCI, во всяком случае, работает именно так при попытке засунуть в PCI-девайс 32-битное число. Возможно, если пихать 64- или более-битные, будет инициирован короткий burst, но тут я уже спецификацию PCI не помню, а самому применять ни разу не приходилось.

Ясен перец. 1280*960*2 байта - как раз 20 с чем-то миллисекунд, чуть меньше 120 МБ/с.

И не только "циррозы": у меня на старой тачке стоит выпущенный в прошлом тысячелетии ATI RADEON 7500 (ещё из тех, оригинальных, с фильтрами дохренадцатого порядка на выходе), так я ему только что подсунул запрос на создание RGB-оверлейной поверхности - и он вернул DD_OK! Вот сейчас докончу недоделанное сегодня на работе, а потом допишу кусок кода для RGB-оверлея и хоть посмотрю, как он выглядит в действии. :-)

(вздыхает) Значит, залягу читать help на IDirectDraw::GetCaps() и проверять DDCAPS_'овые флаги. Наверняка там может что-то заваляться полезное. :-

Согласен. Но оптимальное по скорости - не обязательно самое удобное для геймера, поэтому лучше оставить какую-никакую свободу манёвра по граблям, не? :-)

 

Странно, что получилось так мало. С каких пор отменили write buffers у процессоров? Аппаратную оптимизацию memcpy тоже не вчера придумали. А еще можно писать 64-битными MMX-инструкциями, либо 128-битными SSE.

 

Про AGP не знаю, только про PCI: на том конце шины может быть не ОЗУ, а порты ввода-вывода, служебные регистры и тд, поэтому кэшировать чтение-запись сквозь PCI низзя - может случиться, что какие-то обращения не произойдут или будут не в том порядке, работа устройства нарушится. :-( В книгах про PCI это было, лет с 15 назад я на эти грабли напарывался. :-(

Ха, в MSVC6 (который у меня на вооружении стоит) этого и не ночевало - наоборот, memcpy() куда тормознее, чем даже тупой do { *( dst++ ) = *( src++ ); } while ( --count );.

За эти не знаю - когда-то один раз пробовал применить на PCI-устройстве, которое (как потом оказалось) burst-циклы не поддерживало вообще. Так и не выяснил, могут они хотя бы в принципе работать burst'ом или всегда раскладываются на отдельные 32-битные посылки. :-(

 

@Рыжий Тигра, может, попробуй создать в памяти буфер, выровненный по 64-м байтам, на 1 строку картинки. Конвертировать/ресайзнуть строку картинки в этот буфер, потом его memcpy в соответствующую строку за lock()-еного surface.

--- добавлено 12 янв 2017, предыдущее сообщение размещено: 12 янв 2017 ---

@Рыжий Тигра, Я, к своему стыду, так и не запускал. Поэтому спрашиваю, на какой процессор собираешься ориентироваться, по минимуму?