flatz

Там есть таблица Unicode-букв, т.е. каждая буква представлена своим codepoint'ом (правда, оно не нужно совсем, видимо для отладки оставили), и кроме этого, каждая такая буква содержит еще и указание, какой координате и шрифту она принадлежит. В текстах же указываются не codepoint'ы, а индексы координат, а в шапке блока - номер шрифта для букв, при этом в одном тексте могут встречаться разные шрифты. По индексу координаты мы можем точно определить номер шрифта, который приходится на эту букву. Unicode должен поддерживаться полностью, с той лишь разницей, что в одном файле присутствуют только используемые символы. Я думаю, нет никаких ограничений на типографские знаки, ведь это такие же символы, как и любые другие. Кернинг задается сразу в символе текста (напомню, символ представлен координатой), для правильной установки кернинга нужно пробежаться не по координатам, а по кодам символов, представленных этими координатами, и составить пары символов, для которых посчитать кернинг и записать в каждый конкретный символ текста. Я думаю, не будет никаких проблем с правильным написанием наших шрифтов. Попозже, я сделаю утилиты для генерации шрифтов к этой игре. К сожалению, ничего не могу сказать об этом, т.к. никогда не играл в эту игру. :) Но ты можешь попробовать поискать эти слова в распакованных текстах и определить, где они и какие там шрифты.

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

А если переводчик захочет сделать больше строк, чем было в английском варианте? Например, если фраза на русском языке занимает больше места в строке, чем в английском, тогда лучше ее перенести на следующую строку, но может увеличиться количество строк. Может лучше тогда разделять отдельные строки сообщений чем-то таким?: Первая строка текста сообщения #1Вторая строка текста сообщения #1-------------------------------------------Первая строка текста сообщения #2Вторая строка текста сообщения #2 В общем, я пока реализую вариант, какой предложил Haoose с разделением отдельных сообщений, а там если что - переделаю. На notabenoid`е во всяком случае будет получше смотреться, я думаю.

Да, все так.

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

Починил перепаковщик mcd (пока без шрифтов, ибо для них нужны еще специальные утилиты, но это уже потом будет сделано), вновь были сложности с форматом - узнал новые нюансы, так что теперь даже с японскими текстами все нормально, выложу завтра днем. Теперь вопрос - нужно ли переносить идентификаторы в отдельный файл, а текст сам в другой? В английской версии 8 шрифтов, их номера: 0 2 3 6 7 8 9 10 Шрифты игры из _us файлов (первое число до подчеркивания означает номер шрифта): http://www.sendspace.com/file/pv2wam Извиняюсь за многочисленные дубли, не было времени просмотреть и отсеять, ибо каждая текстура шрифта была сгенерирована отдельно. Загрузил обновленный пакет утилит (mcd с поддержкой перепаковки текстов с оригинальными шрифтами). Также там присутствует исправленный charsetgen. Следует иметь ввиду, что экспортированные тексты могут отличаться от тех, что были сделаны предыдущей версией. Это связано с исправлением группировки по номеру шрифта для основных символов и пробела (знаю, что проявлялось на японских текстах).

Namynnuz Пока даже не могу сказать ничего определенного, но по ходу данные я теперь обработал нормально, гоняю тесты. По всей видимости, коды в текстах имеют разный формат, а следовательно, и разное количество байт для хранения. Есть комплексные коды, состоящие из 4 байт, есть обычные коды, состоящие из 2 байт. newline(-32768)space(-32767, font_id)color_start(-32762, color_id?)color_end(-32761)unk_32760(-32760, ???)button?(-32765, button_id)superscript_start(-32759)superscript_end(-32758) Вроде бы так, но там еще есть другие коды, если мне память не изменяет. И есть также положительные коды (это вроде как иконки или цифры, в общем что-то такое). По поводу полей в шапке блока: num_characters - это на самом деле num_printable_characters (число печатаемых символов, включая код пробела), а следующее за ним поле - это num_characters (общее число символов, включая коды). Так вот, если посчитать количество кодов, то оно как раз совпадет с разницей общих и печатаемых. Namynnuz Спасибо, нашел твою строку: [c:-32759/][f:4]CIA[c:-32758/] (ID=396079937) Фуф, теперь файл пересобирается нормально (правда, пока без текстовых блоков), завтра их буду делать...

Так, распаковал все dat/dtt/mcd, что были в китайском релизе, только с оригинальной версии игры. Посмотрел, там в двух файлах ui_option_us и тот же файл в dlc папке, присутствует эта непонятная пока штука... надо разбираться, ведь тут нет японского языка... Посмотрел в игре в опции, как эти штуки смотрятся - по всей вероятности, это не коды, а тоже символы... надо их как-то к символам причислять. Буду думать. Вроде разобрался, попробую погонять тесты.

