Анализ ресурсов игры Wrath of Earth (возможность перевода)

Результаты поиска относительных байтовых последовательностей в файле woe.rsc

Я решил выполнить относительный поиск в окне из 4-х байт. Ищем распространенное слово THIS. В относительном представлении это будет последовательность байтов (0,244, 245,255). Ищем не менее распространенное слово YOUR. В относительном представлении это будет последовательность байтов (0,246, 252, 249). Я надеюсь, ни у кого не возникает вопросов, почему такие числа и как выполняется сравнение. Найдены прямо в файле woe.rsc (какие это участки я не разбирал).

Смещения относительной последовательности байтов THIS
THIS

0000D8EE
0000E1EE
0000EAEE
0000F3EE
0000FCEE
000105EE
00010EEE
000117EE
000120EE
000129EE
000132EE
00013BEE
000144EE
00014DEE
000156EE
00015FEE
000168EE
000171EE
00017AEE
000183EE
00018CEE
000195EE
00019EEE
0001A7EE
0001B0EE
0001B9EE
0001C2EE
0001CBEE
0001D4EE
0001DDEE
0001E6EE
0001EFEE
0001F8EE
000201EE
00020AEE
000213EE
00021CEE
000225EE
00022EEE
000237EE
000240EE
000249EE
000252EE
00025BEE
000264EE
00026DEE
000276EE
00027FEE
000774F0
0007C1AD
00080E6A
00085B27
0008A7E4
0008F4A1
0009415E
00098E1B
00140864
00157728
00179D63
0017E0B9
0018567B
001A5288
001AD55A
001EEA9F
001F8795
00200C64
00200D4A
0020B148
0021B359
002206F9
002F87EA
0033365B
00347BBF
003D8891
003DF287
003E10A2
003E12EE
003E1712
003E53F9
003E58CF
00414D82
0057C4B6
00597A73
005C2393
005C4EE9
005CA455
005CF22A
005DA016
006334B2
0064DD3B
0073C4C8
00A79FB3
00AB90CE
00AD52EA
00AD6BA3
00AE699E
00B995AF
00BB52BE
00BE3BA4
00C1B37F
00C1F06B
00C4BAF2
00C6A054
00C9206E
00D92227
00D9A7E6
00E5E42F
00EA688F
00EC8290
00ECE89E
00ED2ABB
00EE0F72
00F55133
00FCEEA3

Смещения относительной последовательности байтов YOUR
YOUR

000523A8
000F916A
0011E60B
0017193C
001A7764
00221668
002DC176
002F8F7B
002FE545
0036D3BF
003A58E4
003A6DC2
0045A678
00464C99
004673FE
005382F5
0053AFB9
0055C30E
005B1812
00A7BB13
00AD833F
00AF2B08
00B37E49
00B60385
00B64BC5
00B66C47
00B9576B
00B995F1
00BF7576
00C57047
00C5FE85
00C5FF41
00CB595D
00D5D1F0
00DCAADB
00E15BFF
00ED2D24
00EDB9C4
01080CC3

Наиболее близкие совпадения.
THIS 002F87EA
YOUR 002F8F7B

THIS 00B995AF
YOUR 00B995F1

THIS 00ED2ABB
YOUR 00ED2D24

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

 

WERTA, а вдруг они как DWORD записаны ? YOUR как URYO и т.п.

 

Хорошая мысль, учтём...

 

Я искал более длинные слова типа "DROPPED", "PRIMARY". И вот их относительный поиск в woe.rsc не нашёл. Отсюда и взялся вывод, что в, скажем так, нормальной "последовательной" кодировке текста там нет.

 

Насчёт сжатых картинок подсказок в 999. Рисунки подсказок в файле лежат на правом боку в "зеркальном" виде (см. test3.png в test3.rar). По 176B1 начинается подсказка №2 (Esc, F2), а по 17EB2 он заканчивается.

