Сразу хочу оговориться. Это не описание алгоритмов, применяемых для сжатия графики на Сеге. Да и просто не может быть такого документа в природе по той простой причине, что в каждую игру разработчики вносят нечто своё. В данном документе я попробую описать как лично я взламываю игры.
Воспоминания.
Давным-давно играл я на приставке в одну игру. Очень она мне тогда понравилась. Я, можно сказать, просто фанател от неё. Время прошло, многое изменилось... А однажды попалась мне на глаза в одном журнале. Было это года 2 назад. Вот тогда я и узнал про эмуляцию. Зашёл на сайт, накачал эмуляторов, почти в тот же день, к превеликой радости своей, скачал ту самую игру... И был на том сайте форум, который я изредка почитывал. Помню точно, как я нашёл одну ссылку. Помню в чьём-то сообщении на том форуме была подпись: "Мы переведём этот мир" :) и адрес. Так я узнал про "Шедевр"... Совсем немного полазив по сайту, я уже понял чего я хочу. Я хочу перевести мою любимую игру The Jungle Book...
На пути к цели.
Ужасно заинтересовавшись темой эмуляции, я тут же начал искать информацию по железу Сеги. Нашёл я тогда очень много. Теперь же могу сказать, чего в принципе достаточно для даже самостоятельного постижения этой нехитрой науки:
SEGA2.DOC Самый полный документ по железу Сеги, который я только видел. Имеющейся здесь информации на самом деле достаточно, чтобы даже написать свою программу для Сеги (боюсь использовать слово "игра" :) Поначалу мне так не казалось, но немного практики - и понимаешь, что это действительно так. Оговорюсь, что здесь предполагается знание Ассемблера (хотя бы PC-шного).
Какая-нибудь дока по инструкциям процессора Motorola 68000. Лично мне очень понравилась INSTRSET.TXT.
Хотите верьте, хотите нет. Больше ничего не нужно. Это было необходимо для изучения. Для работы понадобится ещё дебаггер\дизассемблер. Тогда, когда я только начинал, у меня был только кривоватый дизасм от Charles Dotty. Некоторые инструкции он отображал неверно. Отчасти поэтому, я решил написать свой. Писался он целую неделю. Трудностью было полное отсутствие документации по полям КОПа :)
Непосредственно методика.
Так, меня понесло совсем не в ту степь... Теперь опишу непосредственно мой алгоритм взлома игры. Небольшое уточнение - я не пользуюсь прогами типа ROM Artist, Gold Finger, Thingy98 (поправьте, если не так указал название) для перевода по той простой причине, что я не знал о существовании таких прог и поэтому сам писал свои редакторы графики, текста и т.д.
Первое, что необходимо - перевести РОМ в формат *.BIN, если он в формате *.SMD (да, забыл сказать, пока что я взламывал игры только для Сеги :)
Следующий этап один из самых сложных. Цель взлома (хоть слово и неподходящее) - найти запакованный ресурс (текст/графика) и процедуру в коде игры, их распаковывающую. Для этого я поступаю следующим образом. Если в РОМ записать поверх чего-нибудь набор байт, то где-то это да скажется. Если записали поверх текста - ясен пень, заменится текст. Если поверх графики - графика. Если поверх кода - игра повиснет :). Для тех кто ещё не понял - поясняю. Я разбиваю РОМ сначала на большие куски, скажем, по 200кб и по очереди пишу в них мусор, а затем запускаю и смотрю то место, где должны выводится запакованные текст/графика. Те блоки, записывая в которые ничего не меняется, я отбрасываю. Постепенно сужая круг поиска находим нужный ресурс.
Здесь на меня, возможно, многие накинутся, скажут, что так искать слишком долго и сложно. Что же - если кто-то может предложить более рациональный способ - рад послушать. Дело в том, что ресурс запакован, т.е. уменьшен в размере, и никакими просмотрщиками графики вы его не найдёте. Сидеть и дебажить игру - слишком долго это раз, откуда же узнать в какой момент этот ресурс загружается это два, и нет полноценного дебаггера это три. Других идей у меня нет.
Место в РОМе с ресурсом найдено - что же дальше? Дальше ищем процедуру распаковки. В большинстве игр сам код игры идёт в первых 100-200 кб, а остальное - графика, текст, музыка и пр. Так вот нужно эти первые килобайт 200 дизассемблировать. Хотя можно и всю игру, но в большинстве случаев это излишне. Первые четыре мегабайта в адресном пространстве Сеги - это сам РОМ. Т.е. РОМ виден целиком, а не через окошко, а адресом любого байта будет смещение от начала РОМа, т.е. файла. Так вот - положим, на предыдущем этапе мы выяснили, что если в РОМ писать скажем приблизительно начиная с 1000000-го байта, т.е. 0x000F4240 в шеснадцатиричной системе счисления (тем кто не знает что это такое будет, конечно, трудновато). Раз при записи в это место появляются соответствующие глюки, значит тут нужный ресурс и значит игра должна сюда обращаться. Как? Очень просто. Нужно поискать этот адрес. Конечно мы весьма приблизительно искали наш ресурс и он вряд ли будет начинаться именно с 0x000F4240, поэтому поищем в дизассемблированном тексте адрес по старшим разрядам - $000F42. В конце концов мы найдём что-нибудь в духе:
lea $000F422E,A0
lea $FFFF4000,A1
jsr $xxxxxxxx
Здесь в первой строке в один адресный регистр помещается адрес нашего ресурса. Во второй строке - в другой регистр помещается адрес буфера для распаковки (оперативная память в Сеге начинается с адреса $00FF0000 по $00FFFFFF, а затем блоками по 64кб повторяется до $FFFFFFFF). В третьей строке вызывается наша искомая процедура распаковки. Кстати, хочу заметить, что именно такие вызовы я и встречал, т.е. в регистры A0 и A1 помещаются адреса ресурса и буфера, а потом вызывается процедура распаковки.
Следующий этап не легче. Процедура найдена. Нужно понять как она распаковывает, чтобы изменить ресурс и запаковать его таким же образом, что и исходный. В Сеге всего 64кб оперативной памяти, поэтому слишком навёрнутых алгоритмов в ней я ещё не встречал. Я имею в виду такие, чтобы тратилась оперативная память на распаковку (строились деревья, цепочки и пр.). Обычно запакованная графика представляет собой последовательность из блоков: ([Код Операции][Данные]),([Код Операции][Данные]),....,([Код Операции][Данные]). Предположим, что в картинке идут байты: 14,2,3,3,3,3,3,12,11,3,3,12,11. За счёт чего её можно сжать? В тех алгоритмах, что я встречал, графика пакуется только за счёт повторения неких кусков. Т.е. в нашем примере во-первых сначала идёт подряд несколько троек, а во-вторых - повторяется последовательность 3,3,12,11. Значит в запакованном виде это будет выглядеть так: ([Добавить][2 байта][14,2]),([Заполнить][5 байт][3]), ([Добавить][2 байта][12,11]),([Повторить][4 байта][на 4 байта раньше]). Это обобщённый вид. Но принцип везде один и тот же - пакуется за счёт того, что либо несколько раз подряд идёт один и тот же байт (тогда помещается код [Заполнить][Количество][Сам байт]), либо цепочка байт уже встречалась некоторое количество байт назад ([Повторить][Количество][Смещение]), либо несколько байт ещё не встречались ([Добавить][Количество][b1,b2,b3,..,bn]). Повторяю - принцип один и тот же. Различия в том как в запакованном ресурсе будут обозначаться Коды Операций. Например в Beyond Oasis есть 2 алгоритма паковки. В первом - в одном байте хранится Код Операции, потом идёт количество, а затем данные, т.е. всё байтами. В другом же алгоритме (а похоже таких большинство) байтами идут только сами данные, а Коды Операций и размер блоков идёт в отдельном потоке битов.
Вот на этом этапе и предстоит понять как идут КОПы и данные в запакованном ресурсе. По сути можно только один раз написать паковщик для одной игры (чтобы он умел находить эти повторяющиеся блоки, их размер, смещение от текущей позиции и т.д.), и его можно будет использовать для других игр. Естественно нужно будет только переписать те места, где эта информация - КОП, размер, смещение записываются в запакованный поток.
Ещё один геморройный пункт - написание самого паковщика. Скорее всего самым тяжёлым в первый раз будет именно этот пункт. Если после того как вы всё сделаете вам захочется сломать ещё одну игрушку :), то будет уже значительно проще, т.к. будет необходимо лишь понять как в новом алгоритме записываются вышеуказанные последовательности, и слегка модифицировать паковщик.
1843 Прочтений • [Кое-что о сжатии графики в играх] [07.08.2012] [Комментариев: 0]
Vova
