Reverse Engineering

[Crazy Daver]

В этой теме я предлагаю заниматься исследованием исходного кода и структур файлов игр серии Dangerous Dave.

 

[Crazy Daver]

Нарыл интересную структуру в исполнимом файле:

word sprleft
word sprright
word mode
word delay
word xoff
word yoff
word *thinkfunc
word *colfunc
word *drawfunc
word *next

Структура, вернее связные списки таких структур находятся по смещению 27A90, сразу за таблицей тайлов дверей, найденной Crazy Daver.

Этот список представляет собой все состояния всех объектов и содержит указатели на функции обеспечивающие смену состояний.

В общем этот список имеет прямое отношение к игровой логике. Если кому инетерсно, то с ним можно делать разное, например неисчезающий дым из ствола при стрельбе вверх делается заменой нулевого байта по адресу 27D37 на байт 0xA.

 

Я тоже недавно нашёл эту структуру. Она является ранней версией Action Format, который используется в DD3 и DD4.

 

В данный момент мною разобраны практически все служебные функции и около 30% игровой логики. В общем приглашаю всех желающих к дальнейшей разработке.

 

Я уже некоторое время исследую exe файл DD2. Уже нашёл многое из игровой логики: функции игровых объектов (поведение, проверка столкновений, анимация...), игровые переменные и структуры данных. 

Надо как-то объединить собранные нами данные. В каком виде находятся твои наработки?

Какие, кстати, программы используешь для исследования? Лично я пользуюсь связкой IDA + IDADOS Plugin (плагин, позволяющий в IDA Pro в качестве отладчика использовать DosBox).

Изменено 30 июня, 2014 пользователем Crazy Daver

[viiri]

Я тоже недавно нашёл эту структуру. Она является ранней версией Action Format, который используется в DD3 и DD4.

 

 Именно! И похоже эта структура появилась впервые именно в Дейве.

 

Я уже некоторое время исследую exe файл DD2. Уже нашёл многое из игровой логики: функции игровых объектов (поведение, проверка столкновений, анимация...), игровые переменные и структуры данных. 

Надо как-то объединить собранные нами данные. В каком виде находятся твои наработки?

Какие, кстати, программы используешь для исследования? Лично я пользуюсь связкой IDA + IDADOS Plugin плагин, позволяющий в IDA Pro в качестве отладчика использовать DosBox.

 

Пользуюсь IDA, Hiew и BorlandC++ 3.1 в виртуальной машине. Кроме реверсинга так же исследую код игры Hovertank 3D - в нём много общего с Дейвом, частично портировал библиотеку idlibc и менеджер памяти из исходников Hovertank 3D. На данный момент портирование отложил до лучших времён, пытаюсь воссоздать исходник оригинального досового исполнимого файла, используя исходники Кармака. Можно связаться через скайп и договориться о подробностях.

[Crazy Daver]

Кроме реверсинга так же исследую код игры Hovertank 3D - в нём много общего с Дейвом, частично портировал библиотеку idlibc и менеджер памяти из исходников Hovertank 3D.

 

Я бегло посмотрел исходники Hovertank 3D. Действительно, очень многие функции идентичны Дэйвовским.

 

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

 

С какой целью? Чтобы расширить текущие возможности модификации оригинала? Это очень трудоёмкий процесс даже при наличии оригинального компилятора и исходного кода некоторых библиотек. Стоит ли оно того? Порт с оригинальной игровой механикой, наверное, можно написать уже сейчас. 

Изменено 2 июля, 2014 пользователем Crazy Daver

[Aspirin18]

Crazy Daver, можно ли сделать скриншоты уровней, чтобы там было показано точное местоположение врагов и призов, которые разбросаны по уровням? У меня есть подозрения, что после многочисленных патчей для второго Дэйва, которые пачками клепали в Softdisk – изменения коснулись не только титульных экранов, но и чего-то ещё (например – текстур). Точно существует минимум 6 разных версий второго Дэйва – не стали бы они делать их столько штук только ради разных копирайтов и титульных экранов...

 

Отбой. Изменения не коснулись уровней, – они коснулись других файлов. На сайте я уже выложил альтернативные версии. Так, что, думаю, стоит обратить внимание на них.

Изменено 2 июля, 2014 пользователем Aspirin18

[viiri]

С какой целью? Чтобы расширить текущие возможности модификации оригинала? Это очень трудоёмкий процесс даже при наличии оригинального компилятора и исходного кода некоторых библиотек. Стоит ли оно того? Порт с оригинальной игровой механикой, наверное, можно написать уже сейчас. 

 

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

