Принципы перевода азиатских DOS-игр: различия между версиями

Материал из Old-Games.RU Wiki
Перейти к навигации Перейти к поиску
Строка 1: Строка 1:
 
{{CC|WERTA}}
 
{{CC|WERTA}}
  
Перевод азиатской ДОС-игры с двухбайтовой кодировкой наиболее оптимально может быть выполнен путем графической перерисовки в растровых шрифтах 16х16 с заменой азиатских символов парами русских (лат) псевдосимволов с соответствующей перекодировкой ресурсов строк.
+
Перевод азиатской ДОС-игры с двухбайтовой кодировкой наиболее оптимально может быть выполнен путём графической перерисовки в растровых шрифтах (например, с разрешением в 16х16 пикс.) с заменой квадратных азиатских символов всеми возможными сочетаниями пар русских (либо лат.) узких прямоугольных псевдосимволов (8х16+8х16), с последующей перекодировкой строковых ресурсов для их правильного отображения.
  
Конечно, для особых случаев можно и триплеты букв использовать, но, я думаю, это нереально, поскольку не все наши буквы удастся по три записать в растре 16х16. М, Ы, Ю с трудом вписываются в 8х16.
+
Конечно, для особых случаев можно и триплеты букв использовать, но, я думаю, это нереально, поскольку не все наши буквы удастся по три записать в растре 16х16. М, Ы, Ю с трудом вписываются в растр 8х16 пикс.
  
По степени нехватки места под наши символы можно грубо сортировать игры по языку в обратном порядке:
+
По степени нехватки места в строковых ресурсах под наши символы можно грубо отсортировать игры на языках Восточной Азии в следующем порядке:
  
# Китайский (отношение знаков в нормальном тексте – 1/4).
+
''Китайский'' – мои исследования, основанные на собственном переводе различных статей с китайского на русский язык, дают  оценку примерного отношения знаков в нормальном тексте – 1 иер./4 буквы. Для других европейских языков, я полагаю, будет сохраняться примерно такое же соотношение.
# Корейский, не знаю языка, но тут очевидно сильное влияние Древнего Китая, и нынешний хангыль это вроде как, если бы китайцы вписывали бы звучание идеографа на пинь-инь или чжу-инь в квадрат вместо этого идеографа. Только корейцы как фонетико-лингвистическая мононация легко могут себе это позволить (15 век), а китайцы в силу внутренних, мягко говоря, очень существенных фонетических различий – уже не могут. Поэтому, предположу, что по длине строк корейский практически информационно эквивалентен китайскому. Да и в Южной Корее еще в KSC-кодировке остались тысяч 5 иероглифов.
 
# Японский. Все таки слогов у них побольше, плюс часто идет с кандзи еще и хирагана, причем на один кандзи в среднем идут два слога хираганы (тоже двухбайтовые символы) – это уже намного лучше, чем в китайском.
 
  
Однако замена одного азиатского символа двумя нашими все равно не снимает проблема дефицита знакомест в строке. И здесь начинается виртуозная работа переводчика игры. Нужно знать игру досконально, максимально используя хоть какие-то отдаленные синонимичные формы, ну как самый крайний вариант наиболее общеупотребительные аббревиатуры, ставшие в современном новорусском языке практически самостоятельными словами. Крайнюю сложность представляют очень распространенные двухиероглифные сочетания в кит играх. Пример: в [[TunTown]] – 香蕉 – из списка предметов это конкретно банан, чтоб было понятно БА-НА-Н, а по опыту перевода [[Colonial Project]] стало ясно, что если эти однотипные сгруппированные названия идут в меню, то они все будут иметь заведомо одинаковую длину и место между ними будет разделяться только одним нулевым байтом, вот так. А эквивалента банану просто нет, потому что он – БАНАН, или ФР-УК-Т, в общем, такие ситуации возможны и нужно уметь из них выходить. И такой прием (и возможно не только для растровой графики) есть, китайское побеждается китайским – в переводе Colonial Project в некоторых, казалось уже безвыходных ситуациях, когда при перерисовке графических надписей просто не хватало места, [[Участник:Vladimir 777|Vladimir 777]] предложил использовать те же пиктограммки игры, что соответствуют или жестко связаны с переводимыми надписями, а пиктограммки в играх – ну они всегда есть. Так что знайте – любой перевод текстов азиатской игры это, прежде всего, практически ручная, кропотливая работа, которую я не побоюсь назвать искусством.  
+
''Корейский''– не знаю языка, но тут очевидно сильное историческое влияние Древнего Китая, и нынешний хангыль – это вроде как, если бы китайцы вписывали звучание идеографа на пиньинь или чжуинь в квадрат вместо этого идеографа. Только корейцы как фонетико-лингвистическая мононация легко могут себе это позволить (с 15 века), а китайцы в силу внутренних, мягко говоря, очень пёстрых фонетических различий, – уже не могут. Поэтому, предположу, что по длине двухбайтовых строк корейский язык практически информационно эквивалентен китайскому. Да, и в Южной Корее ещё в KSC-кодировке остались около 5 тысяч иероглифов (ханьча). Но бывает, в корейском языке встречаются ещё и чисто корейские слова некитайского происхождения, и они многосложные (2–3 слога на хангыле). Отсюда вывод: в ресурсах игр на корейском языке должно быть немного побольше свободного места для алфавитов однобайтовой перекодировки.
  
