Crash Team Racing [SCUS-94426] [FullRUS] [RGR|RETROGAMING]

[YAGAMI55]

Сейчас мысля возникла...возможно и названия трасс можно таким же макаром проверить. Думаю у трасс тоже поинтером является какое то название(например oxide station)

[SlavaVlasov]

Цитата: Сообщение от YAGAMI55 Например найти в шрифте неиспользуемый символ, каких много и залить пустотой(второй пробел)

Я так уже пробовал с обычными буквами - они все равно не сдвигаются на экране Пуры и Тигра, т. к. им мешают полосы характеристик. Именно когда рамка слева. Я думаю, RGR не просто так обозвали Ускорение "Разгоном".

Цитата: Сообщение от MFS сами поинтеры (т.е. значения, которые нужно вычислять/изменять) как таковые в игре есть? Или здесь как в первых трех Бандикутах

Здесь, в отличии от первых трех частей, они есть. Я уже как-то скидывал одному человеку свою статью с описанием принципа поиска пойнтеров в этой игре. Продублирую ее здесь:

Пойнтеры CTR

Привет. Основы я понял из этой статьи:
http://shedevr.org.ru/cgi-bin/docs.cgi?n=3


Но главным образом выявил две вещи:

1. Отнять 10h: 28210 à 28200 - это лишнее для PS1-игр.
2. Пойнтер - это часть адреса смещения, в которой пары чисел развернуты наоборот (таким образом пойнтер 00 10 на самом деле означает 01 00 - т.е. число "100").

Пойнтеры главным образом указывают на участок памяти, где расположено начало строки. В самом роме (образе) в случае с PS1 они обычно - фиксированные, а в самой оперативке приставки имеют уже другие значения. Таким образом, пойнтеры в образе и в Save State'е (или в самой оперативке), сделанном, например, в pSX 1.13 будут отличаться.


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

1. Запускаем игру в pSX 1.13
2. Находим момент с текстом на экране
3. Открываем HxD и нажимаем на кнопку с микросхемой, чтобы напрямую открыть процесс из оперативки в хекс-редакторе
4. Выбираем процесс psxfin.exe (вроде бы так)
5. Ищем поиском текст, который отобразился в игре, и выясняем его адрес (оффсет)
6. Обрезаем адрес до двух последних чисел, перевернув пары местами, и ищем это значение в памяти.
7. Пробуем изменить значение (например, 01 00 меняем на 02 00) и сохраняем изменения (CTRL+S) обратно в память.
8. Переходим в эмулятор и смотрим, изменился ли текст, начало ли слово отрисовываться на экране со второй буквы, а не с первой. Если это так, значит мы нашли пойнтер.
9. Теперь, смотрим где располагаются пойнтеры, относительно блока текста, в котором находится искомое слово, и ищем их уже в файле из образа, где должен содержаться текст. Зазор между текстом и пойнтерами может отличаться в файле из образа, но обычно пойнтеры идут ПОСЛЕ текста. Таким образом мы выяснили, где рабочие пойнтеры, влияющие на конкретное слово, где они располагаются и где примерно их искать уже в файле. Теперь остается изменить их файле, импортировать его в образ и проверить на изменения в эмуляторе.

Практика:

• Берем игру Crash Team Racing.
• Запускаем ее в pSX 1.13, заходим в какую-нибудь трассу (Time Trial, Arcade) и нажимаем на паузу.
• Открываем HxD и ищем слово "PAUSED" (оно самое первое в текстовом блоке) и мы его будем менять. Для удобства можно открыть память еще раз, чтобы на разных вкладках мы видели разные участки памяти (Текст, Пойнтеры).
• Ищем фразу "DO NOT REMOVE.THE MEMORY CARD!". После нее будет написано "na.na.na" и сразу через 3 нулевых байта - первый пойнтер (указывающий, на слово "PAUSED"). В случае с CTR и работе с памятью, у пойнтеров во втором числе (00 00) всегда будет одинаковое значение. По нему можно определить, что это именно пойнтер, т.к. они разделены еще двумя байтами, которые постоянно далее дублируются, но имеют одинаковое значение (видимо, это типа "разделитель" такой между пойнтерами). Левое значение пойнтера (00 00), а именно - разница чисел от предыдущего к следующему - показывает то, что тут учитывается длина слова: "если посчитать все буквы в первом слове и нулевой байт после него, с какого числа начинается первая буква следующего слова?". Например, если у нас есть последовательность "YES.NO", а "YES" начинается с пойнтера "00 00", то слово "NO" начнется с "04 00" (четвертая буква). Это и есть то, что нужно регулировать: адрес начала строки.
• Измени первое значение пойнтера на более старшее (например, 30 > 31), CTRL+S, и посмотри в эмулятор: скорее всего, "PAUSED" превратится в "AUSED" (т.е. слово считывается со второй буквы). Можно поиграться со словом дальше.
• Переходим ко второму пойнтеру: он находится через три байта от числа, которое мы только что меняли, и имеет похожее, но более старшее значение (с разницей в "+7" по сравнению с оригинальным значением предыдущего пойнтера) (30XX, 37XX). Меняем второе число также, CTRL+S и видим в эмуляторе, что у нас изменилось слово "RESTART". Понятное дело, что если мы будем уводить значение в минус, а не в плюс, слово вообще пропадет с экрана, т.к. чтение будет происходить не с буквы, а с нулевого стоп-байта. Либо мы увидим "огрызок" предыдущего слова, которое им лишь и заканчивается.