Байт 5F по 176B3 отвечает за вертикальную (речь о положении на скриншотах, так-то это горизонтальная координата) координату горизонтального участка в букве W из WEAPON STATUS. Изменение этого байта на 00 соответствует верхней (крайней левой) границе скриншота.

Байт 17 по 176B6 отвечает за вертикальную координату горизонтальных участков в букве E и части буквы A из WEAPON STATUS.

Что там за байты между ними - пока не понял.

 

Да, я тоже посмотрел и поправил прежде всего три наиболее близких совпадения, -результата нет. Но и вылетов тоже не было. Пока отработал 5/39 повторов цепочки YOUR. Результата нет. Если сегодня ничего не удастся найти, то я уже просто не знаю, что делать.

Почему-то игра woe.exe не даёт дебужить по нажатию Alt+Pause. А дебуггер этот сделан почти как Софт Айс, но таких удобств, как быстро пролистать память я не нашел.

---------- Сообщение добавлено в 19:21 ---------- Предыдущее сообщение размещено в 18:57 ----------

Да PRIMARY в прямой относительной последовательности латинских символов в woe.rsc - нет. Я только что проверил. Остается только выискивать место начала брифинга в начале игры и оттуда распутывать кодировку.

Как альтернативный вариант. На брифиинге текст появляется вместе с рамкой, указывающей объект. Так вот может быть текст брифинга - это графика как и подсказки HUD. А вот диалоги с NPC уже текст. Сейчас найди диалог с первым встреченным NPC.


Ну, и ещё мысля... Ведь если у них есть RLE, то и сами тексты, да и вообще весь игровой текст они могут представлять сжатым растром! Но это можно проверить, испортив несколько символов в фонте. Там мы точно установим в какой форме в игре присутствуют тексты! Неудачи с поиском цепочек говорят, что очень вероятно, что искомого текста ВООБЩЕ НЕТ! - он может лежать в сжатом графическом представлении.

---------- Сообщение добавлено в 19:26 ---------- Предыдущее сообщение размещено в 19:21 ----------

Относительной цепочки OTHERS не найдено в woe.rsc

 

Давно уже проверено. Брифинги - точно текст. И путём порчи шрифта подтверждается, и в памяти они есть http://www.old-games.ru/forum/showthread.php?p=1009569#post1009569
Т.е. версию о графических брифингах и диалогах необходимо отбросить.

 

Vladimir 777, я посмотрел test3.png. Это непонятное RLE. Да, этот участок точно отвечает за графический хинт.
В woe.rsc начало этого места 0072B35A
Правил байт прямо в woe.rsc
0072B36C 03->01 по картинке пошли голубые крапинки. Правил другие байты значения которых возле 00h, и были вертикальные полосы и еще большее ухудшение изображения. Верт. полосы, - это подтверждает RLE (картинка повернута в памяти на 90 гр.). Буду пробовать дальше понять прямой правкой байтов и просмотром результата. В любом случае, и эти картинки должны быть переведены.

---------- Сообщение добавлено в 22:14 ---------- Предыдущее сообщение размещено в 20:33 ----------

Ещё одна хорошая мысль. Также относительным поиском можно найти следы от пробелов в текстах. Выбрать опорную строку, в которой довольно много пробелов. И пройтись по всем возможным значениям пробелов от 00 до FF, так чтобы они совпали с заранее известным паттерном взаимного расположения пробелов в опорной строке. Как доп. условие можно потребовать, чтобы с пробелами два соседние байта обязательно были не равны значению пробела. Это подтвердит/опровергнет следующее:
1) Сжатия текста нет/есть
2) Текст кодируется одним байтом/цепочкой байт

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

 

