Что такое "прокрутка в сторону" от старых игр?

Я слышал, что старые игры с прокруткой в ​​аркадной игре использовали специфический взлом программирования, позволяющий прокручивать прокрутку.

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

Этот подход работает только тогда, когда фон не изменяется (и, следовательно, большинство пикселей экрана остаются неподвижными).

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

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

IIRC он использовался во многих старых играх, в основном 80 бит'-вверх, а также в демонстрационных постановках

Можете ли вы описать эту технику и назовите ее автора?

ОТВЕТЫ

Ответ 1

Я написал игры для хорошего старого C64, который делает именно это. И в основном есть две вещи, о которых нужно знать:

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

  • Следующее, что нужно отметить, это поддержка аппаратного обеспечения для перемещения всего экрана на семь пикселей. Обратите внимание, что это никоим образом не повлияло на графику - это просто сделало все, что было отправлено на телевизор, немного смещено.

So 2) позволили действительно сгладить прокрутку на 7 пикселей. Затем вы перемещали каждый символ вокруг - для полного экрана было ровно 1000 байт, с которыми мог справиться компьютер, и в то же время вы переместили регистр прокрутки на 7 пикселей. 8 - 7 = 1 означает, что он выглядел так, будто вы прокручивали еще один пиксель... и затем он просто продолжался именно так. Итак, 1) и 2) в сочетании сделали иллюзию истинной гладкой прокрутки!

После этого в игру вступила третья вещь: растровые прерывания. Это означает, что процессор получает прерывание, когда телевизор/монитор собирался начать рисовать линию сканирования в определенном месте. Этот метод позволил создать разделенный экран, чтобы вам не требовалось прокручивать весь экран в отличие от моего первого описания.

И чтобы быть еще более подробными: даже если вы не хотели разделить экран, растровое прерывание было очень важно в любом случае: потому что это было так же важно, как и сегодня (но сегодня структура скрывает это от вас), чтобы обновить экран в нужное время. Изменение "регистра прокрутки" при обновлении ТВ/монитора в любом месте видимой области вызовет эффект, называемый "разрывом", - где вы четко заметите, что две части экрана синхронизированы один пиксель друг с другом.

Что еще можно сказать? Ну, техника с переделанными наборами символов позволила сделать некоторые анимации очень легко. Например, конвейеры и зубчатые колеса и прочее могут быть анимированы, постоянно меняя внешний вид "персонажей", представляющих их на экране. Таким образом, конвейер, охватывающий всю ширину экрана, может выглядеть так, как он вращается повсюду, просто изменяя один байт в карте символов.

Ответ 2

Я сделал что-то подобное еще в 90-х годах, используя два разных подхода.

Первый из них связан с "окном", который поддерживался стандартом VESA SVGA. Некоторые карты реализованы правильно. В принципе, если у вас есть буфер кадров/видеопамять больше, чем отображаемая область, вы можете нарисовать большое растровое изображение и дать системные координаты для окна в той области, которую вы хотите отобразить. Изменяя эти координаты, вы можете прокручивать их, не перезаписывая буфер кадра.

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

Я нашел этот старый код ассемблера 286 (на функционирующей 17-летней гибкой дискете!), который скопировал экран с размером экрана 64000 байт (320x200) со страницы вне экрана в видео-буфер:

  Procedure flip; assembler;
    { This copies the entire screen at "source" to destination }
    asm
      push    ds
      mov     ax, [Dest]
      mov     es, ax
      mov     ax, [Source]
      mov     ds, ax
      xor     si, si
      xor     di, di
      mov     cx, 32000
      rep     movsw
      pop     ds
    end;

rep movsw переместил слова CX (в этом случае в этом случае это слово составляет два байта). Это было очень эффективно, так как это в основном одна инструкция, которая сообщает процессору как можно быстрее перемещать все это.

Однако, если у вас был больший буфер (например, 1024 * 200 для бокового скроллера), вы могли бы просто использовать вложенный цикл и копировать одну строку пикселей за цикл. Например, в буфере шириной 1024 пикселя вы можете копировать байты:

start          count            
0+left         320
1024+left      320 
...
255*1024+left  320

где left - координата x в большом фоновом изображении, которое вы хотите начать с (в левой части экрана).

Конечно, в 16-битном режиме требуется магия и манипуляция указателями сегментов (ES, DS), чтобы получить буфер размером более 64 КБ (в действительности, несколько соседних буферов 64 тыс.), но он работал очень хорошо.

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

Ответ 3

В аркадных играх часто присутствовали настроенные видеочипы или дискретная логика, позволяющая прокручивать без необходимости работы процессора (много). Этот подход будет похож на то, что danbystrom описывал на C-64.

В основном графическое оборудование позаботилось о тонких прокручиваемых символах (или фрагментах), а затем процессор обработал замену всех фрагментов, как только регистры прокрутки достигли своего предела. В настоящее время я просматриваю плату Irem m-52, которая имеет дело с несколькими прокручивающимися фонов в аппаратном обеспечении. Схемы можно найти в Интернете.

Ответ 4

Для правильной прокрутки на Commodore Amiga мы использовали Copper для сдвига экрана вправо до 16 пикселей. Когда экран сдвинулся, мы добавили 2 байта в начальный адрес экранного буфера, а в правой части мы использовали Blitter для копирования графики из основной памяти в экранный буфер. Мы установили бы экранный буфер немного больше, чем экран, чтобы мы могли копировать графику, не видя мерцающего эффекта от копирования в правой части окна просмотра.