[Crazy Daver]

Всё проще. Если делать порт, то многое предстоит писать с нуля. Если делать воссоздание оригинала, то можно не отвлекаясь на низкоуровневую мишуру заниматься именно игровой логикой. 

 

Так ты хочешь переписать на С++ только подпрограммы с игровой логикой, а остальные низкоуровневые библиотеки пока оставить в виде ассемблерного кода и получить на выходе exe файл с точностью байт в байт с оригинальным Дэйвовским?

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

[viiri]

Так ты хочешь переписать на С++ только подпрограммы с игровой логикой, а остальные низкоуровневые библиотеки пока оставить в виде ассемблерного кода и получить на выходе exe файл с точностью байт в байт с оригинальным Дэйвовским?

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

Примерно как-то так и хочу. Только не C++, а C, потому что оригинал написан именно на нём. Библиотеки не совсем на ассемблере, даже скорее наоборот, ассемблера в них не так много, а взять их в готовом виде я предлагаю из Hovertank 3D - там есть всё что нужно. Если делать порт, то очень много граблей будет именно с низкоуровневой частью. Я сейчас пишу эмулятор встроенного динамика, даже не знаю что хуже, динамик или EGA-адаптер. Игровую логику же придётся раскручивать в любом случае и она нужна и для воссоздания и для порта, поэтому хотелось бы сосредоточиться именно на ней. У меня сейчас возникли вопросы по структуре объекта. Есть непонятные поля. Если есть наработки по этой теме хотелось бы обсудить.

 

ЗЫ: Если очень хочешь делать сразу порт, то предлагаю взять за основу проект omnispeak, там проделано очень много работы, но движок, используемый в Commander Keen 4-6 уже сильно ближе к Wolfenstein 3D и придётся многое адаптировать, в частности тот же встроенный динамик обрабатывается там несколько иначе, чем в DD2.

[Crazy Daver]

 Я сейчас пишу эмулятор встроенного динамика, даже не знаю что хуже, динамик или EGA-адаптер.

 

Для чего нужны все эти эмуляторы? Чтобы можно было использовать оригинальные ресурсы игры? Поясни, пожалуйста, что они из себя будут представлять.

Если делать порт, то графику можно выводить, например, через WinAPI, используя спрайты в bmp формате, звук - проигрывая wav файлы, записанные с DosBox. Это будет намного проще, а игроки разницу всё равно не заметят.

 

У меня, кстати, вопрос один возник:

Разработчики используют собственный обработчик прерывания Int8, повысив при этом частоту вызова с ~18,2 Гц до ~140 Гц (1193181 Гц / 8519). В нём изменяется счётчик тиков, от которого зависит выполнение игрового цикла и подаётся сигнал системному динамику. Как это максимально точно можно реализовать в Windows? Лучшее, что я пока нашёл это мультимедийный таймер на основе Time Stamp Counter (счётчика тактов ЦП), который работает в отдельном потоке.

 

 У меня сейчас возникли вопросы по структуре объекта. Есть непонятные поля. Если есть наработки по этой теме хотелось бы обсудить.

 

Наработки есть:

 

Номера объектов:

 

1 Dave

2 Zombie

3 Hunchback

4 Slime

5 Spider

6 Ghost(attack/ambush)

7 Werewolf

8 FlamingSkull

9 Bonus

10 Frank

11 SilasMaster

12 Delbert

13 -

14 DemonicHand

15 FireBall

16 Knife

17 SnowFlake

18 Meat/Points/ShootFire

 

Структура объекта:

 

0 Number (class) (номер объекта)

2 IsActive (обрабатывать ли объект)

4 SpriteNum

6 X_coord

8 Y_coord

10 HitBox_TopLeft_X

12 HitBox_TopLeft_Y

14 HitBox_BottomRight_X

16 HitBox_BottomRight_Y

18 HitBox_TopLeft_X_tile

20 HitBox_TopLeft_Y_tile

22 HitBox_BottomRight_X_tile

24 HitBox_BottomRight_Y_tile

26 HitBox_TopLeft_X

28 HitBox_TopLeft_Y

30 HitBox_BottomRight_X

32 HitBox_BottomRight_Y

34 HitBox_TopLeft_X_tile

36 HitBox_TopLeft_Y_tile

38 HitBox_BottomRight_X_tile

