Сегодня в графике себя попробовал. :)Прозрачность в TIM2 просто из себя выводит...

Не, точно не там, если от другой английской игры SYSTEM.CFG подсунуть - ничего не меняется.

riku.kh3, кстати, чем ты *.CPK распаковываешь? Нарыл тулзу cpk_unpack.exe, распаковывает, как сами контейнеры DATA0.CPK и DATA1.CPK, так и их содержимое. Ппц, распаковал BGL00.CPK, так там 826 файлов TIM2.

Покритикуйте мою логику в коде, плиз. Там асм знать не надо, надо только здравый смысл. Если все ок, я домой приду закодаю.

Erik, Never7 ждет, а ты какие-то cpk распаковываешь :)

А как ты собираешься свой код умещать?

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

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

Например вместо этих:

А тут-то какие вопросы? Ever17 мне никто конвертор не написал, а кроме этого у меня вопросов нет.
ruki тоже со всем разобрался, кроме кнопок.


Never7 я еще даже не качал. Но подозреваю там всё очень похоже на Ever17.

Там все точно так же плохо, как и с TIM2. 8-битный файл с прозрачностью - это полный гемор.. PNG 8bit альфу не поддерживает... можно в PNG 32bit сконвертить, да, но назад как? Когда изменения внесешь, надо опять снижать цвета до 256 + альфу обрабатывать... я бы наверное даже посоветовал в TIM2 твой формат конвертировать, там палитра такая же используется + сам битмап точно такой же линейный, и для него есть профессиональный софт для грамотного конвертирования цветов с минимальными потерями.

А гиф? Гиф же поддерживает альфу.

Хмм.. хорошая идея, на самом деле. Я GIF почти не пользовался, правда, не знаю как там дела с палитрой обстоят. Фотошоп его открывает, редактировать можно, но получается, что ты привязан к старой палитре.. рендеринг и сглаживаение кривоватыми получаются. :scratch_one-s_head: Опять же сконвертировать 32-битную картинку в 8-битный GIF с прозрачностью я в своем фотошопе не нашел ничего адекватного.. в одну из стандартных палитр только, выглядит кошмар.

Зачем конвертировать 32-битную картинку в гиф? Ты же говорил там 8-бит палитра?

Если в пределах старой палитры собираешься работать, то незачем. В паинте, там, карандашиком рисовать. :)
Хреново рендерится все из-за этого. Эффекты там фотошоповские, текст, сглаживание и т.п.

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

Я тут точно не помогу, стандартными компонентами я понятия не имею как с прозрачностью в палитре у GIF работать.. а на бинарном уровне если конвертировать - это надо все разбирать, включая сжатие.. опыта у меня в этом не так много, дни уйдут(

Блин. Опять самому говнокодить конвертор :( Вы не представляете какое у меня количество говнокода на php для Ever17 уже. По-моему никто на php так не изголялся еще для переводов. У меня опыта в этом вообще никакого нет, я даже не представляю, чего с этим можно на пхп сделать - он же явно не для этого предназначается.

Scorpeg добавил 06.02.2015 в 01:40
Ну че, мой хитрый план вроде сработал. ruki, потестируй, как оно там, одновременно несколько клавиш понажимая (ну там стрелку с чем-нибудь и с крестиком/ноликом). Должно всё отлавливать. Как же бесят эти мипсы, в которых ну просто нихрена нет ни одной нужной операции, приходится городит ВОТ ТАКУЩИЙ ОГОРОД ради элементарных битовых операций... Моя логика вообще должна умещаться там не знаю, в десяток команд, а пришлось распахать аж на 20 (а с учетом переписывания в at - реальных команд еще больше). Да еще и вторую команду после джампов захватывает, которая и падлит периодически. В чем профит так делать был? Неудивительно, что мипсы померли для PC.

http://logtech.ru/EBOOT.BIN.7z

А кстати потом (когда ты с этим закончишь), может засунешь английский перевод в Umineko no Naku Koro ni Portable? А то я все хотел поиграть, а нету. Там вроде тоже CPK.

Scorpeg, все супер, работает отлично, снимаю шляпу. thank you

Не за что. Я правда туда не внедрял эту хоум-кнопку на русском (у меня сейчас тоже только эмулятор, не проверить), поэтому тут пусть кто-то другой проверит.

Тебе долго чтоли еще осталось с этим? Даешь уминеков :)

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

Недостающие части еще надо будет допередеводить, версии отличаются, в основном моменты с H-сценами переделаны. В общем: месяц-вда по самым оптимистичным прогнозам. :scratch_one-s_head:

riku.kh3,
а где за прогрессом следить можно, если что? =)