Типы азиатских (тайваньских, гонконгских, корейских…) ДОС-игр по технической реализации перевода основной текстовой информации (расположены по возрастанию степени сложности):
+
''Японский'' – всё-таки количество фонем в словах и предложениях в этом языке, по сравнению с китайским, побольше будет, плюс часто в японских строках идёт вместе с кандзи ещё и хирагана (корневая часть – кандзи, суффиксальная – кана). При транскрипциях на один кандзи, в среднем, идут два слога хираганы (канна – тоже двухбайтовые символы) и это уже намного лучше, чем в китайском языке.
  
1. Текстовая информация содержится исключительно в графических ресурсах игры. Перевод просто перерисовывание ресурсов. Пример – [[KingKong10]].
+
Итак, вывод наиболее жёсткие ограничивающие рамки нам следует ждать от игр на традиционном или упрощённом китайском языке.
  
2. Текстовая информация содержится в виде шрифтовых псевдострок (пример – [[Galaxy Fleet]]). Кодированных строк нет, а эти псевдостроки напрямую берутся для брифингов и сообщений из псевдошрифтовых файлов 16х16. Т.е в шрифтовом файле идут символы просто также как и в выводимой строке. Перевод – просто перерисовывание файлов псевдошрифтов. Лучше парами неазиатских символов в иероглифическом знакоместе.
+
Однако замена одного азиатского символа двумя однобайтовыми всё равно не снимает проблемы дефицита знакомест в строке. И здесь начинается виртуозная работа переводчика игры. Нужно знать игру досконально, максимально используя хоть какие-то отдалённые синонимичные формы, ну, и как самый крайний вариант – наиболее общеупотребительные аббревиатуры, ставшие в современном новорусском языке практически самостоятельными словами. Крайнюю сложность представляют очень распространённые двухиероглифные сочетания в кит. играх. Пример: список предметов в игре [[TunTown]]香蕉 [xiang-jiao] – из списка предметов ясно, что это банан, чтоб было понятно, запишем тремя псевдопарами: БА-НА-Н_, а по опыту перевода игры [[Colonial Project]] стало ясно, что если такие однотипные сгруппированные названия идут в меню, то они все будут иметь заведомо одинаковую выровненную длину и место в двоичных данных между ними будет разделяться только одним нулевым байтом, вот так, просто вообще может не быть свободного места для расширения двухбайтовой сроки. И понятно, эквивалента банану просто нет, потому что он – БАНАН, или даже ФР-УК-Т_ (всё равно три пары символов), в общем, такие ситуации возможны, и нужно уметь из них выходить. Но один такой приём, возможно, и не только для растровой графики, но и для символов текстов – есть! Китайское побеждается китайским – в переводе игры [[Colonial Project]] в некоторых, казалось бы, уже безвыходных ситуациях, когда при перерисовке графических надписей просто не хватало места, ''Vladimir 777'' предложил использовать те же пиктограммки игры, что соответствуют или жёстко связаны с переводимыми надписями, а пиктограммки в играх – ну они всегда есть. Вместо иероглифа при перекодировке шрифта можно запросто нарисовать свою пиктограммку. Так что знайте, любой перевод текстов азиатской игры это, прежде всего, практически ручная, кропотливая работа, которую я не побоюсь назвать искусством.
  
