Google подала заявку в Федеральное агентство по связи США с просьбой разрешить тестирование передачи данных на частотах 5,8 ГГц, 24,2 ГГц, 71-76 ГГц и 81-86 ГГц. Тесты планируется провести 13 ноября в пяти местах в Калифорнии. Вероятно, компания проверяет, как передаётся сигнал на местности с разным ландшафтом и застройкой.

Миллиметровый частотный диапазон 30-300 ГГц используется, среди прочего, в радиоастрономии и высокоскоростной радиорелейной связи. Возможно, со стороны Google это просто научные исследования, которые не планируется применять в коммерческих сервисах. Но есть вариант, что такую связь можно использовать в сети Google Fiber, которую компания проложила в нескольких американских городах и планирует расширять.

Миллиметровые частоты подходят для использования в городских условиях, в частности, для организации mesh-сети между абонентами на гигабитных скоростях (см. научные исследования на эту тему).

Такая связь работает в пределах прямой видимости между приёмником и передатчиком. Но если объединить в сеть много устройств, то можно покрыть достаточно большую область, где хотя бы несколько устройств всегда будут в пределах прямой видимости. Это может стать реальной альтернативой оптоволоконным кабелям, которые сейчас Google ведёт в дом каждого абонента.

Если предположить, что mesh-сеть создаётся на территории малоэтажной застройки, типичной для американского пригорода, то придётся, наверное, устанавливать передатчики на крышах домов. Впрочем, это всего лишь теоретические рассуждения. Судя по всему, никто подобные сети пока не строил, так что Google может стать первой такой компанией.

«Это может быть что угодно, от чего-то относительно небольшого масштаба, вроде дополнения для их существующей оптоволоконной сети, до чего-то большого, вроде покрытия целого города «облаком» беспроводной связи, — рассуждает Гарольд Фельд (Harold Feld), старший вице-президент некоммерческой организации Public Knowledge, которая занимается технологиями широкополосной связи, в комментарии агентству Reuters. — Если они смогут осуществить это, то получат потенциально очень инновационную систему передачи данных следующего поколения».

До появления лазерных дисков и облаков настоящие игры выходили на картриджах. Те, кто застал девяностые, наверняка помнят самые популярные в нашей стране игровые приставки Dendy (российский клон японской Famicom) и Sega Mega Drive. Если очень хочется «вернуться к истокам» — всегда можно запустить эмулятор. Но можно пойти и чуть дальше — а что, если покопаться в самой игре? Добро пожаловать в эму-сцену.

Эму-сценой называют сообщество энтузиастов, формирующееся вокруг той или иной приставки. Эти люди ковыряются в своей любимой платформе вдоль и поперек: выкладывают полные дампы картриджей (ROM’ы), придумывают способы для их модификации и добиваются порой самых необычных результатов. Самый распространенный пример — локализация игр. Но можно пойти и дальше. Как тебе история про чувака, который хакал ROM’ы игр для NES, заменяя мужских персонажей на женских? А что еще прикажешь делать, если его дочке хочется играть за девочек, а в Donkey Kong такой возможности не предусмотрено?

Краткий экскурс

Самым главным толчком, послужившим появлению ромхакинга, стала история с игрой Final Fantasy V в 1992 году. Японская компания Squaresoft решила не издавать игру в США, посчитав ее слишком сложной для западных игроков. С появлением эмуляции западные энтузиасты не согласились с японцами и не только сыграли в нее, но и выпустили первый любительский перевод образа картриджа. Официального же перевода на английский не было вплоть до переиздания FFV в конце 1999-го на PlayStation. Именно с перевода Final Fantasy V и появилась русская ромхакинг-сцена, это был дебютный проект группы «Шедевр» в 2001 году.