40 HitBox_BottomRight_Y_tile

42 H_step

44 V_step

46 H_speed

48 V_speed

50 TopIsSolid (находится ли сверху спрайта непроходимый блок)

52 RightIsSolid

54 BottomIsSolid

56 LeftIsSolid

58 H_Direction

60 V_Direction

62 HitToDeath (попаданий пуль до смерти)

64 ActionDelay (текущее значение задержки действия)

66 BehaviorDelay (задержка до запуска функции поведения)

68 CurrentAction (pointer)(ActionFormat)

70 HitDelay (сколько тиков показывать белый спрайт при попадании пули)

72 IsSolid (может ли попасть пуля)

74 IsGetDamage (получит ли объект урон при попадании пули (dec HitToDeath) и изменится ли спрайт на белый)

76 boss2: DemonHand1_pointer | DemonicHand: MaxSpeed | Frank: CreateSnowFlake_Delay| Spider: Start_Y_coord | Bonus: Number |  

78 boss2: DemonHand2_pointer

80 boss2: FireBallCreate_Delay

82 boss2: DemonHand2Create_delay/FireBallCreate_Delay | Werewolf: ChangeDirOnLanding (сменить направление при приземлении, если есть столкновение со стеной в прыжке).

84 boss2: DemonHand1Сreate_delay

86 SpriteCollisionFunc (pointer)

88 TileCollisionFunc (pointer)

 

поля 26-40 копия полей 10-24

поля 76-84 разные объекты используют для своих нужд по-разному.

 

viiri, по каким полям нужно пояснение?

Изменено 18 июля, 2014 пользователем Crazy Daver

[viiri]

Для чего нужны все эти эмуляторы? Чтобы можно было использовать оригинальные ресурсы игры? Поясни, пожалуйста, что они из себя будут представлять.

Если делать порт, то графику можно выводить, например, через WinAPI, используя спрайты в bmp формате, звук - проигрывая wav файлы, записанные с DosBox. Это будет намного проще, а игроки разницу всё равно не заметят.

Не всё так просто, к сожалению, и в первую очередь проблемы начнутся с юридической точки зрения. Если мы пишем движок, то обладаем полными правами на код, потому что этот код полностью придуман из головы, а если что-то было взято за основу, то всё взято из проектов с открытыми лицензиями. В общем всё законно, а вот с ресурсами уже такое не пройдёт. Как только мы сделали bmp и wav, да ещё начали распространять, да ещё и не дай бог за денежку - всё, полчища юристов бьют копытами под нашими окнами. В общем для того, чтобы всё было законно движок придётся распространять как неофициальное дополнение требующее для работы легально приобретнееной оригинальной игры.

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

Поэтому все эмуляторы нужны для более точного соответствия оригиналу, вдруг мне не нравится эмуляция динамика Досбоксом?

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

 

У меня, кстати, вопрос один возник:

Разработчики используют собственный обработчик прерывания Int8, повысив при этом частоту вызова с ~18,2 Гц до ~140 Гц (1193181 Гц / 8519). В нём изменяется счётчик тиков, от которого зависит выполнение игрового цикла и подаётся сигнал системному динамику. Как это максимально точно можно реализовать в Windows? Лучшее, что я пока нашёл это мультимедийный таймер на основе Time Stamp Counter (счётчика тактов ЦП), который работает в отдельном потоке.

Этот вопрос, как ни странно, очень тесно связан с эмуляцией динамика. В IBM-совместимых компьютерах в качестве системного таймера использовалась микросхема Intel 8253. Обслуживала она три независимых счётчика, первый, точнее нулевой - это системный таймер, а третий (второй) управлял динамиком.

Этот таймер реализован мной в эмуляторе динамика. Про систему Windows сказать не смогу - она мне не интересна.

Я пишу порт с использованием библиотеки SDL (под Windows она тоже есть) и в ней работа со звуком реализована именно в отдельном потоке. Звуковая подсистема SDL подразумевает, что программист объявляет некую функцию обратного вызова, которая заполняет буффер предназначенный для звуковой карты и которую SDL дёргает каждый раз при исчерпании буффера. Так как частоты таймера, значение делителя и частота дискретизации мне известна, я могу пересчитать частоту таймера в количество отсчётов звуковой карты, по истечении которых мне нужно обновить системный таймер. Как-то так.

поля 26-40 копия полей 10-24

поля 76-84 разные объекты используют для своих нужд по-разному.

 