3. Текстовая информация содержится в виде текстовых строк в одной из стандартных азиатских кодировок в ресурсах ехе-файла. Имеется обычный шрифт 16х16. Внутренней игровой перекодировки нет. Символы берутся напрямую из шрифта 16х16. Перевод – перерисовка части символов шрифта для пар неазиатских псевдосимволов и с соответствующей переводу перекодировкой строк а ехе– файле для того чтобы отображались уже перерисованные символы шрифта. Пытаюсь для этого делать удобный перекодировщик, пока получается неудобно, не могу выработать концепцию. Пример игры– [[ETIN]].
+
Типы азиатских (тайваньских, гонконгских, корейских…) ДОС-игр по технической реализации перевода и перекодировки для основной текстовой информации (расположены по возрастанию степени сложности):
  
Причем сама суть старых двухбайтовых кодировок (EUC-Extended Unix Code) основана на полной сочетаемости однобайтовых и двухбайтовых символов вместе в азиатском тексте. Т. е. последовательность байтов 31А14032А14033А14034h… должна движком игры (хотя для игры это не догма) выводиться как 1<ASIAN_MONOSPACE>2<ASIAN_MONOSPACE>3<ASIAN_MONOSPACE>4. Что я и видел в Colonial Project при вводе символов имени игрока. Это вообще позволяет тогда без длительной перерисовки символов перерисовать только маленький английский шрифт (который обязательно бывает в таких играх) и перекодировать строки напрямую в хекс-редакторе вводя только однобайтовые символы, что автоматически в два раза увеличит полезный размер строки относительно первоначального. Но опять же, если текстовый движок игры это поддерживает. Поскольку лат., греч. символы в начале неанглийского основного шрифта игры нарисованы как моноширинные квадратно-двухбайтовые.
+
1. Текстовая информация содержится исключительно в графических ресурсах игры. Перевод – просто перерисовывание ресурсов. Пример – игра [[KingKong10]].
  
4. Текстовая информация также содержится в виде текстовых строк в одной из азиатских кодировок в ресурсах ехе-файла. Но, шрифт 16х16 имеет в себе только используемые иероглифы и связующим звеном между строками стандартной кодировки в ехе-файле и выводом иероглифов на экран становится таблица перекодировки шрифта. Яркие примеры Colonial Project, TunTown. Число знакомест в таком случае резко сокращено по сравнению с вариантом без внутренней игровой перекодировки основного шрифта. Крайне удачным моментом в Colonial Project является то, что для русских двухбуквенный сочетаний отведено всего 672 знакоместа – это мало, но, как оказалось, не смертельно. Пришлось пожертвовать некоторыми мелочами, и перевод строк в aps0.exe недавно был удачно завершен. Это показывает, что такое небольшое количество – 672 знакомест уже достаточно для полноценного русского перевода. Да и для англификации игры заведомо хватает места. Там двухбуквенных сочетаний существенно меньше. В TunTown места в основном шрифте намного больше – более 2000. Это позволит группировать внутри русских пар псевдосимволов даже основные знаки препинания.
+
2. Текстовая информация содержится в виде шрифтовых псевдострок (пример – игра [[Galaxy Fleet]]). Кодированных строк нет, а эти псевдостроки напрямую берутся для брифингов и сообщений из псевдошрифтовых файлов с иероглифами размером 16х16 пикселов. Т.е в шрифтовом файле имеются строки с уже нарисованными и размеченными на абзацы символами. Перевод просто перерисовывание файлов псевдошрифтов. Лучше это делать парами неазиатских символов в иероглифическом знакоместе, поскольку есть ещё и графические рамки, ограничивающие размеры надписей у текстов игрового перевода.
  
Перевод только в спец приложении с подгрузкой таблицы внутренней перекодировки шрифтов и преобразование пар вводимых текстовых наших символов
+
3. Текстовая информация содержится в виде строк в одной из стандартных азиатских кодировок (BIG5, GB2312, ShiftJIS, KSC) в ресурсах ехе-файла. Имеется обычный шрифт 16х16 пикс. Внутренней игровой перекодировки нет. Символы берутся напрямую из шрифта  с размером символов 16х16 пикс. Перевод – перерисовка части символов шрифта для всех возможных сочетаний пар неазиатских псевдосимволов (8х16+8х16) и с соответствующей переводу перекодировкой строк в ехе-файле, для того чтобы отображались уже перерисованные псевдопары в символах игрового шрифта. Пример игры – [[The Heaven Sword and Dragon Saber]].
  