Да я даже не имею понятия, что это, ибо на японском не шпрехаю. В японском их бывает либо 1, либо 4 (так в шапке указано), а на самом деле 5... Ну хотя может в других языках такой нудятины нет, но хотелось бы понять... К сожалению, не всегда 4 =( Вот встретил 7... Тогда даже не знаю, как хак придумать, ведь от него зависит, сколько байт данных нужно прочитать, чтоб потом их и записать... Можно конечно, попробовать считывать, пока не встретился следующий блок, но не нравится такой костыль. Посмотрел некоторые файлы из разных языков - там вроде бы такого нет... Наверное, забью, а то так никогда не доделаю.

Не знаю, я тесты провожу только на нескольких MCD, в принципе, можешь сам посмотреть у всех mcd. Из того, что я встречал, около 5-6 различных шрифтов. Жесть какая-то, думал с форматом все покончено, ан нет, в японских текстах (не знаю, только лишь в них или нет) есть еще какие-то коды (больше одного, в отличии от остальных текстов) после основных фраз... И пока что-то не пойму, как их правильно парсить, кол-во не совпадает, на 1 больше...

Извиняюсь, был занят работой на этих выходных. Сегодня допилил парсер текстов (тех, что распаковываю скриптом), теперь можно обратно собирать, в связи с этим допилил charsetgen и начинаю работать над перепаковкой в mcdtool. Там еще со шрифтами надо вопрос решить, как их экспортировать и потом обратно импортировать...

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

Haoose Вечером сделаю, сейчас уже уходить надо. Я загрузил новую версию пакета утилит. Собственно, уже можно заниматься текстами. Теги для групп символов с одинаковым шрифтом выглядит так: [f:ID]TEXT[/f:ID], если тега не имеется, значит используется шрифт по умолчанию (указан в шапке, где идентификатор сообщения: ###MESSAGE_ID:eID:fID###, вот fID - это идентификатор шрифта по умолчанию), сделано для упрощения вида текстов, где везде один и тот же шрифт. Перепаковку в mcdtool пока отключил, т.к. ее еще не исправил (не добавил поддержку нескольких записей блоков) - вечером постараюсь доделать. В mcdtool есть поддержка алгоритма сжатия DXT, т.е. она умеет перекодировать текстуры в A8R8G8B8 формат из DXTn. Поэтому теперь появилась возможность экспортировать отдельные текстуры глифов и генерировать цельную текстуру отдельного шрифта (используйте соответствующие команды glyphs и fonts; для их работы нужно указать папку, где лежит файл, именем которого является ID текстуры шрифта). Упс, забыл новые строки добавить. Кто скачал ранее - загрузите заново, исправил ошибку. Примеры текстов: ###1591061390:e0:f3###I must admit, I once thought of groups likeyours as opportunists -- enablers of war.###1884584454:e0:f3###Yes, [f:9]tovarich[/f:9]!###1531809634:e2:f6###LQ[c:16461:0/][c:16471:0/][c:16467:0/]I

Да распаковка/упаковка еще два дня назад сделана. В принципе, мне все эти неизвестные значения не нужны для упаковки, т.к. я делаю перепаковку, беру оригинальный файл и просто генерирую наши блоки с текстом вместо оригинальных. Осталось лишь привести экспортированные тексты в удобный вид, сейчас кое-что еще проверю (хочу проверить, внутри записей/блоков имеются ли символы с разными шрифтами или с одним; очень надеюсь, что они там всегда одинаковые, тогда можно отбросить теги для отдельных групп символов и задавать шрифт в шапке текста), вечером планирую, если успею, выложить утилиту. --- К сожалению, могут встречаться разные, значит без тегов никак... Например, в ckmsg_p230: font_id в записи указывает на шрифт #3 (видимо, это поле указывает на первый шрифт, либо на наиболее распространенный среди символов текста в блоках данной записи). А в тексте вот: ###1884584454:0###Y(3)e(3)s(3),(3) t(9)o(9)v(9)a(9)r(9)i(9)c(9)h(9)!(3)

Последнюю таблицу я тоже понял, а вот про несколько записей для отдельного message не знал, спасибо. Переделал эту часть скрипта, теперь будут выводиться несколько записей на сообщение, если имеются, теперь нужно перепаковку переделать. Кстати, PS3 версия игры хранит текстуры в GTF без swizzle (по крайней мере, на тех текстурах, где я смотрел), а вот в X360 версии вроде как есть. Вот это пока не знаю что, встречал единицы тоже, посмотри в ui_core_us, вот лог (unk1 - это как раз твой se_dummy): Разобрался, это индекс записи в сообщении. unk3, по всей видимости, тоже какой-то монотонно возрастающий индекс, правда, не пойму, почему он начинается с трех. Хотя нет, не монотонно возрастает... Иногда пропускаются индексы, а в ckmsg_codec_1st.mcd начинается с 1.

Я всегда работаю с utf-8, не понял, с ним тоже косяки? Свою утилиту планирую доделать на выходных, если управишься быстрее - еще лучше, только скажи заранее, чтоб я зря время не терял.

Дык вот в чем и дело, что нет никаких умолчаний, можно конечно фиксировано задать, например, 3 шрифт, т.к. он наиболее популярный, но как-то не знаю уж прям... не очень кошерно. А по поводу второго - если я правильно понял, то такое не сделать, ибо как потом осуществить соответствие при обратной сборке? Скрипт ж должен как-то определить, какому численному значению соответствует.

Так, что-то я даже не знаю, как поудобней сделать формат выходного текста, есть идеи? Допустим, у нас есть две строки текста: Допустим, что заглавные буквы отрисовываются шрифтом #1, маленькие - шрифт #2, а знаки - это служебные символы. Как лучше представить это в тексте, чтоб удобней было редактировать и чтоб потом правильно назад сконвертировать? 1. Можно обозначать тегами: Здесь в квадратных тегах указывается индекс шрифта, а внутри тега - сам текст, а в фигурных скобках внутри - служебные символы, например, иконки. 2. Либо через маркеры: Тут квадратные теги означают маркер, который включает заданный в нем шрифт, который будет отрисовывать текст, пока не будет встречен следующий маркер, либо пока не будет встречен конец блока. Может еще какие идеи получше есть?

В тех файлах, какие я смотрел, текстуры тупо в DXT5 без DDS бошки. Так что все с этим ок) Разве что только свиззлинг возможно есть.

Да конечно, я уже писал выше, что достаточно переименовать программу, добавив суффикс _be.

Пока нет, ибо я хочу сменить выходной формат текстов. Т.к. у нас теперь появились ID шрифтов для букв, я их пока указываю в скобках, например: M(1)i(1)c(1)r(1)o(1)s(1)o(1)f(1)t(1) W(2)i(2)n(2)d(2)o(2)w(2)s(2) - строка Microsoft со шрифтом #1 и рядом Windows со шрифтом #2 Но сами видите, что это не очень удобно для перевода, поэтому я хочу преобразовывать группы одинаковых ID в теги, в которых уже будут слова: [1]Microsoft[/1] [2]Windows[/2] Я думаю так будет гораздо удобнее. Плюс, в теги можно будет заключить служебные коды. Для этой реализации мне нужно написать еще некоторый код, чем я и займусь чуть попозже. Как будет готово, выложу утилиту и сможете начинать переводить. Потом нужно будет подумать с тем, как быть с текстурами отдельных шрифтов в MCD. Ну это уже не так важно.

Нижняя таблица - это какие-то индексы сообщений и их идентификаторы, а еще оставшаяся неизвестная - это таблица стилей. То число, что повторялось (39), не всегда одинаковое. Ему соответствует значение float'а в таблице стилей. Пока не знаю, что это. Уже нашел, это высота строки. Объединил символы каждого стиля в свою текстуру: http://www.sendspace.com/file/fvt4kd Стиль правильнее бы назвать font :)

Вот нарезал отдельные символы с их стилями: http://www.sendspace.com/file/mu5omi Именуются так: КОДСТИЛЯ_КОДСИМВОЛА.dds UPD: перезалил У меня появилась мысль, что размытые символы - это специальная текстура distance field для улучшения качества текста при масштабировании: Но надо проверить. :)

Пробовал упаковать сначала, но ошибся с файлом (тот, что используется - берется из папки с DLC, а не из корневой), поэтому ничего не увидел, но перепакованный CPK загрузился нормально, правда паковал минут 5 (без компрессии) - файл вышел 2 гигабайта... Второй раз решил не перепаковывать, а сразу положить в папку, на всякий бросил файл во все три. Тут еще такая проблема - одинаковым символам может соответствовать несколько координат, теперь я понял, почему они сделали такую индексацию через координаты. Индекс координаты определяет уникальный символ - т.е. символ с уникальным кодом и уникальным стилем, но бывают символы с таким же кодом, но с другим стилем, они соответственно имеют другие координаты. А в тексте же индексация идет как раз по этим уникальным индексам координат, т.е. получается текст задается массивом букв с определенными стилями. Надо придумать, как лучше это выводить в текстовый файл... Обычно игры используют теги для стилей, а тут вот так сделано, не очень удобно для нас... И потом еще проблема встает - как рисовать шрифты, ведь стилей может быть несколько на каждый символ, надо, как минимум, смотреть на оригинальные текстуры шрифтов и рисовать похожие, выгр[censored] оригинальные стили и присваивать символам с нашей текстуры эти стили... Собственно, поэтому наверное и буква Z такая на показанном скриншоте - т.к., я выбираю первую попавшуюся координату символа по его коду, то видимо попался символ с отличным от обычного стилем. Значит еще нужно учитывать, что могут быть одинаковые коды символов.

Вот попробовал пока с оригинальным шрифтом: