riku.kh3, ну вообщем вот подписанный тем же родным кирком ~SCE и ~PSP либфонт, надеюсь не напортачил и должен работать...
По заголовку и размеру он ничем не отличается от оригинала. Тело же конечно уже другое 0x150 + 0x40, но подписано этим же родным кирком и заголовком.

Ах да, мой шрифт, который я выкладывал в предыдущем архиве, ловит кириллицу в юникоде и в однобайте. Так что можно использовать как двубайтную кодировку юникода, так и однобайтную win-1251 0xC0 = А.

А ты точно уверен, что шрифт именно jpn0.pgf? А то вдруг там какой-нибудь ltn12.pgf... как в Лунаре.

В общем шрифт должен подхватываться из папки disc0:/PSP_GAME/USRDIR/X9DULE/. Название самого шрифта не указывается в пути, его даже не видно при дампе памяти, он как-то странно там отбирается по непонятному механизму, но в дампе sceFont_Library виден шрифт kr0.pgf

В эмуляторе flash0 папочка с программой лежит и там шрифты, которые на PSP используются хранятся. Если в ней подменить jpn0.pgf, то соответственно всё тут же меняется.. да и как он по-другому может называться просто не представляю :scratch_one-s_head: kr0.pgf это что-то корейское, смею предположить.

ErikPshat, тебя не затруднит всё-таки проверить на реальной PSP модифицированный libfont? Неужели железу PSP пофиг, что путь к disc0:/ в мод. библе записан прямо тупо так в открытом виде, а не как до этого? :scratch_one-s_head:

Щас попробую всё-таки запилить в образ мод.либфонт и проверить.
Ну а путь складывается по тому адресу в памяти flash0:/font/. В оригинале то место забито нулями специально для этих нужд. А т.к. по тому адресу я уже прописал новый путь, то он уже не затирается. Это можно проверить сдампив память с модифицированным либфонтом.

ErikPshat, тогда это объясняет, почему на эмуляторе путь переписывается назад на flash0, и все это китайское мамбо джамбо с написанием своего модуля :D

riku.kh3, ну собсно проверил, всё работает. Подписанный и зашифрованный кастомный модуль отлично отрабатывает на PSP.
Только я шрифт туда подкинул свой Times New Roman сконверченный в ltn0.pgf - переименованный в jpn0.pgf.
Соответственно игра у меня японская и вместо шрифта я вижу прочерки, отображаются только английские слова и спец-символы типа - !?"

Вложение 10017 Вложение 10018

Снял дамп памяти, там то же всё чётко. Путь в памяти отображается в нужном месте и не затирается:


Ну и во вложении доказательства дампа памяти.

Кстати, я не понял, почему вдруг эмулятор использует шрифты из flash0, но так не должно быть. На эмуле так же должен либфонт отрабатывать и так же должен брать шрифт из образа.
Попробуй убрать из эмуля шрифт jpn0.pgf из папки совсем.

А может ты новый модуль не сохранил в образе игры? Или может шрифт туда забыл подкинуть?

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

Подписанный:Неподписанный:Что странно, китайское мамбо джамбо работает на одном из эмуляторов (ppsspp):
Но не работает на втором (jpcsp). Как на реальной PSP - тоже не знаю. :scratch_one-s_head:

riku.kh3, эмм, это китайское мамбо действительно чудо из чудес :D
Как они так умудрились сконвертировать такую библу, там я вижу после концовки файла идёт ещё куча мусора, больше, чем сам продуктивный код.
Выбрось эту шнягу подальше.

И не понятно, что это у тебя на первых скринах и всех остальных пытается грузиться flash0:/font/zh_gb.pgf
Этого шрифта нет ни в игре, нигде. Либо ты сам где-то подмешал это китайское чудо с моим модулем вперемешку.