5. Самый худший вариант – нестандартная кодировка строк, примененная из разных корыстных побуждений. Тогда найти строки становится очень тяжело, но возможно. Далее их нужно раскодировать. Хотя, скорее всего, кодировка может быть и прямой по отношению к положению символа в основном шрифте. Например в Big5 первый символ кодируется как A140h а при таком подходе он в шрифте может идти под номером 0001, поскольку находится в начале. Таких примеров пока не встречал.
+
Причем сама суть старых двухбайтовых кодировок (они восходят к EUC-Extended Unix Code) основана на полной сочетаемости однобайтовых и двухбайтовых символов вместе в азиатском тексте. Т. е. последовательность байтов 31 А140 32 А140 33 А140 34h… должна движком игры (хотя для технической реализации игр это не строгая догма) выводиться как:
 +
1<ASIAN_MONOSPACE>2<ASIAN_MONOSPACE>3<ASIAN_MONOSPACE>4.  
  
Загадкой для меня остается игра [[Danger Zone]]. Строк в ехе-файле я не нашел. Даже откровенно растровые 16х16 иероглифы идущие в интро их тоже в текстовом виде не нашел в интро файле. Вероятно это графические ресурсы игры. Даже последовательно и посимвольно выводимая строка иероглифов в конце кампаний – для нее тоже ничего не нашел текстового. Будем дальше работать.
+
Это вообще позволяет тогда без длительной перерисовки символов перерисовать только маленький английский шрифт (который обязательно бывает в таких играх) и затем перекодировать строки напрямую в HEX-редакторе, вводя только однобайтовые символы, что автоматически в два раза увеличит полезный размер строки относительно первоначального. Но опять же, если текстовый движок игры это точно поддерживает. И ещё одно неудобство лат., греч. символы в начале неанглийского основного шрифта игры нарисованы как моноширинные квадратно-двухбайтовые. Это сильно сокращает место для строк при прямом перекодировании 1 иерогл./1 буква, поскольку на один иероглиф в информационном плане приходится около 4-х символов алфавитных языков.
  
В заключении хочу еще отметить азиатские [[Windows]] игры. Вроде, если есть Windows подразумевай есть и кодировка Unicode, но тогда тоже не исключены некоторые проблемы. Перекодировка будет только двух байтовая один к одному, а если используются системные ttf-шрифты, то и перерисовать уже будет  невозможно. Т.е править ttf смысла нет, поскольку потом замучаешься с хинтингом, а без хинтинга символы буду выглядеть по-уродски. Да и сами символы в Windows выводятся не моноспейсом, а с переменной шириной (неазиатские). Лишь бы хватало места под строки  в самом ехе-файле  при перекодировке один к одному. Но посмотрев игру [[Colonial Project 2]], а она вроде под Windows, я опять в ехе-файле увидел строки старой доброй кодировки Big5. Похоже, что не все так плохо…
+
4. Текстовая информация также содержится в виде текстовых строк в одной из азиатских кодировок в ресурсах ехе-файла. Но, шрифт 16х16 имеет в себе только используемые иероглифы и связующим звеном между строками стандартной кодировки (BIG5) в ехе-файле и выводом иероглифов на экран становится таблица перекодировки шрифта. Яркие примеры – игры: [[Colonial Project]], [[TunTown]]. Число знакомест в таком случае резко сокращено по сравнению со стандартным вариантом кодировки без внутренней игровой перекодировки основного шрифта. Крайне удачным моментом в [[Colonial Project]] является то, что для русских двухбуквенных сочетаний отведено всего лишь 672 знакоместа этого было мало, но, как оказалось, не смертельно. Пришлось пожертвовать некоторыми мелочами, и перевод строк в основном файле той игры – aps0.exe недавно был удачно завершен. Это показывает, что даже такое небольшое количество – 672 знакомест уже достаточно для полноценного русского перевода с использованием описываемого тут  метода формирования пар всех возможных сочетаний псевдосимволов по формуле 16х16=(8х16+8х16). Да и для англификации этой игры заведомо хватает места 26х26=676, ведь двухбуквенных сочетаний для английского языка существенно меньше. В игре TunTown места в основном шрифте намного больше – более 2000 символов. Это позволит группировать внутри русских пар сочетаний псевдосимволов даже основные знаки препинания и служебные пиктограммки.
  
 +
