Форум Honyaku-Subs

Так-с... Недавно разобрал один формат, хотелось бы сохранить его где-нибудь в помощь потомкам Спасибо WinKi за направление

• все числа в тексте - шестнадцатеричные.
• если я пишу "usually", это значит, что во всех/многих случаях в моём файле там было именно это значение.
• [DW] - число типа DWord; [S] - последовательность символов (строка); [S8] - восемь символов; [US] - Unicode string (см. ниже)
• Прога для перевода будет выложена здесь: http://www.solelo.com/p4s

Entis CSX: Cotopha Image file
(Wanko to Lily, system\wanko.csx, 3 813 713 bytes)


где:

• Should be zero - поле должно быть нулём, иначе движок выдаст сообщение о неверном заголовке файла. Может быть, это версия, зарезирвированое поле, код расширения формата или ещё что-нибудь.
• Contents size - это размер всего файла, за исключением его заголовка (иными словами, это значение + 40 должно быть точно на 1 байт больше размера файла целиком).

CSX-файл состоит из секций. Их пять видов:

• image - собственно команды скрипта и текст. Самая большая секция.
• function - это таблица функций и, видимо, точек входа или ещё чего-то. Как раз то, где надо править сдвиги.
• global - не вдавался в детали, не влияет на возможность перевода.
• data - тоже самое здесь.
• linkinf - конкретно не знаю, что это такое, ибо в игре эта секция была пустой...

Секция имеет такой формат:

где:

• ID - вид секции (одно из пяти). Лишнее место заполняется пробелами (20, не нулями).
• Size - размер секции без учёта заголовка.

Некоторые секции ещё читают дополнительный [DW] или несколько.


Unicode string
В файле используется общий формат для всех строк, которые, кстати, все Юникод (кроме ID секций, которые ASCII). Здесь я его обозначаю [US]:

где:

• Character count - количество символов (не байт). Чтобы получить длину строки надо помножить это на 2.
• Unicode string - например, 0030 BF7D...

Linkinf section
Так как не интересовался этой секцией, могу сказать только то, что она имеет свой заголовок (в дополнение к обычному секционному):

Linkinf имеет две части, каждая из которых имеет своё количество "чего-то".


Data section
Тоже не самая интересная секция.

Примеры (Name 1 => Name 2):


Global section
Эта секция, опять же, не представляет особого интереса, ибо не влияет на перевод. Однако вот что о ней известно:

Очень возможно, что Unknown 2 является длиной ещё одной Unicode-строки.


Function section
А вот это самое интересное место. Здесь хранятся указатели внутрь секции image, поэтому тут нам и нужно фиксить сдвиги при изменении скрипта.

Секция состоит из двух частей. В первой хранятся просто смещения, во второй - таблица с именами и смещениями.
Все адреса в этой секции относительны секции image. То есть чтобы получить абсолютный адрес, нужно прибавить к ним адрес начала image (обычно 50).

Первая часть

где:

• Relative offset - относительныый адрес в секции image.

Вторая часть

где:

• Relative offset - относительныый адрес в секции image.

Image section
Сообщения выводятся двумя функциями: Talk и Mess. Функция HitretNewPage ждёт реакции юзера и выводит следующее сообщение (на новый экран).

Особенностью использования Talk и Mess является то, что Talk (видимо) всегда используется для вывода сообщений, а не речи, но не всегда ондо сообщение выводится только функцией Talk. Обычно сообщение делится так, что Talk выводит первые 26 символов (максимум, что умещается на экране в одной строчке), а всё остальное выводится функциями Mess (по всей видимости тоже по одной функции на одну строку).
Интересно, что любая длинная строка выводится нормально даже одной функцией. Не совсем понятно, зачем в скрипте они разбиваются таким образом.

В то же время Mess используется и для вывода речи (без начального вызова Talk). Разделить одно сообщение можно при помощи отлова HitretNewPage.


Порядок прохождения парсера по скрипту (это скрин RTF из аттача):




Теперь вкратце о каждой функции.

Talk

Mess

HitretNewPage

Этого достаточно для изменения строк.


Где и что изменять?
При изменении строки в секции image нужно изменить следующие места в CSX-файле:

• @38 - размер всего CSX-файлла без заголовка.
• "image" section:
• - @08 - размер секции;
• - длину Unicode-строки в самом скрипте.
• - подправить расстояния в коротких прыжках, см. ниже.
• "function" section:
• - изменить адреса в первой части секции;
• - сделать тоже самое во второй части.

Короткие прыжки

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

Например, есть функция IsGameClear, у которой расстояние записано здесь: [us] IsGameClear [w] [dw] distance (то есть 2 неизвестных байта после имени функции, затем смещение размера DWord). Тот же синтаксис имеют аналогичные функции: ChkFlagOn, ChkSelect и OnFlag.

Имена функций, как обычно, в Юникоде (для английских названий символ есть просто его код + 0x00 для 2-го байта).

Ещё один момент. Функции прыжков иногда могут ссылаться на специальный код, который в этом контексте тоже является прыжком. Этот код - один байт = 0x06 и следом за ним 4 байта расстояния дял прыжка: [b.] 0x06 [dw] distance. Так что такие "прыжки" тоже нужно отслеживать и подправлять.

Вообще, скрипты изобилуют прыжками - к примеру, в Yosuga no Sora всего 4 выбора, однако в самом скрипте находится аж 22 прыжка.


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

На этом всё.

_________________
Proger_XP aka p4s | Анимешные картинки »