flatz

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

Снова обновил пакет утилит: - mcdtool теперь также выводит вторую компоненту символа в тексте (кернинг?) в файл текстов (для служебных символов), это пригодится для последующей сборки; - новая утилита charsetgen генерирует файл с таблицей символов, имеющихся в распакованных текстах в указанной директории (может понадобиться для генератора шрифтов BMFont, чтобы выбрать только используемые символы); - новая утилита fontcropper обрабатывает файл в текстовом формате BMFont, пробегается по указанной в файле таблице символов и генерирует UV-координаты на текстуре для каждого символа (пригодится при последующей сборке mcd). Примечание: Для создания BMFont-шрифтов к данной игре использовать следующие параметры (возможна корректировка в дальнейшем): Font smoothing: Yes Outline thickness: 0-2 Padding: 2 2 2 2 Spacing: 0 0 Equalize cell heights: Yes Width: 1024 Height: 512 Bit depth: 32 A, R, G, B: Glyph/Outline/Outline/Outline Font descriptor: Text Textures: tga - Targa Compression: None

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

Обновил пакет утилит: - Все утилиты принимают параметр команды, которую необходимо произвести; - При добавлении суффикса _be к имени файла утилиты включается поддержка big endian для форматов консольной игры (работает для dattool, mcdtool, wtbtool; bxmtool не нуждается в этой поддержке, т.к. формат BXM-файла всегда big endian); - Поддержка перепаковки для DAT/DTT-файлов (по всей вероятности, у этих двух форматов разное значение для выравнивания, а также в консольных версиях на паре тестируемых мной файлов не было выравнивания вообще); - Поддержка перепаковки для WTB-файлов (тоже непонятки с выравниванием, оно может различаться для типов текстур - например, TGA-текстуры используют меньшее значение для выравнивания, но надеюсь, что проблем не будет, если всегда использовать большее значение); - При перепаковке правка информационных полей для файлов осуществляется только при наличии этих файлов в исходной папке, в противном случае вся информация остается прежней; - mcdtool может выводить файл журнала с описанием всех разобранных структур в иерархическом виде. Планы: - Поддержка перепаковки для mcdtool.

Нет, как уже писал - занимаюсь пока работой для своего заказчика, свободного времени только нашлось утром на исправление этого бага и переписывания части кода. Т.к. не знаю пока, когда освобожусь, то надеюсь, что найдется кто еще, который сделает обратную запаковку. Вот приложил лог утилиты при разборе ckmsg_p230, где показаны все разобранные данные: http://www.sendspace.com/file/0y2o66 Как можно видеть, присутствуют еще несколько неизвестных значений, в том числе в таблице координат (совпадают с теми значениями, какие указаны в таблице unks2), а также в таблице unks3, связанной с самими текстами.

С этим все ок, просто мой скрипт при копировании кусков не делает блендинг, а тупо копирует как есть, поэтому они не накладываются с прозрачностью, а замещаются. =)

Обновил mcdtool, закрался один нехороший баг. UPD: Подумал, может то значение - это кернинг? Ведь нам известны все тексты, соответственно все пары символов и необязательно держать таблицу пар символов с кернингом отдельно, можно сразу хранить значение в каждом символе. Походу и правда он, вот текстуры с кернингом и без: http://www.sendspace.com/file/9f430v

Не знаю, не смотрел еще, возможно это тупо просто смещение после буквы до начала следующей.

Да, конечно можно, даже нужно...

Так я всю необходимую информацию уже описывал тут. Не уверен только за "старшую часть структуры", про которую ты говоришь, т.к. не очень понял, какую именно структуры ты имеешь ввиду. Как я уже писал, там есть таблица, отвечающая за координаты символов на текстуре, эти координаты представлены в виде UV-координат текстуры, поэтому нам нужно тупо взять u/v-коэффициенты, которые преобразовывают целочисленные пиксельные координаты (x,y) в UV-координаты (u,v): u_factor=1/texture_width, v_factor=1/texture_height, а далее тупо u=x*u_factor, v=y*v_factor, наоборот, я делал в обратном порядке. Только, если мне память не изменяет, нужно корректно округлять значения крайних пикселей, т.е. та координата, что меньше, должна быть округлена вниз, а та, что больше - вверх (вроде так, ну или наоборот). Текст кодируется просто - указываются индексы в этой таблице координат. Но там есть еще другая таблица - таблица кодов символов (codepoint), вот в ней содержится индекс символа из таблицы координат. Т.е. если ты хочешь узнать, какому коду символа соответствует символ с такой-то координатой, то смотришь в таблицу кодов символов, находишь тот, где индекс координаты совпадает и берешь индекс уже в этой таблице. Алгоритм конвертирования я представляю таким (скорее всего, его и использовали разработчики): берем кириллический шрифт, растеризуем его в общую текстуру, порядок расположения символов не так важен, далее проходимся по всем текстам, группируем линии в блоки символов (получается, что новая строка не входит в массив символов, а только лишь генерирует новый блок), в блоках символов выделяем все коды символов (codepoint), отсеиваем со всех блоков дубликаты кодов, создаем текстуру куска шрифта для данного текста, циклом перебираем все используемые коды и поочередно добавляем кусочек текстуры этой буквы из общей текстуры шрифта, генерируем u,v координаты из пиксельных координат на получившемся куске, записываем в таблицу координат, далее составляем таблицу кодов, пробегаясь опять по кодам символов, ищем соответствие в таблице координат, пишем его в структуру, а далее генерируем текстовые блоки - для каждого символа блока ищем соответствующий ему индекс в таблице координат, записываем в структуру и заполняем оставшиеся таблички в MCD (нижняя таблица вроде одинаковая, я не смотрел, что там, помимо кода текста). Кстати, как предлагал Thief1987 можно попробовать использовать одну общую текстуру на все тексты, так как возможно, что игра его съест тоже.