Перевод таких игр возможен только в спец. приложении с подгрузкой таблицы внутренней перекодировки шрифтов и таблицей преобразования пар вводимых текстовых однобайтовых русских или английских символов.
 +
 +
5. Самый худший вариант – нестандартная кодировка строк, применённая из разных корыстных побуждений. Тогда найти строки становится очень тяжело, но возможно. Далее их нужно раскодировать. Хотя, скорее всего, кодировка может быть и прямой по отношению к положению символа в основном шрифте. Например, в Big5 первый символ (азиатский пробел) кодируется как A140h а при таком подходе он в шрифте может идти под номером 0001, поскольку находится в начале. Таких примеров я пока не встречал.
 +
 +
Загадкой остаётся игра [[Danger Zone]]. Строк в ехе-файле не найдено. Даже откровенно растровые 16х16 иероглифы, плавно идущие в интро – их тоже в текстовом виде я не нашёл в интро-файле. Вероятно это сжатые графические ресурсы игры. Даже последовательно и посимвольно выводимая строка иероглифов в конце кампаний этой игры – для нее тоже ничего не найдено текстового. Будем дальше работать.
 +
 +
В заключение хочу ещё отметить азиатские игры на платформе [[Windows]]. Казалось бы, вроде, если есть Windows – подразумевай есть и кодировка Unicode, но тогда тоже не исключены некоторые проблемы. Перекодировка будет только двух байтовая один к одному, а если используются системные ttf-шрифты, то и легко перерисовать их будет уже невозможно. Т.е править ttf-файлы смысла нет, поскольку потом замучаешься с хинтингом, а без хинтинга символы будут выглядеть весьма неряшливо. Да и сами символы в Windows выводятся не моноспейсом, а с переменной шириной (неазиатские). Лишь бы хватило места под строки в самом ехе-файле при перекодировке один к одному. Но посмотрев игру [[Colonial Project 2]], а она издана именно на платформе Windows, я опять в ехе-файле увидел строки старой доброй кодировки BIG5. А иероглифы в этой игре используются свои собственные, растровые. Похоже, что не всё так плохо…
 
[[Категория:Мастерская]]
 
[[Категория:Мастерская]]

Версия 07:59, 12 октября 2013

Creative Commons: некоторые права защищены
WERTA — автор этой статьи. Вы можете свободно копировать и распространять данный текст, но только при соблюдении условий, что оригинальное авторство и лицензия будут сохранены в производной работе. Текст распространяется под лицензией Creative Commons Attribution-Share Alike (by-sa) 3.0. Разрешается добавлять примечания и исправлять опечатки; остальные действия не рекомендованы.

Перевод азиатской ДОС-игры с двухбайтовой кодировкой наиболее оптимально может быть выполнен путём графической перерисовки в растровых шрифтах (например, с разрешением в 16х16 пикс.) с заменой квадратных азиатских символов всеми возможными сочетаниями пар русских (либо лат.) узких прямоугольных псевдосимволов (8х16+8х16), с последующей перекодировкой строковых ресурсов для их правильного отображения.

Конечно, для особых случаев можно и триплеты букв использовать, но, я думаю, это нереально, поскольку не все наши буквы удастся по три записать в растре 16х16. М, Ы, Ю с трудом вписываются в растр 8х16 пикс.

По степени нехватки места в строковых ресурсах под наши символы можно грубо отсортировать игры на языках Восточной Азии в следующем порядке:

Китайский – мои исследования, основанные на собственном переводе различных статей с китайского на русский язык, дают оценку примерного отношения знаков в нормальном тексте – 1 иер./4 буквы. Для других европейских языков, я полагаю, будет сохраняться примерно такое же соотношение.