ErikPshat, не, это эмулятор для своих системных нужд пытается и несуществующий шрифт добавить (там эмитация окошек для сейвов/загрузок где этот шрифт может использоваться, ввода текста и т.п.). Он вообще все существующие шрифты пытается грузить во всех играх.. :scratch_one-s_head: В образе там все чистенько - только твой libfont.prx заменен и jpn0.pgf рядышком с ним.

riku.kh3, я вижу у китайцев такой хитрый путь: ms0:/iso/open_ms0 :xDD:
Они наверное подумали, что путь сработает и откроется ms0 :D

Ага, и откуда они догадались такую строчку воткнуть ms0:/ISO/zh_gb.pgf

oldfont.prx - это вообще либа не от этой игры. То есть, как я понял, либа libfont.prx компилится только для одной игры, под которую она предназначена, на другой игре по идее она работать не должна. Это потому, что в самой либе прописано название игры, зашифрованное в заголовке ~SCE. В этом oldfont прописан заголовок от другой игры: А у твоей игры заголовок: Просто введи в поиске декриптованного модуля значение 22222JFDD и ты выйдешь на этот код.

Но у китайцев внутри файлов я вижу другой заголовок от какой-то другой игры. По идее такой файл не должен работать на чужой игре.

Все, понятно почему на эмуляторах с правильным libfont.prx шрифт не грузится откуда положено. :) Они попросту не используют libfont.prx вообще, вместо него там в самом эмуляторе грузится рутина. Попробовал заменить libfont.prx на пустышку забитую мусором, и оба эмулятора как ни в чем не бывало запустили игру:

Тут же и ответ на оба поста выше.

riku.kh3, ну на первых скринах я вижу, что вроде бы грузится disc0:/PSP_GAME/USRDIR/X9DULE/libfont.prx
Там кругом видно, что путь отрабатывает.
И шрифт должен браться оттуда же disc0:/PSP_GAME/USRDIR/X9DULE/jpn0.pgf

Ты посмотри внимательнее в логах, может наряду с другими шрифтами он грузится где-то в конце?

ErikPshat, на первых то скринах да, видно что 'вроде бы' грузится, но на самом деле эмуль определяет "что" это такое пытается грузится и скипает, перенаправляя на свой код рутины по работе со шрифтами. Логи я внимательно все пересмотрел - disc0:/PSP_GAME/USRDIR/X9DULE/jpn0.pgf не грузится 100%. Да и говорю, пустым файлом заменил libfont.prx в игре, а она все так же как ни в чем не бывало работает и шрифт все так же отображается.

То есть грубо говоря даже если libfont.prx и грузится, эмулятор его поверх своим кодом все-равно перезаписывает. Как то так, в общем. :scratch_one-s_head:

riku.kh3, ну ладно, тогда значит понятно, что нифига не понятно, почему эмуляторы подсовывают свои шрифты :D
В общем думаю проблему мы решили, ведь игру планируется запускать на PSP. И в общем всё на ней работает, как положено.

Ну а проблемы со шрифтами при сохранении - это уже из другой оперы.

Да, тут все отлично.

Проблем со шрифтами при сохранении не будет, если суметь существующие буковки по ширине уменьшать научиться. Для этого надо скорее всего сам pgf ковырять. :scratch_one-s_head: А так да, если колхозным путем пойти и перерисовать буквы перекидав их местами и вместо одной из них сделать пробел, то при сохранении будет каша отображаться.. ну и бонусом перенос слов, скорее всего, перестанет работать.

riku.kh3, вот посмотри, мне так кажется, что английский шрифт нормально отображается по ширине и не заметно двойных пробелов:


А у тебя почему-то диалоги отображаются широкими с большим пробелом:

ErikPshat, надпись 'Converted Edition' у тебя на скрине в обычной ascii кодировке с нормальным $20 пробелом, текст для таких системных сообщений берется из самого EBOOT.BIN.