Какая помощь нужна с разбором ресурсов, если они разобраны уже? И почему нет смысла переводить, я тоже не пойму. Запаковать обратно 100% реально, китайцы же сделали. Просто нужно этим заняться, написать обратную утилиту, попробовать CPK перепаковать (кстати, никто так и не попытался?), у меня пока на это нет времени, возможно у кого-то найдется.

Я пока не занимался, куча дел своих по работе...

Залил на Яндекс.Диск: http://yadi.sk/d/ITWXXzuoFtZ7X По поводу скайпа - не, скайп сильно отвлекает от реальной работы, поэтому стараюсь там общаться только с теми, кого знаю лично.

Вот новая версия: http://www.sendspace.com/file/uapncd Теперь должна корректно выдергивать все блоки, так что текста может быть еще больше, чем раньше.

Да, действительно, я как-то упустил этот момент. Попозже выложу исправленную версию, где учитывается количество блоков. Спасибо! Консольные версии я тоже могу поддерживать, уже тестировал, правда в том релизе, что был ранее - не поддерживаются - надо пересобрать скрипты заново, изменив там тип endian'а.

Я тут подумал, что лучше заменить (ID) на %%%ID%%%, чтобы не париться потом с обратной заменой (если вдруг скобки с цифрами в оригинальных текстах тоже встречаются), а то может выйти неопределенность: http://www.sendspace.com/file/v183t8 Рекомендую использовать вот эту версию.

Haoose Ага, спасибо за список нерабочих. Посмотрю, когда буду свободен. Вот исправленная версия: http://www.sendspace.com/file/gbikn2 Прошу потестировать еще раз.

Да, я тоже думаю, но нужно подтверждение.

Последняя версия пакета утилит на текущий момент: http://www.sendspace.com/file/goorq0 (включает MCDtool). В текстах могут встречаться кодовые последовательности (число, заключенное в скобки) - это подстановки. На данный момент я не знаю все подстановки, встречаются как положительные, так и отрицательные коды. Было бы неплохо, если бы кто-нибудь занялся исследованием, что это такое... С положительными вообще какие-то странности, может это подстановки иконок или что-то такое. Вот, например, из ui_chapter.dat/messchapter.mcd: ###1821662545### DL(16461)STORY ###1501029907### R(16461)(16463)(16463)

Я же вышел писал, что в ev0000_us.mcd. Действительно. Фуф, пришлось сделать небольшой хак: http://pastie.org/private/mmxpxv7b8o2dt1lpejr9a Ждите скоро тексты/утилиту.

Жесть адская, формат предусматривает возможность "переворачивания" структуры. Вот спарсил нормально: http://pastie.org/private/ers1npzgmimbffkczb6oa Переворачиваю, когда встретился символ перевода строки, но я думаю, что это плохой подход. Надо подумать, может как-то иначе проверять можно. А теперь другой баг всплыл - после переворота теряется первый символ с новой строки.

Ага, видимо там формат другой совсем, поэтому неправильно обработалась табличка.

Да, спасибо, надеюсь поможет.

UPD: Забыл сказать, это все и ev0000_us.

Нужна помощь от тех, у кого есть игра под рукой. Во втором типе таблицы букв встретил какие-то странные комбинации кодов, возможно это подстановки. Вот пример: http://pastie.org/private/u2llcdneopfbm5nfv1pw В моих обработанных текстах встречаются скобки с цифрами - это коды, какие мне нужно заменить, например, для пробела такой код был 32767, поэтому, встретив его, я заменяю оный на пробел. 32768 - скорее всего, это символ перевода на новую строку. Мне нужно, чтобы вы нашли в игре некоторые такие сообщения, и желательно сняли скриншоты или рассказали, что там в них. Скорее всего, (1), (2) это подстановки, но нужно уточнить.