Как они заставили экран двигаться в Dangerous Dave?

14

Я делал игры на бейсике, когда был ребенком, и мне было любопытно, как создавалась графика в версии Dangerous Dave 1988 года, написанной на C ++; тем более, что в те дни у них не было достойных графических пакетов. Помните, как, когда Дейв достиг края экрана, весь графический экран использовался для движения влево широким движением? Я помню, как читал, что Ромеро использовал специальную технику для этого. Я давно хотел создать что-то вроде Дейва, и мне было интересно

  1. какой графический пакет / метод они использовали для Дэйва?
  2. и как заставить весь графический экран двигаться так, как он?
навигационный
источник
1
Это одна игра, о которой я вспоминаю как подарок из моего детства
Вишну
Чтобы увидеть видео этой игры в действии, чтобы увидеть эффект прокрутки, о котором говорит Нав, см. Dosgamesarchive.com/download/dangerous-dave
Тим Холт

Ответы:

18

Моя версия Dangerous Dave 1988 года была версией Apple II. Прокрутка осуществлялась путем перемещения всех байтов экрана, а затем рисования новой плитки по краю экрана - повторить 20 раз для полного сдвига экрана. Версия Apple II была написана на языке ассемблера 6502.

На ПК версии 1990 года я написал графический код на ассемблере 80x86 для всех режимов видео: CGA, EGA, VGA. Dangerous Dave PC - единственная из известных мне игр, в которой есть все 3 режима видео и которые можно переключать в любое время (F2), даже в середине прыжка!

Для быстрой прокрутки экрана все было на языке ассемблера, и я использовал аналогичную технику, которую я использовал с версией Apple II - быстро перемещать байты в видеопамяти и рисовать плитку с правой стороны. В EGA это было сложнее, потому что для быстрого выполнения действий в режиме EGA требовалось использование Latch Mode для перемещения памяти. Я помню, как преподавал Todd Replogle, как это сделать, чтобы Duke Nukem 1 был забавной игрой (медленный Duke Nukem не был бы крутым).

Код игры для Dangerous Dave PC был написан на C, в Borland C 3.0 IDE. Большая часть отладки проводилась в Turbo Debugger на 12-дюймовом янтарном мониторе, подключенном к карте Hercules.

user42604
источник
Вот это да! хорошо получить информацию от кого-то, кто действительно работал над этими видеорежимами в сборке!
Nav
@ Нав эээ ... ты на самом деле разговариваешь с самим Ромеро :-)
Джанлука Геттини
@GianlucaGhettini Ну, это пользователь с фотографией Ромеро, которая доступна в Интернете. Будет ли Джон Ромеро создать учетную запись, чтобы ответить на один вопрос? Не могу быть полностью уверен :-) Это довольно странно, что вы прокомментировали только один день после того, как я сыграл Dangerous Dave после очень очень долгого времени.
Нав
@Nav согласно его твиту здесь: twitter.com/romero/status/679769135681826817 он фактически сказал Тодду Реплоглу, как сделать плавную прокрутку EGA для Duken Nukem, что именно то, что он заявляет в этом ответе. Я сомневаюсь, что кто-то, притворяющийся им, знает об этом .. :-)
Джанлука Геттини
Эта статья подтверждает, что user42604 действительно Ромеро gamasutra.com/blogs/DavidLightbown/20170223/289955/…
mastazi
13

Ах, я помню эти методы из моих дней DOS. Перемещение видеопамяти с прокруткой для выполнения прокрутки привело бы к прерывистой прокрутке. EGA представила регистры вертикального и горизонтального панорамирования пикселей, которые можно использовать для установки источника экрана (откуда в видеопамяти видеокарта начала отображать данные). Поскольку копирование памяти не происходит, это происходит практически мгновенно и может использоваться для очень плавной и быстрой попиксельной прокрутки на EGA и VGA, если у вас есть прямой доступ к аппаратным регистрам. Большинство скроллеров в DOS использовали бы это, и эта часть кода, вероятно, была бы написана на ассемблере для прямого доступа к аппаратным регистрам. Эти методы на самом деле больше не действительны. Чтобы достичь аналогичного эффекта сейчас, Я думаю, что на современном графическом оборудовании вы могли бы сделать это достаточно быстро, просто перерисовывая весь экран в каждом кадре. Другой метод, который я могу придумать, - это использование OpenGL или DirectX и рендеринг текстуры в квадрат, в два раза превышающий ширину экрана, и его перемещение. Хотя это не так весело, как манипулирование аппаратными регистрами :)

