Как классические боковые скроллеры выполняли синхронизированные события и триггеры анимации?

Question

Я всегда был поражен серией Супер Марио на Сне. Я думаю, что это было сделано в сборке Z80. Но поскольку часов в реальном времени не было, как же они справлялись со всеми этими приуроченными, анимированными событиями с сборкой и без часов реального времени?

Благодаря

Answer 1

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

Поскольку это происходит с постоянной скоростью (60 раз/секунду в NTSC, 50 в PAL), большинство игр использовать это в качестве своего таймера, с кодом, который примерно соответствует этому:

void main() { 
    while(true) { 
     updateGame(); 
     updateSprites(); 
     waitForVSync(); 
    } 
} 

Очевидно, это значительно упрощено, но это то, что происходит. Некоторые игры были настолько сложными, что они занимали слишком много времени и пропускали период VSync. В этом случае они будут ждать второй VSync и, таким образом, будут работать на 30 (/ 25) FPS.

Иногда вы заметите замедление в играх NES (например). Это когда рабочая нагрузка настолько тяжелая, что ей не хватает нескольких периодов VSync в одном кадре действия.

Но да, это суть того, как выбор время работало на старых консолях (На самом деле, даже многие новые консоли и PC игры используют ту же систему, а не только старые приставки!)

Answer 2

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

wikipedia говорит, что SNES была 16-разрядной системой, поэтому это был не Z80, а 8 бит. На самом деле это говорит, что это был 65c816

http://en.wikipedia.org/wiki/Super_Nintendo_Entertainment_System

(по ссылке выше говорит о прерываниях видео синхронизации, так что я, вероятно, на правильном пути Предполагая, что вы правильно о часах реального времени)

Answer 3

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

Хороший бит заключается в том, что сигнал вертикальной синхронизации, который делает поворот пистолета от нижней части экрана до вершины, обычно связан с аппаратным прерыванием на центральном процессоре консоли и в этот самый момент , что происходит ровно 29,97 раза в секунду (почти 30 кадров в секунду), происходит в тот момент, когда данные вообще не передаются по видео, потому что требуется, чтобы луч «откидывался назад» в верхнюю часть экрана. Изменения в видеопамяти в это время будут мерцать!

Answer 4

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

В настоящее время большинство игр по-прежнему продвигают время в дискретных шагах, которые кратковременны для базовой скорости, обычно 50/60 Гц или что-то вроде 100 Гц - некоторые титры по-прежнему имеют время на основе VSync, но большинство из них просто используют регулярные таймеры для это сейчас. В настоящее время мы используем фиксированные временные параметры по нескольким причинам: во-первых, в играх обычно проводится, по меньшей мере, некоторое физическое моделирование, и очень сложно получить физическое моделирование с переменными временными параметрами стабильно - особенно в приложениях реального времени, таких как игры, где вы не может легко бросить на него больше вычислительной мощности, используя более точные методы интеграции и т. п. Во-вторых, если у вас есть какой-либо тип сетевого многопользовательского режима, вам нужно убедиться, что игра остается синхронной для всех игроков. Это почти невозможно управлять (и отлаживать), если все находятся на другом таймере и обрабатывают события с другой скоростью. Заставляя всех использовать общий временной шаг, задача на несколько порядков упрощает управление, потому что вы можете смело предположить, что два игрока, которые начинают в одинаковом состоянии и получают одинаковый вход, все равно будут находиться в идентичном состоянии через 5 секунд, даже если игроки смотрят на разные вещи или имеют разные машины, все из которых влияют на реальную частоту кадров, в которой игра проходит (и, следовательно, также скорость, с которой игра может обрабатывать события).