А на втором скрине текст и пробелы в shiftjis 2-байтовой кодировке:
В самой игре если использовать в диалогах ascii с обычными $20 пробелами то игра будет крэшится при попытке сохраниться. То есть в идеале бы сократить ширину shiftjis буковок и пробела, чтобы они выглядели как обычно. :scratch_one-s_head:

riku.kh3, а, ну да, тупанул я мальца.

Получается нужно как-то Shift-JIS сконвертировать из TTF.
А в TTF можно подкорректировать пробел покороче с помощью редактора шрифтов, дома на компе валяется такой.
Это у Японцев в этой кодировке всегда расстояния такие, чтобы иероглифы не сливались, ну и другие символы языков так же отрисованы.

ErikPshat, с самим TTF я как только не игрался.. ширину уменьшать пробовал, в самой windows и любыми программами где этот шрифт используется как положено буковки уже становятся и shiftjis пробел в два раза меньше как надо.. но после конвертирования в pgf в самой игре совсем все не так.. Пробел как большим был так большим и остается, из ascii буквы если все глифы удалить - интервала вообще она перестает создавать.. а если из shiftjis символа все глифы удалить - в точности все до наоборот.. :unknw:

riku.kh3 добавил 08.05.2014 в 23:20
Скрины которые я выкладывал с русским текстом все в том же shiftjis'е и там никаких интервалов нет. То есть не статическая эта ширина, и должна быть где-то таблица ширины для каждого символа.

http://www.seiai.ed.jp/sys/text/java...jis_table.html

Я, когда над переводом ff3 работали, с этими шрифтами намаялся. Правка ttf по ширине ничего не даст. Ttf2pgf штука не идеальная, но это лучшая софтина из тех, что я нашёл. В самом pgf хранится битмап символов и таблица ширин, пожато это всё rle алгоритмом. К сожалению ни одной программы, которая бы умела напрямую править pgf, мне найти не удалось.
Можно попробовать такой костыль: использовать вместо ascii пробела что-то вроде • предварительно исправив этот символ в ttf.

Да, согласен. В переводе можно вместо пробела использовать любой международный символ, например знаки препинания беруться из общего набора международных шрифтов, такие как !?";:*#() и т.п.. Можно взять любой узкий малоиспользуемый знак и через редактор шрифтов TTF зачистить этот символ, либо перекопировать на его место пробел. Затем сконвертировать в PGF.

Но чую я, что там не только пробел используется в качестве служебного символа, могут попасть и любые другие буквы алфавита.
Про Лунар я уже писал ранее, какие буквы используются в качестве служебных.

lupus, в комплекте с pfgtool помимо основной ttf_pgf.exe, есть еще dump_pgf.exe. Она умеет полную информацию по каждому символу в pgf выводить, в том числе и информацию о длине/ширине. Знающий человек посмотрев исходники dump_pgf, по идее, сможет понять где все это хранится и как изменить.

ErikPshat, как уже говорил: международные символы (ascii) править в TTF не поможет. ascii символы после конвертирования в pgf на экране занимают ровно столько места, сколько сами глифы. Если стереть все глифы, то символ абсолютно 0 пикселей интервала будет занимать и просто пропадет.

riku.kh3 добавил 09.05.2014 в 14:04
В этом плане тут все еще даже хуже, игра понимает скриптовые комманды в тексте и различные сочетания ascii буковок могут стать триггером комманд.

Ну вот возьмём shift-jis пробелы:

http://s020.radikal.ru/i720/1405/da/b2e49c67773a.png

Возьмём для примера кавычки " с которых начинается предложение.
Как видно, после кавычек пробела нет и они занимают маленькое расстояние.
Если мы эти кавычки затрём, чтобы на экране вместо них отображалось пустое место, то получится вполне компактный пробел.

То есть, в переводе нужно писать в кодировке shift-jis, но вместо пробелов ставить кавычки. Либо, если уже перевод осуществлён, через поиск замену можно тупо массово заменить пробелы на кавычки, хоть в тексте хоть в хексе.
Тогда, как видно на скрине - расстояние между буквами нас устраивает и так же будет устраивать пробел (пустые кавычки). А PSP будет думать, что мы ставим кавычки и не будет добавлять 2-ой пробел.