viiri, по каким полям нужно пояснение?

Охрененть!!!!! Все 90 байт структуры!!!! КАК???? Я на некоторых из них мозг свернул!!!!

 

У меня вопросы по копии хитбоксов, зачем она? И координаты хитбоксов, есть координаты пиксельные, есть округлённые до тайлов, собственно зачем вторые?

И интересуют поля 42 H_step и 44 V_step - что они из себя представляют?

 

ЗЫ: Расскажи про свои планы по игре? Хочешь сделать клон, но с оригинальной механикой?

[Crazy Daver]

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

 

А как же идентичные функции поведения монстров?

 

Охрененть!!!!! Все 90 байт структуры!!!! КАК???? Я на некоторых из них мозг свернул!!!!

 

С этой структурой проблем, как ни странно, почти не возникло, потихоньку назначение всех полей определил.

 

У меня вопросы по копии хитбоксов, зачем она?

 

Копии хитбоксов толком нигде не используются. Используются только поля 34-40 в процедурах проверки проходимости тайлов. 

 

И координаты хитбоксов, есть координаты пиксельные, есть округлённые до тайлов, собственно зачем вторые?

 

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

 

И интересуют поля 42 H_step и 44 V_step - что они из себя представляют?

 

H_step и V_step это значения того, на сколько нужно изменить текущие координаты X и Y соответственно. Вот пример вычисления:

mov     ax, H_Speed (H_Speed из структуры Action)
imul    H_Dir (left=-1, right=1)
mov     H_Step, ax

mov     ax, H_Step
imul    GameTick (GameTick - количество тиков, которое нужно сделать)
mov     H_Step, ax

mov     ax, H_Step
add     X_Coord, ax 

ЗЫ: Расскажи про свои планы по игре? Хочешь сделать клон, но с оригинальной механикой?

 

Пока что демку с оригинальной механикой, а там как пойдёт. Сейчас начал потихоньку переписывать игровую логику на Delphi. 

[viiri]

А как же идентичные функции поведения монстров?

Идентичные, да не совсем! Мы же не воровали чужие исходники! Мы пишем свои функции, которые по-своему реализуют похожее поведение. Реверсинг хоть и немного скользкая тема, но кто докажет, что мы не измеряли линейкой и секундомером события происходящие в игре?

 

С этой структурой проблем, как ни странно, почти не возникло, потихоньку назначение всех полей определил.

В моих наработках есть небольшие расхождения по этой структуре. Попозже соберу различия и покажу.

Нет. Всё точно так же. Сам ошибся.

 

Копии хитбоксов толком нигде не используются. Используются только поля 34-40 в процедурах проверки проходимости тайлов. 

 

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

Ага, нашёл. Спасибо! 

 

H_step и V_step это значения того, на сколько нужно изменить текущие координаты X и Y соответственно.

У меня названия немного другие и ещё перепутаны были пары velX, velY и deltaX, deltaY

 

Пока что демку с оригинальной механикой, а там как пойдёт. Сейчас начал потихоньку переписывать игровую логику на Delphi.

Связаться бы и обменяться материалами. Демку можно попробовать на love2d сделать, у меня уже есть наброски. Delphi не кросплатформенное решение, не хочется ограничиваться поддержкой только одной платформы.

Изменено 21 июля, 2014 пользователем viiri

[viiri]

Нашёл интересное отличие в структуре спрайта от других игр серии:

word width
word height
word offset
word location
word cliprectX1
word cliprectY1
word cliprectX2
word cliprectY2
word name[5]
word planesize
word xoff
word off

Имя спрайта по идее должно быть 12 байт, но в игре последние два байта имени при загрузке спрайта в памяти перезаписываются размером плана.

[viiri]

Тут практически полностью дизассемблированный Дейв (АХТУНГ! ТАМ МОГУТ БЫТЬ ОШИБКИ И НЕТОЧНОСТИ!):

https://cloud.mail.ru/public/0de8da509951/davedis.zip

Тут исполнимый файл с начальными наработками воссоздания Дейва на базе исходников Hovertank 3D (Две заставки + обработка горячих клавиш, исходники чуть позже добавлю):

https://cloud.mail.ru/public/896bfc73bf8e/hovdd2.zip

 

[viiri]

Наработки на базе движка love2d. Исходник:

https://cloud.mail.ru/public/5dc6c552afe8/dave.love

Бинарник под винды:

https://cloud.mail.ru/public/5261c3245580/dave.zip

 