В 1994 году история отчасти повторилась и с Final Fantasy VI. На этот раз игра вышла в США (под названием Final Fantasy III), через несколько месяцев после релиза в Японии (1994 год). Однако локализация оказалась крайне неудачной: перевод всей игры был выполнен всего одним человеком (Тедом Вулси) в крайне сжатые сроки. Например, в этом переводе были выкинуты скрытые отсылки к дальнейшему развитию сюжета, а смысл одного из предложений был заменен на противоположный из-за неправильно понятого японского крылатого выражения (фраза, близкая по значению к «бизнес испарился», была воспринята Тедом как «бизнес пошел вверх»). Сам Тед оправдывает низкое качество его перевода тем, что ему приходилось делать текст максимально коротким, так как он не влезал в картридж, в то время как японский текст заведомо более компактный. Тем не менее недовольные официальным переводом фанаты с задачей помещения в ром близкого к оригиналу английского текста справились вполне успешно.

Формулируем условия задачи

Есть одно обстоятельство, которое делает ромхакинг одновременно сложнее и интереснее более популярного моддинга PC-игр. Разработчики современных игр для ПК часто поддерживают моддеров, создавая для них официальные инструменты и выпуская всю необходимую документацию. В случае с консольными играми очевидно, что разработчики никак не предусматривали последующую модификацию своих тайтлов. Поэтому при ромхакинге мы имеем бинарный файл и даже не знаем, по каким адресам и в каком формате хранятся нужные данные, а значит, изначально требуется действовать вслепую, на ощупь.

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

Рассмотрим самую распространенную цель ромхакинга — любительский перевод. Изменение шрифтов необходимо, если алфавиты исходного и конечного языка отличаются, например если нужно заменить латиницу на кириллицу. То же самое касается и перевода с японского на английский или русский.

No$gba — отладчик платформ GameBoy Advance и Nintendo DS

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

Перерисованный шрифт в тайловом редакторе YY-CHR. В данном примере перед каждым символом идут данные, отвечающие за его ширину

Абсолютно любые данные (а особенно текст) могут быть запакованы, и это может усложнить жизнь ромхакеру еще больше. В особенно запущенных случаях локализатору понадобится разобраться в языке ассемблера под конкретную платформу: если «на ощупь» никак не получается выяснить формат паковки данных, можно прибегнуть к дебаггингу для выяснения алгоритма распаковки. Но, поскольку у каждой платформы ассемблер свой, я рассмотрю общие для всех платформ приемы, доступные даже тем, у кого нет желания или возможности редактировать машинный код соответствующей игровой приставки.

Находим цель

Перед тем как выяснить, в каком формате хранятся нужные данные, надо сначала определить, по каким адресам они расположены. Если ты думаешь, что для того, чтобы найти расположение текста, нужно скроллить hex-редактор, то очень сильно ошибаешься. Дело в том, что кодировка текста не обязана быть стандартной. Например, латинской A может соответствовать абсолютно любое значение байта от 00 до FF. Поэтому, чтобы увидеть текст в hex-редакторе, сначала нужно скормить ему составленную таблицу кодировки символов. Только вот такую таблицу вряд ли получится сделать, пока точное расположение текста не будет найдено. Хотя определить его путем скроллинга в различных режимах тайлового редактора, в принципе, можно, все равно это долго и не гарантирует, что найдешь: формат шрифта опять же может быть произвольным, иногда тайловый редактор может и не поддерживать этот формат. Не говоря уже о том, что любые данные могут быть запакованы.

Translhextion — одна из ромхакерских утилит, которая позволяет искать текст в неизвестной кодировке, подбирая ее автоматически путем перебора вариантов. Напомню, что этот прием работает, только если алфавит кодирован по порядку, а текст не запакован

Тем не менее решение задачи по гарантированному нахождению всех нужных данных выглядит довольно просто. ПО для ромхакинга, которым нужно воспользоваться в первую очередь, называется корруптор. Его задача — временно испортить ром на определенном участке, запустить ром для проверки, а затем вернуть в исходное состояние. Опционально это может быть увеличение/уменьшение значений, случайные значения или заданные (последний вариант также полезен для определения кодировки текста, когда он будет найден).

Пример таблицы символов, в которой они идут не по порядку (реальный пример из Final Fantasy VI Advance для GBA). В данном случае автоматически выяснить местоположение и кодировку текста Translhextion не в состоянии, но их можно определить вручную при помощи корруптора

