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

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

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

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

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

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

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

 

@Scorpion ZS 256, а можешь создать проект (или как оно там называется) и залить туда для начала хотя бы тех же "технических" персонажей? А то мне совершенно некогда - работа заедает, почти третий месяц аврал в стиле "пятилетку в три дня". :-(

 

@Scorpion ZS 256, заглянул я на transifex на предмет посмотреть на чьи-ньдь переводы (а может, при случае в каком-то и поучаствовать) - и ничего не нашёл / никуда не пробился: предлагают только либо зарегиться, либо посмотреть демку (а перед тем опять же зарегиться). Сплошная секретность. :-( Можешь устроить мне инвайт на экскурсию по сайту? :-)

 

А как я тебе устрою, если ты не зарегался? Могу тебе дать посмотреть на мой проект, если хочешь. Порегайся только и в PM напиши аккаунт, я тебя добавлю в свой проект.

 

Ссылкой на страницу с твоим проектом, например. Или там настолько жёсткая секретность, что без пароля даже просто поглазеть не пустят? :-)

 

Да, без аккаунта не дадут поглядеть даже. Регайся.

 

Сектанты?

 

копирасты. (в смысли виноваты)

 

Никому не нужно повторения истории с нотабеноидом (как правильно заметил Ogr 2)

 

Выдался сегодня свободный денёк (типа у нас тут празднуют День Оккупационной Конституции), я покопался в старых постах и исходниках dxmci'я - и допёр, как можно уменьшить загрузку проца

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

. В полёте игра старается держать постоянную частоту кадров (24 в секунду) - значит, должна сама мерять время между кадрами, логично? Дальше просто: перехватываю QueryPerformanceCounter() и вызываю перед ним Sleep( 1 ). А чтобы картинка не трепыхалась в такт биений между 24-кадровой игрой и 64-герцовым системным таймером - в самом начале поднимаю ему частоту

вызовом timeBeginPeriod( 1 ) - когда-то @Bato-San мне подкинул пару статей про мультимедийные таймеры, я тогда не оценил, а пригодилось! Делюсь линком: Timing in Win32 - вдруг ещё кого-то выручит.

по самые уши, до примерно полкилогерца. Эффект потрясающий: игра между кадрами успевает пару десятков раз запросить время, проц работает только одним ядром на процентов 20 от силы - и вентилятор практически не слышно. :-)

Но эффект нестабильный: стоит загнать ноут посреди игры в standby mode - и после пробуждения игра начинает идти рывками. Оказалось, что после выхода из спячки частота системного таймера сбрасывается назад на 64 герца. Отдельной функции для проверки на спячку не нашёл, то сделал финт ушами: в том же перехватчике QueryPerformanceCounter() проверяю - если его больше секунды не вызывали, то принудительно сбрасываю частоту системного таймера в дефолтную

через timeEndPeriod( 1 ) - из той же статьи.

и обратно задираю до упора. Помогло!

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

 

Нашёл два места, где трюк с перехватом QueryPerformanceCounter() не помогает и проц кочегарится на полную катушку:

• ожидание подтверждения готовности к взлёту;
• вывод внутрикиношной менюшки.

Хвала аллаху, оказалось, что в обоих местах в цикле вызывается PeekMessage() - его тоже перехватил и воткнул Sleep( 1 ).
(Было ещё несколько подобных мест с циклами из PeekMessage()'й - настройки на авианосце и в полёте, посмертное меню, полётная карта, - но их я замедлил Sleep()'ами по нескольку десятков миллисекунд уже давно, так что сейчас специально не заморачиваюсь.)

 