Другое вопрос в том, сможем ли мы, исправив TTF, сконвертировать шрифт в PGF, чтобы он потом мог отображать писанину, сохранённую в shift-jis ?

Пробела как раз таки и не получается, символ и занимаемое им место пропадут. И даже если получится это реализовать, бонусам перестанет работать перенос слов (с　shiftjis　пробелом　он　работает) и в сохранениях будут крокозябры. То есть идеальным решением все-таки было бы уменьшить существующий shiftjis пробел вдвое.

С этим проблем нет:

http://s52.radikal.ru/i137/1405/8d/ab57e5aab45f.png

(скрин не самый удачный, т.к. пробелы на нем по прежнему проблемные - $20)

Не понимаю, как может пропасть занимаемое символом место. Система будет всё равно думать, что символ на том месте есть и никуда он не пропадёт. Ведь код символа останется тем же, но не такой код пробела 0x20, а уже тот самый родной код символа, кавычек например.

И с чего перестанет работать перенос? Неужели для переноса ты используешь символ пробела?

Скинь плиз уже готовые ресурсы перевода, с самого начала игры, чтобы я мог потестить, а не переводить всё с начала...куда-нибудь в личку к примеру.

При конвертации из TTF в PGF это, по видимому, происходит. По сути, он никуда не пропадает, просто занимает 0 пикселей и визуально его не видно.

Я не о ручном переносе слов говорю (это было бы кошмаром, учитывая объемы текста), а об автоматической, которая в игре реализована.

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

Такс, по-моему ты мне вводишь в заблуждение мои мозги :)
О каком таком пробеле shiftjis идёт речь? Ты мне уже всю тему про эти пробелы твердишь.

Вот сейчас проверил код пробела в обычной windows-1251 и в shiftjis - символ пробела один и тот же 0x20.
Так что тут пробел абсолютно не при чём. Крашится игра при сохранении не из-за пробела, а из-за управляющих символов, попавших в кириллический диапазон win-1251.

Думаю можно сохранять в другой кодировке, например UTF-8 или UTF-16LE(BE), либо в чём-нибудь другом, где возможно не используются служебные символы от игры.

ErikPshat, да там просто все замороченне некуда - $20 пробелы не в 100% случаев вызывают крэши при сохранении. Но, опять же, во многих случаях если во фразе, на которой происходит крэш, зменить $20 пробел на shiftjis пробел ($8140), то сейв происходит нормально.

Опять же говорю, что Shift-JIS пробел всегда имеет код 0x20.

Вот для примера я сохранил один и тот же текст "Привет Кёске, как дела?" в разных кодировках:
(название текстовика видно в заголовках программ, а кодировка текстовика видна в нижней части программы)


И вот что я вижу в хексе, какие коды символов использует та или иная кодировка:

---

Ну может быть PSP действительно берёт не тот код пробела, а по своему, из другой области 0x8140.
Но непонятно тогда, ведь когда ты сохраняешь текст в Shift-JIS на компьютере, то код пробела должен быть 0x20.

ErikPshat, в японском языке пробелы по-сути вообще не нужны, и редко когда используются. Как и все остальные ascii символы вроде: .,"'()[] ... т.к. там есть свои: 。、゛’「」『』…