Например, для начала можно разбить текст на восемь участков и пройтись по каждому. Если несмотря на то, что некоторые данные в роме испорчены, шрифт и текст отображаются нормально, значит, этих данных на проверенном участке нет и мы можем пометить его как полностью проверенный и больше к нему не возвращаться. Если после порчи данных игра зависает, то, скорее всего, был затронут программный машинный код, а значит, пока что неизвестно, есть ли на этом участке, помимо программного кода, текст или шрифт. Чтобы это выяснить, нужно данный большой участок разбить на более мелкие и пройтись уже по ним, разумеется рекурсивно уменьшая размер исследуемых участков. Наконец, если мы видим, что текст или шрифт на этом участке испорчен, то можно будет сразу же сосредоточиться именно на нем и, постепенно уменьшая исследуемые интервалы, точно установить начало и конец интересующих данных.

Существует еще один способ найти текст. Он более быстрый, но не гарантирует результат и сработает, только если текст не запакован и алфавит закодирован упорядоченно, то есть, например, если a = 2D, то b = 2E, c = 2F, d = 30 и так далее. Можно для начала попробовать взять какое-либо не очень короткое слово, встречающееся в тексте игры, только строчными (или только заглавными) буквами, а дальше пусть самописное или готовое ПО пробежится по рому в поисках этого слова (256 – 26 = 230) раз. Если ничего найдено не будет, то я рекомендую не париться и просто воспользоваться корруптором.

Корруптор Ромкор.

Вносим изменения

Для редактирования шрифта или графики можно воспользоваться готовым тайловым редактором, но нужно быть готовым, что формат хранения шрифта/графики может оказаться экзотическим и/или сжатым. Тогда придется или самому писать редактор шрифта, или «перерисовывать» шрифт в hex-редакторе, произведя все расчеты вручную, или написать перекодировщик из BMP или PNG в необходимый формат.

При редактировании текста нужно учитывать, что по умолчанию любой замененный тобой кусок не должен быть длиннее оригинала. Как правило, это ограничение очень легко обойти за счет изменения поинтеров, которые в отличие от текста очень узнаваемы сразу же в hex-редакторе. Но если перевод не ограничивается главным меню и окном опций, то пересчитывать и редактировать их вручную, мягко говоря, не стоит: рассчитывать и изменять их нужно автоматически. Из уже готового ПО я могу порекомендовать для этих целей Kruptar. Используя подобный софт, можно комфортно делать перевод, совершенно не парясь о том, что если вносить корректировки в уже осуществленный перевод и длина отредактированного фрагмента текста изменится, то значения множества поинтеров сдвинутся. Kruptar или ПО с аналогичным функционалом полностью возьмет на себя постоянный пересчет и правку поинтеров.

Калькулятор поинтеров Kruptar позволяет практически забыть о технических деталях во время редактирования текста. Также поддерживает извлечение/вставку запакованного методом MTE текста. Можно обеспечить поддержку другого метода сжатия благодаря возможности написания к нему плагинов

Поинтеры можно увидеть в hex-редакторе невооруженным глазом

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

Один из просмотрщиков, реализованный на Flash

Для Final Fantasy V Advance HoRRoR сделал схожий просмотрщик, с описанием и скриншотом которого можно ознакомиться здесь, но он не выкладывает свой софт в паблик по непонятной для меня причине.

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

Например, если использовать Python, то достаточно всего лишь определить словарь, ключами которого являются символы, а их значения равны ширине этих символов в пикселях в соответствии с игровым шрифтом. Затем нужно, используя регулярное выражение, пробежаться по всему тексту, отдельно по символам каждой строки, посчитав таким образом ширину текущей строки и сравнивая с максимально возможным значением, записать в лог все случаи превышения лимита (если они есть). Если лог окажется не пустым, то нужно проверить все найденные им места с помощью графического просмотрщика.

Заключение

В статье кратко описан процесс базового ромхакинга c применением готового софта. Все, что требуется, — комп, эмулятор, ром, интерпретатор или компилятор любого подходящего языка по вкусу и голова. Если готовый софт отлично справляется с возникшими задачами, лучше идти по уже протоптанной другими людьми тропинке, вместо того чтобы ломиться через сугроб. Но и стесняться писать собственный софт не стоит. Например, отчаянно не хватает портов виндовых утилит — даже на romhacking.net в разделе UNIX всего лишь восемь софтин. Удачи!