А фиг, нельзя PeekMessage() стормаживать - на медленной машине игра еле ползает, в полёте 15-17 кадр/с всего, а на Sleep()'ы уходит почти половина процессора. :-( Пришлось и для киноменюшки, и для ожидания перед взлётом найти соответствующие циклы в коде игры и впилить Sleep( 1 ) в них.
А с перехватом QueryPerformanceCounter() ещё хуже - в самом начале финальных титров слово "КОНЕЦ" проявляется уже не секунду с чем-то, а раз в десяток быстрее. :-( Причём даже Sleep() из перехватчика убираю - всё равно частит. Буду разбираться...

 

*пожал плечами...
EmulateSlowCPU включи в Application Compatibility Toolkit для исполнимого файла игры.
Во многих Win9x играх, вылетавших или ускоренных в WinXp из-за QueryPerformanceCounter - помогало. Правда в некоторых - нет.

 

Уже установил. Куда нажимать?

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

Уже нашёл: в цикле приёма message'й окном

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

ловлю WM_POWERBROADCAST с wParam == PBT_APMRESUMESUSPEND и по нему частоту таймера уже восстанавливаю дефолтную и тут же обратно выставляю нужную. Соответственно, переустановку по тайм-ауту неактивности выбросил из-за громоздкости и ненадёжности.
Но тут тоже засада: если в момент срабатывания WM_POWERBROADCAST'а крутится игра - всё путём, а если видеоролик, то системным таймером командует какой-то из directshow-фильтров и попытка в лоб сбросить-выставить частоту не срабатывает: по кодам возврата всё ОК, а по факту - так и остаётся 64 тика в секунду. :-(

 

В общем, поставил семь замедлителей:

• в цикле ожидания подтверждения готовности к взлёту - Sleep( 1 ) перед PeekMessage()'м - самый простой случай: цикл ничего не выводит, только ждёт нажатия клавиши, гашетки на джойстике или кнопки мыши;
• в цикле ожидания выбора из менюшки в киноролике - аналогичный случай, тоже обошёлся коротким Sleep()'ом;
• в цикле вывода кадров в сценах на авианосцах
  На "Лексингтоне" - главный терминал (расписание полётов, доска почёта, оружейка, состав звена), пост управления, полётная палуба, кают-компания. На "Неустрашимом" пока не проверял, но по идее должен работать этот же цикл.
  - там посложнее, нативной привязки к QueryPerformanceCounter()'у нет и в оригинале игра лупит по паре сотен кадров в секунду, то обошёлся трюком: вставил Sleep() переменной длины, при каждом его вызове засекаю время его окончания и на следующем круге задаю время отстоя более-менее 40 миллисекунд минус время, что уже прошло после засечки (то бишь время обсчёта и вывода предыдущего кадра), получается довольно точно 25 кадров в секунду;
• в полёте (собственно активный полёт, автопилот, катапультирование, гибель) - игра старается держать 23-24 кадр/с и между обсчётом очередного кадра и его выводом тянет резину в пустом цикле с QueryPerformanceCounter()'ом внутри. Проблема в том, что кроме этого цикла есть ещё с десяток вызовов QueryPerformanceCounter()'а - перед обсчётом кадра, после него, после вывода кадра... - в общем, пришлось попыхтеть под отладчиком и копаясь в дизассембле, но в конце концов нашёл цикл оттягивания резины :-) и вклеил в него такой же короткий Sleep(), как и в первых двух точках;
• в цикле вывода финальных титров - тут игра держит 30 кадр/с, реализация аналогична предыдущему случаю и метод лечения применил такой же;
• пауза в полёте - тоже жрёт процессор на полную катушку, крутится в таком же цикле из PeekMessage()'й, как и первая точка - ждёт нажатия чего-ньдь безо всякого вывода на экран; способ лечения такой же;
• переспрос о завершении игры по alt-X в полёте - работает точно так же и его терапия такая же.

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

В статике на авианосцах (точка 3) - совсем мало, на выводе финальных титров (точка 5) - чуть побольше, в вылете (точка 4) - ещё больше и зависит от насыщенности сцены