Теперь вернись к блоку с текстом и попробуй написать два более длинных слова, разделив их по традиции нулевым байтом, и посчитай кол-во букв в первом + нулевой байт. Например, если слово "PAUSED" ты заменишь на "QPNOCTAHOBLEHO" (14) + нул. байт (1) = 15, то получается, что если первый пойнтер, допустим, "30", то следующий пойнтер для второго слова будет "3F"(считать шестнадцатеричные числа будет удобнее, вооружившись Windows'овским калькулятором в режиме "Программист").


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






Теперь переходим к более реальным вещам:

• Скопируй из образа в папку файл BIGFILE.BIG и открой его в HxD
• Найди слово "PAUSED". Обрати внимание, что оно находится по адресу 68B4008, а второе (RESTART) - по 68B400F.
• Теперь, переворачиваем числа у первого адреса и получаем - 08 04. Здесь есть один момент: вот это "XX 04" вообще лишнее. По факту там - "XX 00", поэтому, находясь курсором в блоке с текстом и выбрав поиск вперед по "шестнадцатеричным значениям", ищем значение "08 00". Он найдет его как раз после вот этого "na.na.na", где мы ранее находили пойнтеры. Обрати внимание, что после "08 00" через два байта идет "0F 00" (68B400F). Вот мы и нашли первые два пойнтера, за которыми идут и все остальные. И теперь знаем, как они визуально выглядят с правой стороны в текстовом представлении.

Изменив пойнтеры уже в файле и импортировав его обратно в образ, ты уже на эмуляторе увидишь разницу.



Главной задачей при работе с пойнтерами является их пересчет. Например, если ты решишь перефразировать первое слово, которое, скажем, короче предыдущего варианта на 1 букву, надо будет изменить КАЖДЫЙ пойнтер, который идет после этого слова, изменив его значение на "-1" от текущего. Некоторые используют специальные программы, с которыми я пока не разобрался, некоторые используют Excel, где вроде бы можно включить шестнадцатеричное отображение (это я еще не пробовал) и считать каждое слово(+1 нул. байт) в отдельном столбике, суммируя предыдущие строки.




Также стоит отметить, что не всегда пойнтеры можно найти просто переворотом отрывка адреса: в случае с CTR главной особенностью похоже является BIGFILE.BIG, где пойнтеры уже прописаны. Сложнее вроде там, где текст в отдельном файле или в самом EXE-шнике игры (в том же Тони Хоке я так до сих пор и не нашел пойнтеров - может плохо искал). Еще одна сложность с CTR состоит в том, что пойнтеры идут ПОСЛЕ блока текста. Т.е. нас никто не ограничивает в длине слов, но сам блок превышать нельзя. Таким образом, сокращая одни слова, можно наращивать другие, тем более с пойнтерами - нам не надо затирать более длинное слово дублирующимися пробелами или нулевыми байтами. В некоторых случаях, можно выкрутится. В некоторых предложениях "Карта памяти в слоте карты памяти 1 не отформатирована. Отформатировать карту памяти?" можно сократить кол-во т.н. "тошноты" и привести в более человеческий вид "Карта памяти 1 не отформатирована. Форматировать ее?", освободив тем самым лишние байты.




Еще один момент касается перевода от RGR: они-таки "раздули" блок с текстом, сдвинув также и блок пойнтеров. Я не уверен, но, вероятно, в недрах файла существует пойнтер, указывающий на блок пойнтеров. И вот его как-то нужно найти.

Немного оффтопа

Попробовал я значит уместить в один образ всех 4-х Крэшей (1,2,3+CTR). Для этого взял образ от RGR "Золотая серия хитов 4 в 1" (которые уже вычистили "мусорные файлы" в первом Крэше) и выкинул оттуда первого Спайро. Что могу сказать... CTR получилось закинуть в образ в работоспособном виде, но только вырезав:

• Почти всю речь
• Музыку XA (фанфары перед гонкой, победная музыка на стендах... или как они называются?)
• Ролик Scrapbook
• Видео-превьюшки трасс.

В остальном игра работает и трекерная музыка внутри трасс сохранилась

P. S. Вот интересно, первая сонька читает специальные CD-R болванки на 800 мегабайт? Тогда бы можно было выкинуть только Scrapbook.

[SlavaVlasov]

Цитата: Сообщение от YAGAMI55 Сейчас мысля возникла...возможно и названия трасс можно таким же макаром проверить. Думаю у трасс тоже поинтером является какое то название(например oxide station)

Да, мысля хорошая. И я даже надеялся на нее, но она не сработала. Я стер между названиями трасс все нулевые байты, и хоть одна строка должна была сработать в отношении рамки. Но ее ширина не изменилась:

Нажмите

[YAGAMI55]

SlavaVlasov, огромное спасибо за статью. Вот честно. Теперь немного представление иметь буду о поинтерах, может на D попробую...да о чем речь))) уже ищу их...