а у меня даёт.. по крайней мере фризит процесс. если ты про DosBox Debugger. я версию 0.74 использовал. просмотреть память - сделать дамп и смотреть в WinHex. + я как понял есть ещё версия DosBox Heavy Debugger - с cpu-логом (из которого можно выловить и стек) и с Memory breakpoints - как раз то что тут было бы ОЧЕНЬ нужно. правда, бинарников я не нашёл, но т.к. сорцы GPL то особые энтузиасты могу попробовать скомпилить их сами..

 

плохо искал...
Всё тут.
http://www.vogons.org/viewtopic.php?f=32&t=7323&sid=5534fc91c6f541954052aca974cf7124

они есть в 0.74. Команда BPLM линейный адрес + 14 байт.
Впрочем это описано в указанной мной теме на вогонсах.

 

странно, в той теме я нашёл только 2 дохлых ссылки на 0,72 и 0,73 (heavy)..

так попробуй её!

 

Zolimax, так работает же !

 

Примененная кодировка в игре (00-А, 01-В, 02-С...) очень удобна для битового сжатия текста. Сделал свой анализатор. Проверил файлы 000 и 999 для длины символа 5,6,7 бит. Результата нет. Варианты перебора - 2N (N - число битов). N битовых смещений и 2 варианта чтения битов (прямой и обратный порядок). Прибавлял к результату 41h - безрезультатно. Проверял поиском слов HERE, THIS. Хотя был один подозрительный момент с битовой длиной 5 (смещение 3) порядок следования битов - не помню. Там я недалеко друг от друга находил HERE, CARD, KILL (файл 000). Но это может быть совпадением. Похоже. что битового сжатия не использовали.

 

WERTA, надеюсь, ты анализировал общий байтовый поток, а не отдельные байты? Поскольку надо учитывать, что при битовом сжатии данные идут вот так:
[AAAAAABB][BBBBCCCC][CCDDDDDD] (для длины байта символа 6 бит)
а не так:
[AAAAAA00][BBBBBB00][CCCCCC00]
иначе в нём нет смысла.

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

 

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

 

Анализ файлов WRATH OF EARTH

Универсальный разметчик границ между блоками данных в картах и др ресурсах – 00 00 FF

Проверил на битовое сжатие текстов файл woe.exe - результат нулевой (поиск слова HERE).

Результаты исследования за 01.08.2013
Файл 000 (смещения даны напрямую по woe.rsc, 17 386 700 Бт, 24.07.1995)

007D6FE6: начало чего-то (задник?-нет)
---
007D7593: начало чего-то (это задник!)
007D75D5: 5F – порча задника
007D7FD7: 50 CA CA CA 50 – порча задника
---
007DA037: начало чего-то?,в явном виде нет реакции на правки
007DA113: 50 50 50 - привело к изменению текста в брифинге первого уровня, но этот текст был куском из диалогов с NPC второго уровня. И грузился второй уровень, а потом вылет.
---
007DAD6F: – конец файла 000 в woe.rsc
=====================================
007DA111: 20h - горячо и обжигает! Слово в первом брифинге OBJECTIVE
Родной байт со значением 20h даёт нам букву E
Замена родного 20h на 1Eh даёт нам темный экран брифинга+crash
Замена родного 20h на 1Fh даёт нам темный экран брифинга
Замена родного 20h на 21h даёт нам букву U - OBJECTIVU
Замена родного 20h на 22h даёт нам букву ! - OBJECTIV!
Замена родного 20h на 23h даёт крапинки после этого места
Замена родного 20h на 24h даёт крапинки после этого места
Замена родного 20h на 30h даёт нам темный экран брифинга+пиликание

И это что-то не связанное с текстом, а больше с графикой. Слово из первого брифинга DEVELOPED при замене там же 007DA111: 21h превратилось в DEVULOPUD. А остальные буквы Е остались в порядке. Я, честно говоря, хоть и рад, что что-то удалось найти, но всё же опять в ступоре от такого результата. Пока подозрения, что это не текст, а все же некая графика, на которой кусками выводится текст.