Классный, очень хитрый план. Хотя и так всё работает, но есть только небольшие уточнения... Тут у тебя прыжок записан по адресу loc_0891E38C, но в EBOOT.BIN нет такой адресации. Хотя прыжок должен быть на 0x0011A38C.
Но если отнять 0x08804000, что прибавляет эмулятор, тогда всё встаёт на места.
Т.е. 0x11A38C : 4(u32) = 0x0468E3. Нулевой джампер начинается с 0х08, поэтому записываем адрес 0x080468E3 = loc_0011A38C

---

Ну и дальше в самом "sceUtilitySavedataShutdownStart()" такие же просчёты с прибавкой эмулятора.
0x0A2478F6 = 0x0891E3D8 - 0x08804000 = 0x0011A3D8 : 4 = 0x080468F6
0x0A2478F5 = 0x0891E3D4 - 0x08804000 = 0x0011A3D4 : 4 = 0x080468F5
0x0A228443 = 0x088A110C - 0x08804000 = 0x0009D10C : 4 = 0x08027443

ErikPshat,
причём тут просчёты? uMem начинается с 0x08800000, адрес загрузки eboot.bin - 0x08804000 (часто, но не всегда).

Yoti, но в самом EBOOT.BIN все относительные адреса смещений заданы без учёта 0x08804000. Там просто отнимается заголовок ELF = A0 и отсчёт всех смещений идёт с нуля.

ErikPshat,
а как по мне, то нет =) Буду дома - проверю на консоли.

Ну вот, например в файле есть такого вида смещения. И я вижу в этих же позициях в файле EBOOT.BIN именно эти же записи значений.

Вложение 10648

Последняя имеющаяся секция в файле = 0x0014D5D8. Там нет столько байт, как 0x08804000.
Вот так показывает его смещение:

Вложение 10649

Хотя, по аналогии со всеми другими смещениями, должно отображаться loc_0011A38C, потому что именно по тому адресу в EBOOT.BIN он прописал кнопки.
Но не на loc_0891E38C. Хотя PSP видимо считывает и так и эдак.

Да, как-то не гуд выглядит. Может с совместимостью проблемы потом возникнуть в каком-нибудь из эмуляторов. Может другим ассамблером попробовать этот опкод собрать?
:scratch_one-s_head:

riku.kh3, да в принципе лучше оставить, как есть. Работает замечательно.
А вот мой вариант я проверил, и не работает :) У меня рассчёт на смещение вроде правильный, там прописывается адрес 4-байтными шагами на байт.
Просто номер функции MIPS видимо не такой. Но вроде верный.
Там 1-ый байт 0х08 берёт адресацию 0х00000000, если 0х09, то адресация 0х04000000, если 0х0A, то 0х08000000ю

простой джамп, видимо, не принято на psp использовать. jr и jal повсюду только вижу :scratch_one-s_head:

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

riku.kh3, да не, джампов там полно, они в конце все.
Scorpeg вроде всё нормально сделал, и инструкцию добавил и return на следующую функцию. Он всё это встроил вместо сообщения об ошибке и туда направил прыжок. Просто я не пойму, почему стандартный мой отсчёт не работает, хотя по всему файлу виден явный отсчёт без всяких прибавок 0х08804000.

Хакеры, вашу мать :)

Scorpeg добавил 07.02.2015 в 16:59
Это у Erik'а задвиг не туда. Всё четко у меня. Ты ж видишь что работает, нет? :) Был бы косяк - оно бы не работало.


Короче ликбез нумер два для Erik'a и сочувствующих.

Во второй раз говорю (как уже ранее я писал и недавно писал Yoti) в память PSP Eboot грузится по адресу 0x08804000. Не каждая программа, но в 99% случаев это так (там прописано в общем-то в ебуте куда грузить).

То есть eboot грузится по этому адресу в память PSP, принимай это как факт.

Что происходит далее? Далее происходит применение релоцируемых данных или как их там по научному зовут. Суть их в чем - существует где-то в ебут табличка, где отмечены адреса с переходами (джампами). После загрузки проги в память PSP пробегает по всем адресам и относительное смещение (вот это вот j 0x1111 которое вы видите в других джампах в PRXTool) преобразует в абсолютное (в j 0x8804000+то число).

Поэтому, если вы например вместо любой инструкции (кроме джампа) воткнете например j 0x33333 она у вас так и останется неправильно j 0x33333 потому что она отсутствует в таблицу-указателе на релоцируемые адреса.

Поэтому Erik пошел вообще не туда. У меня код не имеет релоцируемых адресов - поэтому там указывать надо абсолютные адреса для джампов.

