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

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

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

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

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

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

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

 

Попробую. Но чуда не ожидаю: memcpy() это просто rep movsd :-(

Видимо, на пентиум-4: более ранние не тянут воспроизведение кинороликов ("матрёшка", видеоряд - 640*480 XviD, звук - двухканальный Ogg Vorbis). Соответственно (если верить википедии), можно использовать MMX, SSE и SSE2. Но поскольку и мой dxmci, и сама игра иногда иcпользуют плавающую точку, то нужно будет каждый раз сохранять-восстанавливать состояние сопроцессора. :-(

 

При должной длине и выравнивании movsd превращается в перемещение целых кэш-строк.
Во времена Pentium 2 и K6 я делал эксперименты, сравнивая пересылку uint32 в цикле, rep movsd и MMX. Относительная разница была невелика и зависела от длины, выравнивания и прочего. Кончилось тем, что я при запуске приложения делал мини-бенчмарк и выбирал одну из этих функций.

Если память не подводит после удара головой, только MMX в этом нуждается, да и у него стоимость вызова EMMS не так уж велика, эту проблему искусственно раздули когда-то "эксперты", которые сами ни строки кода не написали. Или ты про что-то другое? А нам есть смысл для копирования данных попробовать использовать первый SSE, который работает начиная с P-III. SSE2 подменяет MMX, но у P4 не дает при этом серьезных преимуществ по скорости над MMX, вплоть до появления линейки Core.

 

Ну дык PCI-контроллер же ж не дурак и как раз кэш на это дело отключает. :-( За AGP не знаю.

С этой парой я тоже развлекался, правда, на P3, - для копирования ОЗУ-ОЗУ rep movsd работал куда медленнее, чем в цикле из [ ESI++ ] в EAX и из него в [ EDI++ ].

Кстати, для совсем начала можно и проще - 8-байтными double'ами. Ща поэкспериментирую и расскажу чем кончилось. :-)

Upd. А фиг там: ( (double *) dst )[ 0 ] = ( (double *) src )[ 0 ] компилируется в пару обычных 32-битных перебросок. :-(

 

Известная засада. Компилятор понимает, что идет переброс из памяти в память без обработки и делает ее как сочтет нужным. Сам на это ловился совсем недавно. Попробуй присвоить промежуточной переменной типа double.

 

Не помогло. :-( Даже хуже - добавилось ещё каких-то пересылок и общее время обработки кадра возросло с 21-22 до 26-27 миллисекунд. :-(

Угу, ты прав. Blt() вернул код "не поддерживается". :-(

 

@Рыжий Тигра, Я уже не раз высказывал мое мнение об "акселерации" через ddraw. Она, по моему мнению, принесла геймдеву намного больше вреда, нежели пользы. Разные карты поддерживают то подмножество, какое пожелают и так, как пожелают, да и набор имеющихся операций откровенно беден. Обидно, ведь отдельные карты действительно аппаратно умели ускорять некоторые операции очень сильно, намного быстрее, чем можно было сделать, используя процессор, особенно во времена 486 и более ранних.
Попытка Майкрософта загнать ранние 2D/3D карты в прокрустово ложе их кривоватых API - это "натягивание совы на глобус".

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

Вообще обидно, что при программировании через пропиетарные API большинство этих ранних видеокарт карт спокойно побивало по скорости и фичам тот же Playstation, но на Playstation были сотни/тысячи игр, в то время как покупатель видеокарты почти ни во что не мог поиграть без тормозов или глюков. Разве что в несколько игр, продававшихся в комплекте, к которым потом даже патчи не подходили.

 

В общем, получается вот такой список видеорежимов:

Код:

; DrawMode: дополнительные возможности вывода изображения в полноэкранном
;           режиме:
;        0: none / отключены -
;           без дополнений (принудительное отключение dwrap.dll в GOG-сборке);
;           вывод дополнительных субтитров (некрологи, лекции Папаши на экране
;           выбора/конфигурации машины) только в оконном режиме;
;        1: minimal: GOG-like / только под GOG-версией -
;           если в .exe'шнике прописан dwrap.dll (как в сборке от GOG) -
;           через него, иначе как изначально в игре; dwrap.dll конфигурируется
;           через файл renderer.cfg. Это единственный возможный режим
;           при отключенном bXlatGame. Дополнительные субтитры также выводятся
;           только в оконном режиме;
;        2: dwrap: opengl -
;           принудительный вывод через dwrap.dll в режиме "opengl" (как в
;           GOG-версии игры): без переключения разрешения на более низкое;
;           поддержка широкоэкранных дисплеев на кинороликах; блокировка
;           переключения из полноэкранного режима в оконный, сворачивания
;           в линейку задач и переключения на другую задачу; дополнительные
;           субтитры (только с доработанной dwrap.dll) без сглаживания.
;           ВНИМАНИЕ: при попытке подключить оригинальную GOG-версию dwrap.dll
;           к wc4dvd.exe v3.02 игра зависает - это дефект dwrap.dll,
;           в доработанной версии устранён;
;        3: dwrap: direct3d -
;           принудительный вывод через dwrap.dll в режиме "direct3d" -
;           сейчас это фактически directdraw; не рекомендуется, оставляю для
;           совместимости с будущими версиями dwrap.dll;
;        4: hicolor, 640*480 / 16-бит цвет, 640*480 -
;           directdraw в 16-битном цвете вместо 8-битного: убирает глюки
;           с палитрой под win7 и win8; вывод дополнительных субтитров
;           в полноэкранном режиме со сглаживанием; годится для мониторов 4:3
;           и медленных PCI- и AGP-видеокарт, самая чёткая картинка;
;        5: truecolor, 640*480 / 32-бит цвет, 640*480 -
;           directdraw в 32-битном цвете: то же, но требует более быстрого
;           доступа к видеопамяти (как минимум AGP); позволяет очень быстро
;           переключаться с игры на рабочий стол и обратно;
;        6: RGB overlay, widescreen / RGB-оверлей, широкий экран -
;           то же, плюс вывод картинки без переключения разрешения на более
;           низкое, плюс поддержка широкоэкранных дисплеев на кинороликах,
;           панорамных сценах (автопилот, катапультирование, некролог и т.д.)
;           и финальных титрах; требует видеокарту с поддержкой RGB-оверлея.
;           Самый продвинутый режим для AGP-видеокарт, рекомендуется в первую
;           очередь;
;        7: YUV overlay, widescreen / YUV-оверлей, широкий экран -
;           то же, не требует поддержки RGB-оверлея видеокартой, но AGP-шины
;           для него мало - нужен PCI-E или видеоконтроллер в процессоре;
;           самая чёткая картинка после режимов 640*480, но при разрешении
;           не ниже 1280*960; рекомендуется для широкоэкранных Full-HD
;           дисплеев;
;        8: hicolor, hires, widescreen / 16-бит цвет, широкий экран -
;           то же, но для небольших разрешений (1280*720 и ниже) с видеокартой
;           без RGB-оверлея; годится для AGP-видеокарт c широкоэкранным
;           дисплеем. Чёткость картинки заметно хуже, чем с YUV-оверлеем;
;        9: truecolor, hires, widescreen / 32-бит цвет, широкий экран -
;           то же, но 32-битный цвет позволяет быстрое переключение с игры
;           и обратно; годится для PCI-E- (и быстрых AGP-) видеокарт c
;           широкоэкранным дисплеем.
DrawMode=7

Это фрагмент комментированного dxmci.ini (для сравнения - предыдущая версия

Код:

; DrawMode: дополнительные возможности вывода изображения в полноэкранном
;           режиме:
;        0: none / отключены -
;           без дополнений (принудительное отключение dwrap.dll в GOG-сборке);
;           вывод дополнительных субтитров (некрологи, лекции Папаши на экране
;           выбора/конфигурации машины) только в оконном режиме;
;        1: minimal: GOG-like / только под GOG-версией -
;           если в .exe'шнике прописан dwrap.dll (как в сборке от GOG) -
;           через него, иначе как изначально в игре; dwrap.dll конфигурируется
;           через файл renderer.cfg. Это единственный возможный режим
;           при отключенном bXlatGame. Дополнительные субтитры также выводятся
;           только в оконном режиме;
;        2: truecolor, 640*480 / 32-бит цвет, 640*480 -
;           directdraw в 32-битном цвете вместо 8-битного: убирает глюки
;           с палитрой под win7 и win8; вывод дополнительных субтитров
;           в полноэкранном режиме со сглаживанием;
;        3: truecolor, hires, widescreen / 32-бит цвет, широкий экран -
;           то же, плюс вывод картинки без переключения разрешения на более
;           низкое, плюс поддержка широкоэкранных дисплеев на кинороликах,
;           панорамных сценах (автопилот, катапультирование, некролог и т.д.)
;           и финальных титрах. Самый продвинутый режим, рекомендуется
;           в первую очередь;
;        4: dwrap: opengl -
;           принудительный вывод через dwrap.dll в режиме "opengl" (как в
;           GOG-версии игры): без переключения разрешения на более низкое;
;           поддержка широкоэкранных дисплеев на кинороликах; блокировка
;           переключения из полноэкранного режима в оконный, сворачивания
;           в линейку задач и переключения на другую задачу; дополнительные
;           субтитры (только с доработанной dwrap.dll) без сглаживания.
;           ВНИМАНИЕ: при попытке подключить оригинальную GOG-версию dwrap.dll
;           к wc4dvd.exe v3.02 игра зависает - это дефект dwrap.dll,
;           в доработанной версии устранён;
;        5: dwrap: direct3d -
;           принудительный вывод через dwrap.dll в режиме "direct3d" -
;           сейчас это фактически directdraw; не рекомендуется, оставляю для
;           совместимости с будущими версиями dwrap.dll.
DrawMode=3

).

 

Затеял переделку directdraw'ного перехватчика (ddhook.cpp в исходниках) - а то в нём уже заплат больше чем собственно кода, да и заодно вспомню его логику...

 

В ходе переделки directdraw'ного перехватчика провёл серию экспериментов - искал наиболее скорострельные алгоритмы пропихивания данных через AGP. Но увы - в этой гонке лидируют (с где-то трёхкратным отрывом от лучших моих решений) старые добрые IDirectDrawSurface::Blt() и ейный братец IDirectDrawSurface::BltFast(): 360..380 МБ/c. Как, блин, они это делают??? Не понимаю... :-(

 

/* очень смешно */

Ну, для каждого случая есть что то своё, например для S3Trio V64+

Код:

procedure BLT(SrcX,SrcY,DstX,DstY,W,H:word);
begin
PortW[$86E8]:=SrcX;
PortW[$82E8]:=SrcY;
PortW[$8EE8]:=DstX;
PortW[$8AE8]:=DstY;
PortW[$96E8]:=W-1;
PortW[$BEE8]:=H-1;
PortW[$9AE8]:=$C0F3;
end;

заметь - это PCI.

 

@Bato-San, тонко намекаешь, что лезть самому в тайны bus master mode'а не надо, а более-менее внятного API драйвер видеокарты не предоставляет? :-) Я знаю. Но мне сильно неохота вместо одного промежуточного surface'а для наложения субтитров делать два - один для субтитров, а второй для YUV'а. :-( Хоцца пропихивать байтики пачками по строке, а не цельный кадрик за раз.

 

@Рыжий Тигра, я пока только нашёл намёк, что agp fast writes могут тут помочь. https://forum.nvworld.ru/viewtopic.php?f=3&t=2331
Ещё у меня сформировалось подозрение, что если не делаешь именно 64-битных записей в AGP, максимальной скорости не добиться
А так - да, мой опыт оптимизации в основном относится ещё к ISA и PCI, подводных камней AGP тогда не знал.

 

Про эту фишку я знаю. Вопрос в другом - из какой библиотеки какую/ие функцию/и вызывать, чтобы загнать в память видеокарты сразу пачку байтиков, а не пихать по одному mov'ами. Пока что под руками есть только тот же BltFast(), но это неудобно - надо строить в системной памяти surface таких же размеров и с такими же параметрами, как surface в видеопамяти, в него конвертировать картинку с уже наложенными субтитрами (в случае вывода YUV-оверлеем; во всех RGB-режимах субтитры можно накладывать прямо в нём), а потом целиком перегонять в видеопамять.
(В случае с режимами 8 и 9 ситуация ещё интереснее - в видеопамяти надо строить два surface'а: один собственно для вывода на экран (с размерами как у экрана и параметрами DDSCAPS_PRIMARYSURFACE и, если железо не против, :-) DDSD_BACKBUFFERCOUNT), а второй - размером 640*480 и DDSCAPS_OFFSCREENPLAIN - заполнять BltFast()'ом из surface'а в системной памяти и затем Blt()'ом ресайзить в нужную часть (4:3 или 16:9) первого surface'а.)

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

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

 

В общем, это должно быть включено и поддержано видеокартой И чипсетом. https://www.google.ru/search?newwindow=1&q=uncached+speculative+write+combining
Я помню, как ещё во времена Квейка под досом была утилита для включения этой фичи. В теории, поддерживалось Intel начиная с PPro, и возможно была также и у Cyrix/AMD.

 

Авотфиг! Пытаюсь создать в системной памяти surface формата YUV2 - получаю отлуп DDERR_INVALIDPIXELFORMAT. :-(
Соответственно, идея о быстром переносе картинки в видеопамять Blt()'ом пролетает. Абыыдно... :-(((((

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

Хотяяя... можно попробовать трансректально:

• каким-то образом (ещё не знаю как) отхватить кусок видеопамяти;
• на него создать два surface'а - правильный оверлейный YUV'ный и "левый" offscreen'овый RGB;
• картинку конвертировать в YUV, но складывать в surface в системной памяти с фальшивым типом таким же как у "левого";
• копировать Blt()'ом в "левый" surface - должна, по идее, проявляться на экране...

 

Задачка с копированием YUV-картинки в видеопамять Blt()'ом решена. Ваяю дальше.

 

Просматриваю ролики из игры. Интересно, это только я заметил, что Маньяк в последнем картёжном сражении со Скитальцем, тыча ему под нос четыре карты с дамами, намугыкивает "Боже, царя храни"? Не, ну понятно, что в оригинале это было God Save the Queen, но как бы это поизящнее обыграть в переводе?

 

"Боже, царя храни" – отличная идея!

 

@Neitan, а как оформить? Допустим, Маньяк вместо намугыкивать поёт первую строчку (в кадре в этот момент его лица нет, так что в принципе можно) в виде "Боже, меня храни

Из старого детского фильма, где царь сам себя восхвалял :-)

", а вместо "I got four queens" выдаёт "Я царь горы!" и далее по тексту - про синюю птицу, леди Удачу и т.д. И всем, кто в курсе идиомы "царь горы", сразу ясно - чувак капитально мандражирует и сейчас его побьют. Покатит такое, как считаешь?

 

Думаю, прокатит. Но "Боже, царя храни" более "близко" к оригиналу)