Корейский– не знаю языка, но тут очевидно сильное историческое влияние Древнего Китая, и нынешний хангыль – это вроде как, если бы китайцы вписывали звучание идеографа на пиньинь или чжуинь в квадрат вместо этого идеографа. Только корейцы как фонетико-лингвистическая мононация легко могут себе это позволить (с 15 века), а китайцы в силу внутренних, мягко говоря, очень пёстрых фонетических различий, – уже не могут. Поэтому, предположу, что по длине двухбайтовых строк корейский язык практически информационно эквивалентен китайскому. Да, и в Южной Корее ещё в KSC-кодировке остались около 5 тысяч иероглифов (ханьча). Но бывает, в корейском языке встречаются ещё и чисто корейские слова некитайского происхождения, и они многосложные (2–3 слога на хангыле). Отсюда вывод: в ресурсах игр на корейском языке должно быть немного побольше свободного места для алфавитов однобайтовой перекодировки.

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

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

Однако замена одного азиатского символа двумя однобайтовыми всё равно не снимает проблемы дефицита знакомест в строке. И здесь начинается виртуозная работа переводчика игры. Нужно знать игру досконально, максимально используя хоть какие-то отдалённые синонимичные формы, ну, и как самый крайний вариант – наиболее общеупотребительные аббревиатуры, ставшие в современном новорусском языке практически самостоятельными словами. Крайнюю сложность представляют очень распространённые двухиероглифные сочетания в кит. играх. Пример: список предметов в игре TunTown– 香蕉 [xiang-jiao] – из списка предметов ясно, что это банан, чтоб было понятно, запишем тремя псевдопарами: БА-НА-Н_, а по опыту перевода игры Colonial Project стало ясно, что если такие однотипные сгруппированные названия идут в меню, то они все будут иметь заведомо одинаковую выровненную длину и место в двоичных данных между ними будет разделяться только одним нулевым байтом, вот так, просто вообще может не быть свободного места для расширения двухбайтовой сроки. И понятно, эквивалента банану просто нет, потому что он – БАНАН, или даже ФР-УК-Т_ (всё равно три пары символов), в общем, такие ситуации возможны, и нужно уметь из них выходить. Но один такой приём, возможно, и не только для растровой графики, но и для символов текстов – есть! Китайское побеждается китайским – в переводе игры Colonial Project в некоторых, казалось бы, уже безвыходных ситуациях, когда при перерисовке графических надписей просто не хватало места, Vladimir 777 предложил использовать те же пиктограммки игры, что соответствуют или жёстко связаны с переводимыми надписями, а пиктограммки в играх – ну они всегда есть. Вместо иероглифа при перекодировке шрифта можно запросто нарисовать свою пиктограммку. Так что знайте, любой перевод текстов азиатской игры это, прежде всего, практически ручная, кропотливая работа, которую я не побоюсь назвать искусством.

Типы азиатских (тайваньских, гонконгских, корейских…) ДОС-игр по технической реализации перевода и перекодировки для основной текстовой информации (расположены по возрастанию степени сложности):

1. Текстовая информация содержится исключительно в графических ресурсах игры. Перевод – просто перерисовывание ресурсов. Пример – игра KingKong10.

2. Текстовая информация содержится в виде шрифтовых псевдострок (пример – игра Galaxy Fleet). Кодированных строк нет, а эти псевдостроки напрямую берутся для брифингов и сообщений из псевдошрифтовых файлов с иероглифами размером 16х16 пикселов. Т.е в шрифтовом файле имеются строки с уже нарисованными и размеченными на абзацы символами. Перевод – просто перерисовывание файлов псевдошрифтов. Лучше это делать парами неазиатских символов в иероглифическом знакоместе, поскольку есть ещё и графические рамки, ограничивающие размеры надписей у текстов игрового перевода.

3. Текстовая информация содержится в виде строк в одной из стандартных азиатских кодировок (BIG5, GB2312, ShiftJIS, KSC) в ресурсах ехе-файла. Имеется обычный шрифт 16х16 пикс. Внутренней игровой перекодировки нет. Символы берутся напрямую из шрифта с размером символов 16х16 пикс. Перевод – перерисовка части символов шрифта для всех возможных сочетаний пар неазиатских псевдосимволов (8х16+8х16) и с соответствующей переводу перекодировкой строк в ехе-файле, для того чтобы отображались уже перерисованные псевдопары в символах игрового шрифта. Пример игры – The Heaven Sword and Dragon Saber.

Причем сама суть старых двухбайтовых кодировок (они восходят к EUC-Extended Unix Code) основана на полной сочетаемости однобайтовых и двухбайтовых символов вместе в азиатском тексте. Т. е. последовательность байтов 31 А140 32 А140 33 А140 34h… должна движком игры (хотя для технической реализации игр это не строгая догма) выводиться как: 1<ASIAN_MONOSPACE>2<ASIAN_MONOSPACE>3<ASIAN_MONOSPACE>4.