Но не в этом суть. То, что я называю shiftjis пробелом - это стандартный, как и все остальные shiftjis символы, двухбайтовый пробел. Вдаваться в смысл как конвертеры кодировок работают не стоит, достаточно просто знать, что ascii пробел (однобайтовый, 0x20), как и остальные ascii символы (.,"'()[] и т.п.) он переносит как есть.. т.к. shiftjis кодировка включает себя саму ascii (хоть она на практике практически и не используется) и по мнению конвертера и фактически оно всегда будет отображаться как надо.

И еще уточню по поводу русских буковок в shiftjis: по стандарту, они часть японской кодировки (как греческие буквы и т.п.), и восприниматься, по сути, должны как и остальные иероглифы... но похоже, что конкретно с этой игрой все гораздо сложнее.. хоть и сам русский текст в игре в чистом shiftjis'е, судя по всему, происходит вмешательство libfont (или другого?) psp модуля, и конвертирование текста в юникод (насколько я понял, pgf формат шрифтов в юникоде) и это вызывает рэндомные крэши вообще независимо от пробелов. :scratch_one-s_head:

riku.kh3, ну вот ты сохрани любой текст в любом текстовом редакторе в кодировке shift-jis.
Потом проверь в хексе, какие коды в этом shift-jis сохранились. Ты сам убедишься, что пробел там 0x20.

Собственно сдампил из памяти PSP один диалог с твоего перевода. Там действительно вместо обычного пробела подставляется "длинный пробел" 2 байта = 0x8140.
Эти пробелы так же используются в программировании, для отступов исходного кода. "Длинные пробелы" так же бывают 4-байтными и 8-байтными. Ну ты сам наверное встречался с такими, когда в исходниках хочешь удалить или выделить один пробел, а на самом деле удаляется или выделяется длинная полоса.

Мне кажется, что в конвертере допущена ошибка, когда он сам вместо пробела вставляет служебный символ.

---

Короче, вот кусок дампа памяти: Вложение 10032
Там ELF-код лишний почистил, оставил только выводимый текст и инфу по шрифту (FTT-NewRodin Pro DB), которые оказались в дампе.
Причём в памяти коды символов букв не совпадают с кодом в прилагаемом тобой шрифте (HGRSGU002.TTF). То есть, в твоём TTF-шрифте идёт сдвиг кодов.

И да, в дампе памяти используется служебный "длинный пробел" 0x8140.
Я думаю, что его подставляет конвертер изначально, а не PSP его так подменяет.

Кстати, есть идея сдампить оригинальный японский диалог и подсмотреть, какой символ пробела там подставляется.

Короче, текст нужно писать, чтобы не было багов, в Shift-JIS кодировке.
Но пробел должен быть стандартный 0x20, как и положено в Sift-JIS, а не 0x8140.

ErikPshat, давай проссуммируем что мы имеем:

1) Никто нам не запрещает использовать стандартный ascii пробел (0x20) и он прекрасно отображается в тексте, но это одна из причин, по которой игра рэндомно крэшится на сейве.

2) Тулза для вставки текста в SCRIPT.PAK дает использовать 0x20 пробел, но я специально их все заменил на $8140 пробел чтобы выявить закономерность крэшей.

3) Использование русских буковок в shiftjis (8440-8460, 8470-8491) еще одна из причин рэндомных крэшей (что-то связано с юникодом pgf шрифта?)

4) Двухбайтовые shiftjis символы, хоть и выглядят все одинаковой длины, не моноширинные. Доказательство тому символ $814B:
5) Изменить ширину shiftjis символов играясь с TTF не представляется возможным, после конвертирования в PGF ширина у каждого символа всё та же как и была.

1) Ты говорил, что с Shift-JIS кодировкой всё в порядке. А вот с однобайтовой 1251 вкупе с пробелом 0х20 - происходят креши. Поэтому я так и понял, что в кириллице именно 1251 используются служебные символы.

2) По видимому ты сам значит выставил такой длинный пробел, вместо короткого )))

3) Тогда это причина перейти на другую кодировку, например UTF-8, там символы в диапазоне 0401 - 0451. И возможно игра не использует из этого диапазона служебные коды.

4) Ну и русский 2-байтный шрифт так же в Shift-JIS выводится, как однобайтный, вернее нормальной ширины. Так что не в этом проблема.
2 байта на символ - это всего-лишь порядковый номер символа в таблице шрифтов и это совсем не значит, что символ выводится 2-мя байтами.