Пока больше всего видел на полётной палубе перед взлётом, что и понятно - прорисовка каждого квадратного дюйма будет кушать процессор...
(Кстати, расход процессора и частоту кадров в полёте легко увидеть - после нажатия Ctrl-F в левом верхнем углу появляется белая строчка вида "Frames: XXXX, Rend: YY%", где XXXX - текущая частота кадров (обычно 23, если проца хватает, если не - соответственно поменьше), YY - процент использования процессора конкретно под прорисовку картинки. Чтобы получить время прорисовки одного кадра в миллисекундах, умножаем YY на 10 и делим на XXXX.

.

и временем её вывода

Для примера: в сцене с траурной речью Барбары Майлз - перевод 8-битной картинки в 32 бита, наложение субтитров, растяжка вдвое для пущей чёткости, передача полученной картинки 1280*960*32 (почти 5 мег!) в видеокарту, там аппаратное (если есть) растягивание (или, наоборот, сжатие) до размеров полного экрана... пара десятков миллисекунд набирается легко. :-(

, ненужное процессорное время отдаётся диспетчеру сразу же, т.е. ни миллисекунды лишней игра себе не подгребает.

Всё это проверил ещё и на старой медленной одноядерной машине с AGP: убрал разгон проца, выбрал самый тормозной режим вывода картинки - 32-битный цвет с удвоенным разрешением, чтобы проц и шина гарантированно захлёбывались, и подержал каждый цикл по паре минут, фиксируя расход проца в диспетчере задач. Получилось более-менее 98-99%

, т.е. Sleep()'ы откусывают меньше 2% времени - значит, места их расположения угадал правильно.

PS. Кстати, мимоходом разгадал одну из самых стрррашных тайн DVD-издания WC4 - почему в оконном режиме, если не получается вывести видеоролик (нет файла, нет кодека или ещё что), киноменюшка выводится не в кадре, а вылезает под верхний левый угол экрана. Но это уже завтра - доделаю и расскажу.

 

Об обещанной тайне косого вывода киноменюшки. :-) Тут просто: перед проигрыванием ролика создаётся окно, в которое он будет выводиться, а его handle возвращается в игру через MCI'йный вызов MCI_STATUS с битом MCI_OVLY_STATUS_HWND; дальше из него берётся handle к контексту дисплейного устройства (HDC) и туда выводятся строки киноменюшек. А если ролик не проигрывается, то MCI_STATUS не вызывается, HDC берётся от NULL'а (то бишь от handle'а к полному экрану / рабочему столу) и менюшка базируется уже не об координаты в окне вывода ролика, а об координаты всего экрана. Исправил эту граблю одной строкой кода в модуле создания окна и двумя в перехватчике GetDC().

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

Проблема: вывод через GOG'овский OpenGL (режим DRAW_MODE_DWRAP_OGL) не очень-то и спешит отдавать ненужные процессорные кванты - на ноуте о четырёх ядрах грузит проц на процентов 60, вентилятор непрерывно воет. :-( То ли сам OpenGL настолько серьёзно жрёт проц, то ли dwrap.dll настолько неоптимизирован - разбираться влом.
Кто играет через OpenGL - отзовитесь!

 

Нашёл интересную библиотечку - hqx. Сразу захотелось к имеющимся режимам двойного разрешения добавить ещё и что-то наподобие DOSBox'ового hq2x. Запас Дури есть, приступаю к доработке.

 

Добавил, опробовал - не понравилось: где-то сглаживает, где-то замыливает, где-то оставляет оригинальные крупные пиксели - притом и то и другое и третье в пределах одного кадра, в результате картинка идёт шевелящимися пятнами. И проц жрёт безбожно. :-(
Убираю. Но в исходниках оставлю - вдруг кто-то захочет собрать dxmci.dll с этой фишкой, то раскомментирует #define RGB32_HQ2X в файле config.h и перекомпилирует.

 

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

PS. Пост про замедлители поправил - добавил туда шестой и чуть-чуть расписал подробнее про методику и результаты проверки потребления процессора.

 

Уже семь. Оказалось, что переспрос на прекращение игры по alt-X в полёте крутится в таком же цикле, как подтверждение готовности к взлёту и пауза в полёте. Соответственно, аналогично и лечится.

 

В ходе одладки замедлителей обнаружил забавную багофичу - в вылете C3 (погоня за шатлом Айзена) при взлёте с "Лексингтона" откуда-то берётся неуязвимость: попытка убиться об стенку ангара на форсаже не удаётся, только глохнет движок и падает до нуля защитное поле. После перехода на автопилот неуязвимость исчезает.
На голом WC4DVD (т.е. без подгрузки перевода и хаков) - то же самое, т.е. багофича не моя. Видимо,так задумано разработчиками. Но зачем???