Это вообще позволяет тогда без длительной перерисовки символов перерисовать только маленький английский шрифт (который обязательно бывает в таких играх) и затем перекодировать строки напрямую в HEX-редакторе, вводя только однобайтовые символы, что автоматически в два раза увеличит полезный размер строки относительно первоначального. Но опять же, если текстовый движок игры это точно поддерживает. И ещё одно неудобство – лат., греч. символы в начале неанглийского основного шрифта игры нарисованы как моноширинные квадратно-двухбайтовые. Это сильно сокращает место для строк при прямом перекодировании 1 иерогл./1 буква, поскольку на один иероглиф в информационном плане приходится около 4-х символов алфавитных языков.

4. Текстовая информация также содержится в виде текстовых строк в одной из азиатских кодировок в ресурсах ехе-файла. Но, шрифт 16х16 имеет в себе только используемые иероглифы и связующим звеном между строками стандартной кодировки (BIG5) в ехе-файле и выводом иероглифов на экран становится таблица перекодировки шрифта. Яркие примеры – игры: Colonial Project, TunTown. Число знакомест в таком случае резко сокращено по сравнению со стандартным вариантом кодировки без внутренней игровой перекодировки основного шрифта. Крайне удачным моментом в Colonial Project является то, что для русских двухбуквенных сочетаний отведено всего лишь 672 знакоместа – этого было мало, но, как оказалось, не смертельно. Пришлось пожертвовать некоторыми мелочами, и перевод строк в основном файле той игры – aps0.exe недавно был удачно завершен. Это показывает, что даже такое небольшое количество – 672 знакомест уже достаточно для полноценного русского перевода с использованием описываемого тут метода формирования пар всех возможных сочетаний псевдосимволов по формуле 16х16=(8х16+8х16). Да и для англификации этой игры заведомо хватает места 26х26=676, ведь двухбуквенных сочетаний для английского языка существенно меньше. В игре TunTown места в основном шрифте намного больше – более 2000 символов. Это позволит группировать внутри русских пар сочетаний псевдосимволов даже основные знаки препинания и служебные пиктограммки.

Перевод таких игр возможен только в спец. приложении с подгрузкой таблицы внутренней перекодировки шрифтов и таблицей преобразования пар вводимых текстовых однобайтовых русских или английских символов.

5. Самый худший вариант – нестандартная кодировка строк, применённая из разных корыстных побуждений. Тогда найти строки становится очень тяжело, но возможно. Далее их нужно раскодировать. Хотя, скорее всего, кодировка может быть и прямой по отношению к положению символа в основном шрифте. Например, в Big5 первый символ (азиатский пробел) кодируется как A140h а при таком подходе он в шрифте может идти под номером 0001, поскольку находится в начале. Таких примеров я пока не встречал.

Загадкой остаётся игра Danger Zone. Строк в ехе-файле не найдено. Даже откровенно растровые 16х16 иероглифы, плавно идущие в интро – их тоже в текстовом виде я не нашёл в интро-файле. Вероятно это сжатые графические ресурсы игры. Даже последовательно и посимвольно выводимая строка иероглифов в конце кампаний этой игры – для нее тоже ничего не найдено текстового. Будем дальше работать.

В заключение хочу ещё отметить азиатские игры на платформе Windows. Казалось бы, вроде, если есть Windows – подразумевай есть и кодировка Unicode, но тогда тоже не исключены некоторые проблемы. Перекодировка будет только двух байтовая один к одному, а если используются системные ttf-шрифты, то и легко перерисовать их будет уже невозможно. Т.е править ttf-файлы смысла нет, поскольку потом замучаешься с хинтингом, а без хинтинга символы будут выглядеть весьма неряшливо. Да и сами символы в Windows выводятся не моноспейсом, а с переменной шириной (неазиатские). Лишь бы хватило места под строки в самом ехе-файле при перекодировке один к одному. Но посмотрев игру Colonial Project 2, а она издана именно на платформе Windows, я опять в ехе-файле увидел строки старой доброй кодировки BIG5. А иероглифы в этой игре используются свои собственные, растровые. Похоже, что не всё так плохо…