5) Я уже посмотрел таблицу шрифтов - там даже нету в таблице этого кода пробела 0х8140. Поэтому этот код пробела берётся не из таблицы шрифтов TTF или PGF, а оно уже заложено в либах.

---

И поэтому я предлагаю:

1. Либо сменить кодировку.
   
   
2. Либо вместо пробела использовать другой неиспользуемый символ и заменить его стандартным пробелом, т.е. вместо того символа скопировать/вставить пробел. Затем в конвертере пакетно заменить код 0х20 на код того символа, точно так же, как ты заменил на 0х8140.

Выложу сюда скриншоты, чтобы мне было легче ориентироваться по кодам...
Почему у тебя ошибки в переводе? ))

ShiftJIS кодировка - это единственная в которой я разбираюсь и знаю как устроена. Каким образом игра вообще может знать о существовании русской 1251 не представляю. :scratch_one-s_head:

Да, специально, крэшей стало намного меньше, но они по прежнему есть.

Опять же, понятия не имею как это все устроить, и как модуль шрифтов это все обрабатывает.

Пардон, я думал 1251 кодировка тоже однобайтная, с ней не приходилось просто никогда работать. Никогда не видел чтобы с shiftjis кодировкой такое срабатывало.

TTF, насколько я понимаю, в юникоде и там у него код другой. PGF вроде как тоже в юникоде. :scratch_one-s_head:
Ссылку я уже давал, тут коды всех символов в shiftjis:
http://www.seiai.ed.jp/sys/text/java...jis_table.html
Сначала идет "половинчатая", однобайтная область, затем "полная", основная, двухбайтная.

Да, я уже это делал, частично проблему крэшей это решает.. Но по причине №3 не полностью.

riku.kh3 добавил 13.05.2014 в 16:46
Это не ошибка, это куски разных фраз слепленные в одну. Тулзу, которую я давал, через AppLocale если запустить из японской среды, то можно нормально каждую фразу на русском смотреть и редактировать.

Эмм, по-моему ты совсем в этом ничего не понимаешь :D
Или, скорее всего, ты себе сам всё усложняешь тогда, когда всё на самом деле очень просто.

Кодировка - это всего-лишь набор символов и всё! Просто в каждой кодировке все буквы пронумерованы по разному. Взять чисто однобайтную кодировку, то там количество кодов не превышает 0xFF, что получается, если перевести в десятиметричную систему 256 символов.
А как же добавить 257-ой символ?
Вооот! Тут-то 0xFG уже не проканает, потому что в 16-ричной системе максимальное число F и уже нету G ))) ну ты сам знаешь.
Поэтому, чтобы поместить в таблицу 257-ой символ, приходится считать дальше по правилам: 256 = 0xFF, 257 = 0x0100, а 65535 = 0xFFFF.
Вот тебе и всё правило кодировок 1-байтных или 2-байтных.

Поэтому секрет 2-байтных кодировок в том, что в ней присутствует и 1-байтная кодировка :D потому что элементарно подсчёт символов в любой кодировке начинается с нуля, а не с центра вселенной.
Ты же яйца в корзине, если их там 100 штук, начинаешь считать всё равно с 1 единицы, а не с 50-ти )))

Кодировки между собой отличаются только количеством символов и соответственно их порядковым номером в 16-ричной системе.
Если ты хочешь писать в UTF-8, то и символы русского алфавита нужно подсунуть в её диапазон в шрифте.
Кстати, в Shift-JIS я вижу, что русские символы как раз дублируются в диапазоне UTF-8 (0401 - 0451). Таким образом, можно тупо сохранять текст в UTF-8 и шрифт Shift-JIS будет его отображать.

ErikPshat, по прежнему не объясняет почему игра должна понимать UTF-8. Под shiftjis выделена четкая область и границы начиная с $8140 (ну + ascii еще 00-FF), на все что ниже ей просто параллельно и она не будет это отображать.