Ясно-понятно. Но все-равно, мне тоже интересно почему другой дизассамблер один этот единственный адрес по-другому показывает. :)

Да потому что bne - это относительная инструкция. Там адрес считается в пределах +0xffff и -0xffff от КОМАНДЫ.

Поэтому ее загрузи в любое место - будет одинаковые результат. Она относительную адресацию использует. Поэтому все бранчи будут отображаться правильно, куда угодно их загрузи. Можешь для интереса кусок этот сохранить с бранчам и загрузить куда-нибудь еще - он все равно будет тебе правильные адреса показывать.

То есть на деле оно выглядит как "прыгни на адрес, который равен текущему + сколько-то (но не больше 65535)".

Ну или доку по мипсам прочитай, там ровно то же самое написано.

А джамп использует абсолютную адресацию, поэтому там пишется абсолютный адрес. Бранчем нельзя же адресовать больше 65535 байт вперед и назад, а у меня он явно дальше ушел.

Scorpeg добавил 07.02.2015 в 17:17
Можешь не проверять, на ней тоже работает :)

Ну теперь-то понятно. Я так и понял, что у тебя адрес без релокации оказался, потому что новую функцию дебаггер не видит.

А это почему? Я вижу, что адресация кругом подсчитывается 3-мя байтами, не обязательно до FFFF. Вот примеры:

• 0x0802D866 --- loc_000B6198 = 745880 : 4 = 0х02D866
• 0x08044346 --- loc_00110D18 = 1117464 : 4 = 0x044346

Как бы больше, чем 65535. Первый байт 0х08 - указывает на функцию джумпа в 0х00000000.

Можешь проверить все смещения и этот алгоритм будет во всём файле применим.
Существует ещё правило, когда номера функций идут строго 2-байтные, то оставшиеся 2 байта значения пишутся младшими байтами(ессно до FFFF(65535)), а старшие байты просто отбрасываются.

Ты по диагонали чтоли прочитал? Я про команду branch (bne например), не про jump. У джампа 3 байта + 2 бита (26 бит) под адрес, у бранча - 2 байта под указатель смещения (16 бит). Еще раз отсылаю читать доку по mips, а не спорить ради спора. А лучше в Never7 разбираться :)

Scorpeg добавил 07.02.2015 в 19:05
Давай не путать терминологию. Дебаггер - тулза, которой можно отлаживать код в реальном времени (собственно отлавливать баги). PRXTool не дебаггер, а максимум дизассемблер - программа, которая разбирает код на ассемблере в человечитаемые инструкции. Так что нормальный дебаггер мою функцию как раз увидит, скорее всего. И IDAPro точно увидит, хотя она тоже дизассемблер, только интерактивный. Но это не особо важно, я думаю, что там увидит дебаггер, просто ты не теми терминами оперируешь и меня это путает.

Ну так а я про джампы веду разговор. Это ты же читаешь мои посты про джампы, а отвечаешь про бранчи. Бранчи-то понятно, что там там другой алгоритм и математическая формула. Там 2 регистра и значение, где в значении указывается смещение, относительно места расположения этого самого значения и расчитывается по формуле: значение - offset : 4 - 1.
И по ходу дела, я смотрю структуру кода и сразу выписываю формулы, чтобы закрепить знания в постах. Тебе может это не надо, но другие люди тоже могут искать ответы на подобные вопросы и им может помочь информация, каким образом эти цифры появляются и генерируются в файлах.

---

Короче, я просто посмотрел твои формулы и заметил, что ты использовал абсолютные смещения, хотя в EBOOT.BIN кругом используются относительные внутренние смещения. Поэтому подумал, почему бы не воспользоваться стандартами по аналогии с файлом, и вынес этот вопрос на обсуждение. От тебя просто хотелось услышать пояснения, почему был избран такой путь, а не то, как "у Erik'а задвиг не туда" или всякие ликбезы.

Ладно, признаю, что я полный лох педальный.
За твою реализацию хитрого плана с кнопками, присваиваю тебе звание Про-Геймера https://www.pspx.ru/forum/images/pspx/progamer.png ;)

---

---

riku.kh3, почитал ещё раз твою ссылку: http://bbs.blacklabel-translations.c...?tid=35&pid=84
В первый раз как-то не так дошло и я не туда полез выполнять шаг 2. Сейчас наконец допёрло, что это относилось всё к тем же строкам. Там помимо смены $zero на регион, чтобы не было глюков, надо было ещё сменить функцию move на li. После первой правки было так, с move: Чтобы сменить регистры, нужно поменять регистры move: 2025 и 2825 на li: 2404 и 2405 (для 10-тичного формата) или на 3404 и 3405 (для 16-ричного формата) Я сделал смену языка в десятичном формате. Если в первой строке поставить 1, то будет надпись на английском языке, я поставил на 8 для русского языка. Готовый файл, с правками кнопок от Scorpeg, во вложении...