По поводу трасс в Краше печально, ты опередил меня конечно, я ток за комп сел тестить...но что поделать. Значит без сокращений не обойтись!


P.S по поводу блока поинтеров у RGR в CTR...заметил подобное у Firecross и его версии охотника. Там тоже самое, файлы раздуты, текст дублируется по неск раз, и поинтеры непонятные. Их толком нет только нули одни и диалоги разделены этими нулями 00(я например использую их что бы диалоги чистить от немецкого и французского) , не уверен за ориг PAL версию охотника, но USA NTSC имеет плавающие значения 1F, 3D и т.д

[SlavaVlasov]

Цитата: Сообщение от YAGAMI55 P.S по поводу блока поинтеров у RGR в CTR...заметил подобное у Firecross и его версии охотника. Там тоже самое, файлы раздуты, текст дублируется по неск раз, и поинтеры непонятные.

Сейчас проверил версию от FireCross - да нет, там пойнтеры как раз не тронуты (потому они и сокращали текст):

FireCross

А вот так выглядит это у RGR:

RGR

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

[SlavaVlasov]

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




Адрес в BIGFILE.BIG: 0x68B0004
Также важно заметить, что в BIGFILE.BIG вшито два текстовика.
Адрес пойнтера для второго текстовика: 0x68B4004


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

Нажмите

В свое время я прочесывал целый BIGFILE.BIG в поисках этого байта. Кто же знал, что он находится на самом видном месте - перед началом текста?

[YAGAMI55]

Спасибо за нахождение)))

[YAGAMI55]

Цитата: Сообщение от SlavaVlasov Ну, вот, можете опять меня поздравить: нашел я пойнтер, указывающий на блок самих пойнтеров. Вот он: Адрес в BIGFILE.BIG: 0x68B0004 Также важно заметить, что в BIGFILE.BIG вшито два текстовика. Адрес пойнтера для второго текстовика: 0x68B4004 В общем, насколько у нас длина блока текста превышена (а еще точнее - на сколько байт сдвинут блок пойнтеров относительно своего исходного положения в оригинальном BIGFILE.BIG), на столько мы и увеличиваем значение этого шестнадцатеричного байта. Нажмите В свое время я прочесывал целый BIGFILE.BIG в поисках этого байта. Кто же знал, что он находится на самом видном месте - перед началом текста?

Как всегда отличные тесты и расчёты, теперь MFS Khaos знает даже больше, что бы его перевод был идеальным. Жду с нетерпением)))

[MFS]

Уф-ф-ф... Выхожу (НАДЕЮСЬ!!!) на финишную прямую своего перевода. И чем больше в нём копаюсь, тем больше понимаю, что перевод, как и любое творчество, нельзя доделать, можно просто прервать на определенном этапе. Но одну китайскую загадку я так и не разгадал. Это нумерация кругов в некоторых режимах:

Нажмите

Хотелось бы, конечно, заменить это дело на аналогичные русские К1, К2 и т.д., но сколько бы ни рылся в текстовиках и прочем, ничего похожего не нашел. Может знает кто, как выйти на байты, отвечающие за эти злосчастные L1, L2 и т.д.?

[brill]

MFS, в файле SCUS_944.26, по смещению 0x7dd0c будет лежать искомое значение.