Реализован список объектов, список состояний и частично логика зомби и игрока.

Стрелки влево-вправо - задание направления игроку, "d" - вывод отладки. Игрок при столковении со стеной медитирует в пассивном состоянии.

[Crazy Daver]

Я решил написать свой порт Дейва. Это будет нечто среднее между тем, что планировали создать Харч и viiri. 

Вся игровая механика и поведения монстров будут оригинальными (дизассемблированный код будет переписан в ООП на другом языке), а низкоуровневые функции (вывод графики, звука...) будут реализованы современными средствами, без эмуляции.

Будет возможность легко изменять ресурсы игры (спрайты, звуки, тайлы, уровни). Для создания уровней будет полностью переписан мой старый редактор карт QuaDD c Delphi на Qt (см. ниже).

 

Порт уже потихоньку создаётся. Для написания я использую Qt (кроссплатформенный фреймворк для С++), поэтому порт можно будет создать сразу для нескольких платформ (Windows, Linux, Mac).

 

[Aspirin18]

Вот, какой-то человек собрался портировать первого Дэйва на Sega Mega Drive. Пишет статьи и ведёт что-то вроде блога по разработке. Текст, сам по себе, неплохо переводится в Google Translate. Можете почитать, если интересно и это как-то поможет делу.

Первая ссылка

Вторая ссылка

Третья ссылка

[Харч]

Я решил написать свой порт Дейва. Это будет нечто среднее между тем, что планировали создать Харч и viiri. 

Вся игровая механика и поведения монстров будут оригинальными (дизассемблированный код будет переписан в ООП на другом языке), а низкоуровневые функции (вывод графики, звука...) будут реализованы современными средствами, без эмуляции.

Будет возможность легко изменять ресурсы игры (спрайты, звуки, тайлы, уровни). Для создания уровней будет полностью переписан мой старый редактор карт QuaDD c Delphi на Qt (см. ниже).

 

Порт уже потихоньку создаётся. Для написания я использую Qt (кроссплатформенный фреймворк для С++), поэтому порт можно будет создать сразу для нескольких платформ (Windows, Linux, Mac).

 

И как успехи? Я свой порт думаю тоже перенести на QT для того, чтобы перенести потом на android, недавно немного для этого переписал графическую составляющую. Но пока не перенёс. На самом деле, лучше чтобы был один порт, который будет хорошим и качественным во всём. Могу свой больше не делать, если смысла нет. Да и смысла в большом количестве почти однотипных портов нет

[Crazy Daver]

Никак. Тогда всё заглохло, успел только перенести из ассемблера на с++ основную часть логики (но он остался не в рабочем состоянии)) .
Год назад решил переписать свой старый редактор карт на Qt, только сделать его максимально универсальным (под любые подобные игры). В процессе продумывания архитектуры всё переросло в мысли о простеньком игровом движке со своим объектно-ориентированным скриптовым языком. Дальше я очень увлекся проектированием языка и уходил в более глубокие области и всё дальше от Дэйва, чем и сейчас занимаюсь.
Если и возьмусь когда-нибудь за него, то очень, очень не скоро. Поэтому продолжай делать свой порт.

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

[Харч]

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

[Aspirin18]

Спросил у Frenkel Smejeirs (наш зарубежный коллега) о чит-кодах в Дэйвах на Apple II - существуют ли такие? Он ответил вот что:

Я не думаю, что в этих играх есть читы.

Я только посмотрел в роме Dangerous Dave Returns с помощью шестнадцатеричного редактора и не нашел таких строк, как «Режим бога» или «Перейти на какой-то уровень», или что-нибудь еще интересное.

Я также не смог найти читы в компьютерной версии Dangerous Dave. Было какое-то время, но я помню, что я искал эти строки в этой версии, и я ничего не мог найти. Я также дисамблировал игру, чтобы посмотреть, содержит ли она код для некоторых специальных комбинаций клавиш, и я не смог найти ничего особенного.

Я полагаю, что вставлять читы в игры было делом Джона Кармака, а не Джона Ромеро. Я имею в виду, что компьютерные версии Catacomb и Dangerous Dave были выпущены на одном диске, и только в Catacomb есть читы.

Frenkel

[Харч]

Краткие новости по моему ремейку: перенесён на SFML, практически полный функционал оригинала включён. Также много нововведений с дополнительными возможностями. Подробности на гитхабе и группе ВК.

Изменено 28 декабря, 2021 пользователем Харч