ErikPshat, это не то же самое? :)

Да в том и дело, что у тебя на скриншотах как раз бранчи и написаны https://www.pspx.ru/forum/attachment....8&d=1423310816. ruki и не понял, почему бранчи правильно показываются, а джамп нет. Я ему и объяснил, как это делается (там первая же фраза в сообщении "Да потому что bne - это относительная инструкция. Там адрес считается в пределах +0xffff и -0xffff от КОМАНДЫ." - то есть сразу понятно, что я не про джампы). А ты эту фразу не заметил или еще чего, начал спорить на пустом месте непонятно с чем :) Пояснения я написал, почему "не туда" в ликбезе, вроде понятные. Если непонятные, то еще раз скажу, что я косноязычен и мне сложно объяснить, если с первого раза не получилось, поэтому тут лучше всего обращаться к доке по мипсам.

Вообще есть такая вещь как armips https://github.com/Kingcom/armips собственно ассемблер для мипсов (может кто не знал). Я в нем писал. Мож кому-то будет полезно. Kingcom правда загрузку ELF'а в нормальном виде не прикрутил, так что придётся как я писать пока что.

У-ха-ха, да, именно тоже самое :xDD:
Я чёта не допёр сразу. Это вчера только боги спустились с небес и мне во сне объяснили что к чему.

Только в тот раз я move не трогал, а просто сменил zero на 1 и у меня высвечивалось по-русски. В этот раз я поменял на li и всё стало по-английски, пришлось поменять 1 на 8. Но ты конечно изначально уже всё это сделал. Бывают у меня заскоки, когда глаза видят одно, а мозги вычисляют по другому. Просто когда до мозгов сразу не доходит, то они думают как-то иначе :)

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

А за армированные мипсы спасибо. Было дело я когда-то в Mars-e умудрился написать программку на асме, где на кубике Yoti что-то там плавало. Да там собсно не С++ писать, это как батники рисовать, просто смотришь спецификацию и рисуешь. Но конечно в асме и мипсах я ничерта не шарю, всё держится только на логическом обосновании.

Так и я не тебе, а riku отвечал. И ты опять путаешься в показаниях, до этого говорил, что ты про джампы, теперь ты про оффсеты заговорил, хотя оффсеты только у бранчей, а у джампов - прямые ссылки. Короче замнем это, не суть, а то можно долго докапываться, кто чего хотел сказать :drinks:

И ты может начнешь уже Never7? Я тебе даже план уже написал, тулзы тут есть (вообще почти все тулзы подойдут отсюда, и формат графики тоже наверное). Осталось только скрипты повыдирать и присоединить. Ну и init.bin разватрушить (я не осилил пока что его целиком, только 75% гыгы) :crazy:

Кстати по поводу картинок. Всё не так :) Это просто такие удачные картинки попались с одной колонкой.

А на самом деле оно выглядит так: http://psp4real.ru/_tr/kb_0.png

И где-то там, в хедере, находится информация, как из этих квадратиков собрать нормальную картинку.

Всем привет. Проект еще жив? На неделе разбирал ресурсы Remember11, пытаясь адаптировать перевод (заодно узнал что psp сцена почти умерла :( ). И столкнулся с некоторыми трудностями. Возможно, здесь мне кто-нибудь сможет помочь. И, конечно, готов поделиться всем, что обнаружил сам, если это окажется полезным.

Я, по возможности, реюзаю код комманды из tlwiki, которые занимались pc версией, попутно допиливая нужные изменения.
С картинками много не заморачивался, т.к. пользы от этого мало. Зато разобрался со шрифтами, осталось только нормальный конвертор в bmp/png и обратно написать.

Набросал скрипты для распаковки iso, распаковки AFS, декомпресии упакованных lzss-ом ресурсов, и переупаковки всего этого добра(или зла - зависит от восприятия) обратно.
Ресурсы пока не модифицирую, не считая некоторой работы с BOOT.BIN руками, т.к. для начала хочу убедиться, что все правильно пакуется и сжимается.

Все работает, с одним досадным исключением: если разжать и сжать обратно init.bin, то игра будет крешиться при загрузке. Через эмулятор тоже крешится, при чем сам эмулятор. А разжимать файл надо, т.к. туда вбита большая часть текста. Кто-нибудь сталкивался с такой проблемой? и как ее решили?

Подскажите, можно ли как-то "дебажить ассемблер"? Подключить gdb к запущенному iso не знаю как, но мне нужно как-то определить где оно вылетает.