18 сообщений в этой теме

Опубликовано: · Жалоба

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: (изменено) · Жалоба

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

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).
Изменено пользователем Crazy Daver

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: · Жалоба

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

 

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

 

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: (изменено) · Жалоба

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

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

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

 

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

Изменено пользователем Crazy Daver

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: (изменено) · Жалоба

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

 

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

Изменено пользователем Aspirin18

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: · Жалоба

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: · Жалоба

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: · Жалоба

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: (изменено) · Жалоба

 Я сейчас пишу эмулятор встроенного динамика, даже не знаю что хуже, динамик или 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, по каким полям нужно пояснение?
Изменено пользователем Crazy Daver

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: · Жалоба

Для чего нужны все эти эмуляторы? Чтобы можно было использовать оригинальные ресурсы игры? Поясни, пожалуйста, что они из себя будут представлять.
Если делать порт, то графику можно выводить, например, через 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 - что они из себя представляют?

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: · Жалоба

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

 

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

 

Охрененть!!!!! Все 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. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: (изменено) · Жалоба

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

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

 

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

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

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

 

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

 

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

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

 

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

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

 

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

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

Изменено пользователем 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 байт, но в игре последние два байта имени при загрузке спрайта в памяти перезаписываются размером плана.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: · Жалоба

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: · Жалоба

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

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: · Жалоба

Я решил написать свой порт Дейва. Это будет нечто среднее между тем, что планировали создать Харч и viiri
Вся игровая механика и поведения монстров будут оригинальными (дизассемблированный код будет переписан в ООП на другом языке), а низкоуровневые функции (вывод графики, звука...) будут реализованы современными средствами, без эмуляции.
Будет возможность легко изменять ресурсы игры (спрайты, звуки, тайлы, уровни). Для создания уровней будет полностью переписан мой старый редактор карт QuaDD c Delphi на Qt (см. ниже).
 
Порт уже потихоньку создаётся. Для написания я использую Qt (кроссплатформенный фреймворк для С++), поэтому порт можно будет создать сразу для нескольких платформ (Windows, Linux, Mac).

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: · Жалоба

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: · Жалоба

Я решил написать свой порт Дейва. Это будет нечто среднее между тем, что планировали создать Харч и viiri
Вся игровая механика и поведения монстров будут оригинальными (дизассемблированный код будет переписан в ООП на другом языке), а низкоуровневые функции (вывод графики, звука...) будут реализованы современными средствами, без эмуляции.
Будет возможность легко изменять ресурсы игры (спрайты, звуки, тайлы, уровни). Для создания уровней будет полностью переписан мой старый редактор карт QuaDD c Delphi на Qt (см. ниже).
 
Порт уже потихоньку создаётся. Для написания я использую Qt (кроссплатформенный фреймворк для С++), поэтому порт можно будет создать сразу для нескольких платформ (Windows, Linux, Mac).

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!


Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.


Войти сейчас