Резюме на сегодня:
1) Задник уровня лежит в карте 000
2) Брифинг уровня (или ссылки на него) лежит в карте 000

---------- Сообщение добавлено в 15:30 ---------- Предыдущее сообщение размещено в 14:14 ----------

По багу с лифтом из 7-го уровня.
Получено путем сравнения сейвов.
В woe.rsc замена байта 000913C98 E6h -> E4h делает лифт активным и модуль лифта уже вставлен в гнездо. Я таким образом пытаюсь найти сектор, ответственный за лифт со стороны ледяных шахт.
Правленый уровень был загружен в момент завершения прохождения предыдущего через сейв. Затем я с читами сквозь карту быстро дошел до этого места.

Сравнивать сейвы - просто. Один из них будет чуть больше размером, даже если вы сохранились не сходя с места. Затем обрезайте излишек и сравнивайте в HEX Workshop. Обычно самые первые разницы и будут искомыми изменениями на карте.

Лифт работает как телепорт. Я точно знаю координаты точки куда мы попадаем сразу после лифта в ледяные шахты.
это X5984 Y3680 (HEX = X1760 Y0F60)
при делении на 64 получаем
X номер сектора 5Dh +(offset 20h) 5D20 или 205D
Y номер сектора 39h + (offset 20h) 3920 или 2039

Учитывая, что смещение по сектору меняется от 00h до 3Fh, значение смещения 20h как раз является серединой сектора, тогда можно еще искать либо 005D и 0039 либо 5D39. Я искал рядом всевозможные сочетания этих значений байтов и ничего рядом не находил. чтобы это было вместе в карте 006.

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

И еще, у сектора за стены отвечает только одна текстура. Тут нету разделения N,W,E,S. Это упрощает структуру. По крайней мере один сектор я знаю и место номера текстуры стены тоже знаю.

 

Определенно сегодня «прёт»…

Еще одна буква.
Это сообщение от оператора с зеленой мордой на пути к бесполезному выжившему NPC. После момента начала уровня идите прямо затем будет поворот к двери в здание направо.
Замена 007DA135: 20h->21 дает следующее:
После прохождения точки (X1938, Y6993) оператор сообщит
DETECTING HUMANS TO THE 3ORTH OF YOUR CURRENT LOCATION
Буква N стала 3

Похоже, что все таки битовое сжатие. Почему же я не нашел этого? Сейчас выясню.

 

WERTA, а если предположить, что в коде символа использовано по 7 бит на символ и байты сдвинуты друг в друга, а потом уже ужаты чем то.

 

Да это что-то химичат с битами

Замена 007DA136: D0h->00 дает следующее:
После прохождения точки (X1938, Y6993) оператор сообщит
DETECTING HUMANS TO THE AORTH OF YOUR CURRENT LOCATION

Замена 007DA136: D0h->10 дает следующее:
После прохождения точки (X1938, Y6993) оператор сообщит
DETECTING HUMANS TO THE BORTH OF YOUR CURRENT LOCATION

---------- Сообщение добавлено в 18:08 ---------- Предыдущее сообщение размещено в 18:05 ----------

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

 

DETECTING HUMANS TO THE NORTH OF YOUR CURRENT LOCATION(54 CHARS)
Интервал строки 007DA121–007DA151

Код:

C6 23 80 20 9C EC 0C FD 03 85 25 00 D0 93 F4 27 23 09 81 E6 20 D0 70 46 B6 FD 07 01 5F A1 80 70 50 22 FD 01 5A 02 33 E0 9B F6 88 02 00 53 C1 C0 D9

49 байт.
Иногда правки дают глюки и крэши. Старайтесь править байты так, чтобы крайние биты при битовых переходах 0-1 и 1-0 не изменялись и были равны 1 до и после правки. Например 7->5, D->F. Но это не строго. Очень удобно править байты D0 70. Ноль не трогайте, а меняйте первую тетраду байта.