madeyes
источник
3
«Почему-то это не так весело, как манипулирование аппаратными регистрами, хотя :)» - правда :)
Nav
4

Редактировать: Вот ссылка на статью доктора Доббса, которая обсуждает боковую прокрутку. Это может быть метод, используемый для этого эффекта.

http://www.drdobbs.com/184408045


Трудно судить, как именно это было сделано, но учтите, что эта игра была написана для очень специфической спецификации оборудования - DOS с видеокартой EGA (640x480 пикселей). Код, вероятно, выполняет некоторые довольно низкоуровневые манипуляции с видеопамятью, чтобы прокрутка происходила плавно.

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

http://www.phatcode.net/res/224/files/html/index.html

Тим Холт
источник
Эта игра будет использовать видео режим 320x240.
Skizz
Skizz Я тоже так думал, но нашел несколько скриншотов игры с разрешением 640x400 - разрешение EGA. Были разные версии игры, и я предполагаю, что ранние были 320x200.
Тим Холт
4

Metagun (игра, разработанная Markus aka Notch aka MineCraft guy) имеет то же чувство прокрутки, что и вы.

Игра с открытым исходным кодом и написана на Java.

Надеюсь, вы узнаете, посмотрев на код.

は る と
источник
1
И на случай, если вы захотите увидеть, как он делает игру: youtube.com/watch?v=ZV-AFnCkRLY
と る と
1
-1, хотя выглядит одинаково, явно не использует один и тот же метод.
2
Я знаю, что это не тот метод, который Джон Ромеро использовал в 1988 году. Но поскольку @Nav хотел создать нечто подобное, я не стал его программировать, используя Applesoft BASIC на компьютере Apple II. Код, на который я ссылался, явно выполняет ту же работу, на которую вы указали.
と る と
Спасибо Джо, но Eibx прав, что я тоже искал альтернативные пути.
Nav
2

Я могу думать о двух способах, которыми это было сделано:

  1. Грубая сила: просто нарисуйте сцену
  2. Mode-X и регистры панорамирования. Нарисуйте бит, который нужно прокрутить, и отрегулируйте регистры панорамирования, чтобы прокрутить сцену. Вам нужно будет перерисовывать верхнюю область отображения каждого кадра, но это менее трудоемкая задача, чем рисование основной игровой области. Вам не нужно будет перерисовывать нижнюю область, поскольку в аппаратном обеспечении был регистр, который заставлял бы ЦАП для видео читать с адреса 0 на заданной строке сканирования (так что нижняя область была бы по адресу 0 в ОЗУ видео и верхней начнется после нижней области) * .

Я бы, вероятно, остановился на 1), поскольку графического представления не так много, может быть какой-то самогенерируемый код, который может перетаскивать и обрезать изображения по краям. Одной из возможных техник, над которой тогда работал мой коллега, были спрайты с самозаписью, то есть данные спрайтов не были данными, это был код. Это означало, что не было никаких проверок прозрачности, и чтение данных блита было фактически свободным (это было на 386, где каждая инструкция читалась и затем декодировалась так, чтобы вместо чтения кода-> чтения данных-> записи данных это было просто чтение кода- > напиши данные). Это сработало на удивление - у нас было много огромных спрайтов на нескольких слоях параллакса со скоростью 25fps +.

Но мы говорим о Ромеро здесь, и, вероятно, происходит немного преувеличения по поводу техник.

  • Я действительно делал это в моей первой основной игре для DOS, и в некоторых аппаратных средствах была ошибка, из-за которой сброс адреса произошел слишком рано, так что у вас был бы пиксель половинной высоты между двумя секциями.
Skizz
источник