Все ли игры сделаны на каждом кадре?

60

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

У меня вопрос, является ли этот метод единственным, который используется для создания анимации и игр. Кажется, это немного неэффективно. Я также не совсем понимаю, как этот метод будет работать для 3D- игр. Может ли кто-нибудь объяснить это более подробно?

Eeze
источник
Комментарии не для расширенного обсуждения; этот разговор был перенесен в чат .
Джош
Джон Кармак почти изобрел подход на ПК для выполнения полноэкранной боковой прокрутки, рисуя только тонкий вертикальный фрагмент экрана, который изменился. ПК просто не могли обновлять полноэкранный режим достаточно быстро без этой техники. Он использовал это во многих 2D играх в начале 90-х, таких как Commander Keen. Читайте "Мастера Судьбы" для получения дополнительной информации.
ясень

Ответы:

68

Очень старые игры использовали технику, при которой перерисовывались только те части кадра, которые изменились в этом кадре. Что я могу вспомнить, игра «Маленькое большое приключение» использует эту технику (1994). Но вы можете видеть, что в игре большую часть времени установлена ​​статическая камера. только когда вы выходите из видимой области, сцена перерисовывается. Если вы играете в игру, вы также заметите небольшую задержку на этом кадре. На современных графических процессорах с современными игровыми движками все изменилось. Все перерисовывается на каждом кадре. В зависимости от техники рендеринга, вещи могут быть отрисованы несколько раз. Вычислительная мощность графического процессора просто невероятно высока, если вы используете его правильно. Но повторное использование происходит. Например, движок может решить обновить карту теней только каждый 5-й кадр. Или освещение не обновляется, если нет изменений в источниках света.

Arne
источник
23
Это не просто старые игры. В EA была попытка уменьшить расход батареи ноутбука для некоторых «казуальных» игр, и одним из методов было перерисовать только части экрана. Иногда вы можете увидеть это в The Sims 3, если вы оставите камеру неподвижной, а сим будет ходить по экрану, иногда будет ошибка, когда перерисовка будет недостаточно большой, и вы увидите пиксели, оставленные позади в линии, проходящей через экран. Вам просто нужно было слегка переместить камеру, чтобы вызвать полную перерисовку, и линия исчезнет.
Кевин Фее
12
Очень старый .. 1994 ... Теперь я чувствую себя старым ...
alseether
4
@alseether старый в игровых терминах. Помните, что мы перешли от 8-битных пиксельных капель к фотореализму (в предварительно отрендеренных роликах, если не в прямом эфире) всего за 20 ~ 30 лет.
Джаред Смит
16

Нет.

По крайней мере, если вы включите старые игры 70-х годов, которые использовали векторные изображения.

Например, широко известная игра Asteroids, которая изначально была разработана для векторных дисплеев, которые представляют собой принципиально иной способ рендеринга графики на экран.

Векторные мониторы также использовались в некоторых аркадных играх конца 1970-х - середины 1980-х годов, таких как Asteroids, Tempest и Star Wars. Atarius использовал термин Quadrascan для описания технологии, используемой в игровых автоматах.

https://en.wikipedia.org/wiki/Vector_monitor

Современная графика на 100% сделана для растеризации, которая по определению записывает содержимое графического буфера на дисплей каждый кадр.

Сэнди Чепмен
источник
7
Векторные дисплеи даже не имеют «рамки».
Хоббс
2
@hobbs Правильно, что делает мой ответ по-прежнему правильным, так как ответ на вопрос "Все ли игры сделаны с прорисовкой каждого кадра?" «Нет, даже не все игры рисуются на основе фреймов».
Сэнди Чэпмен
1
однако, в более глубоком смысле, вопрос заключался в том, чтобы многократно рисовать все видимые элементы, а не только элементы, которые перемещаются, и для большинства векторных дисплеев ответ по-прежнему «да» (исключение составляет пробирка для хранения изображений)
szulat
@szulat таким образом, что это правда, но, честно говоря, он по-прежнему не тянет в промежутках, где дисплей черный. Он только обновляет видимые элементы на экране. Т.е. в астероидах это только перерисовывает корабль и оставшиеся астероиды на экране.
Сэнди Чэпмен
@ SandyChapman и на другом уровне, действительно мало различий. игра обновляет память экрана или спрайты, когда что-то меняется. в противном случае соответствующая часть дисплея остается статичной. это справедливо как для растровой, так и для векторных систем - «астероиды» обрабатывают обновление экрана из (векторной!) экранной памяти, не беспокоя процессор, аналогично тому, как аппаратное обеспечение спектра zx генерирует свой растровый видеосигнал. независимо от того, рисует ли реальный или воображаемый луч ЭЛТ полигоны или сканирует экран по фиксированной схеме, это вторично.
сулат
11

На самом низком уровне графический процессор на вашей машине действительно вычислит каждый кадр с нуля и отправит его на ваш экран. Однако вы будете подвержены этому только в том случае, если вы сами управляете этими низкоуровневыми вещами [1]. Однако любой графический (и с этим, игровой) движок будет обрабатывать эти вещи за вас, и вы можете свободно выражать сцену. с точки зрения многих объектов, которые вы могли бы изменить между кадрами, но будет постоянным.

... как этот метод будет работать для 3D-игр ...

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

[1] ... например, если вы пишете свой собственный движок [2] с чем-то вроде OpenGL. Даже в этом случае вы, вероятно, будете хранить постоянные вещи между кадрами.

[2] Что не подходит для вашего текущего уровня квалификации.

TauCraft
источник
Есть ли у вас ссылки на поддержку "графический процессор на вашей машине будет действительно вычислять каждый кадр с нуля"?
Кромстер говорит, что поддерживает Монику
@ Кромстер: Это в основном эффективность. Поскольку каждый кадр может потребовать полного вычисления, и точно неизвестно, какие именно части этого не делают, вам потребуется дорогой расчет, чтобы точно определить, какие биты могут быть сохранены. Даже если это приведет к чистому улучшению производительности, это приведет к непоследовательной частоте кадров.
MSalters
@MSalters, как это сформулировано, противоречит многим пунктам во многих ответах соседей.
Кромстер говорит, что поддерживает Монику
Я бы сказал, что утверждение «графический процессор на вашей машине действительно будет вычислять каждый кадр с нуля» технически не соответствует действительности. Графический процессор вычисляет именно то, что вы говорите. Если вы хотите, чтобы он повторно использовал предыдущий кадр, то он будет (действительно, это его по умолчанию). Многие современные игровые движки (и даже графические интерфейсы операционной системы) предпочитают начинать с нуля (где предыдущий кадр отображается только в том случае, если новый кадр не завершил рендеринг вовремя), но это не обязательно.
Ove
Я даже не уверен, что будет означать ссылку на «экран должен быть очищен», но есть ссылка на то, как кадр отображается в Doom: adriancourreges.com/blog/2016/09/09/doom-2016- графика-исследование ; не забывайте, что видеокарта умеренного класса должна обрабатывать триллион вычислений в секунду, несколько тысяч на пиксель.
pjc50
2

Краткий ответ: Нет.

Длинная история:

Когда я изучал программирование игр в школе, нас учили делать следующее:

Решите, какую частоту кадров нам нужно в игре (например, 30).

Напишите некоторый код, который добавляет 1 к счетчику для каждого интервала (33 мсек для 30 кадров в секунду). Этот код работает одновременно с игровым циклом.

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

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

Но затем многое происходит в игре, процессору предстоит проделать больше работы, и обновления состояния игры будут иметь приоритет перед рисованием на экране.

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

Все это было сделано с C ++ и без игрового движка, ни видеокарты. Все работало на одном ядре. Мы использовали несколько библиотек для 2D-графики.

user985366
источник
1
Я помню игру "Золотой топор". Когда играли в 8086, игровой процесс был медленнее и намного проще в обращении, чем в 286, например, где все шло быстрее. Просто к вашему сведению.
Акостадинов
0

Прежде чем можно сказать, «рисуют» ли видеоигры каждый кадр, сначала необходимо определить, что означает «рисовать». Конечно, существует множество видеоигр, которые не все рисуют каждый кадр, собирая растровое изображение с нуля; на самом деле, многие игровые платформы никогда не собирают полные растровые изображения вообще .

Существует несколько подходов видеоигр к генерации дисплея. В очень небольшом числе ЦПУ включает и выключает электронный луч или для каждого пикселя, или, для игр с векторным сканированием, задает координату XY каждой наносимой точки. Большинство игр, которые делают это, делают это в основном для того, чтобы продемонстрировать, что процессор достаточно быстрый. Чаще всего в играх используется аппаратное обеспечение, которое при отсутствии нагрузки на ЦП неоднократно выводило бы на дисплей некоторую комбинацию пикселей или векторов. Этот шаблон может быть получен путем последовательного считывания данных из области памяти и интерпретации каждого бита или группы битов как цвет пикселя (это называется отображением битовой карты). В некоторых случаях оборудование может считывать байт памяти для каждого 8x8, 16x16, или область другого размера дисплея, а затем используйте этот байт для выбора диапазона памяти для считывания данных пикселей (это часто называют отображением карты символов). Некоторые аппаратные платформы могут накладывать несколько растровых дисплеев на настраиваемые позиции. Они называются спрайтами.

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

Большинство игр для персональных компьютеров используют аппаратное обеспечение, настроенное для рисования одного растрового экрана, а затем для рисования на этом экране всего, что должно отличаться от того, что уже есть. Иногда может быть проще рисовать вещи, не обращая внимания на то, действительно ли это необходимо в конкретном случае, но если код может легко определить, что нет причин для изменения части экрана, производительность можно улучшить, пропустив эту часть. Современные платформы часто бывают достаточно быстрыми, чтобы они могли рисовать весь экран много раз в течение кадра, но исторически это было не так. Например, самый быстрый код для записи всех пикселей на экране высокого разрешения компьютера Apple II займет более двух кадров, а самый быстрый код для копирования всех пикселей на компьютере Apple II ». Экран с высоким разрешением из другого буфера займет в два раза больше. Чтобы добиться хорошей производительности, игры должны обновлять только те вещи, которые действительно менялись, и это то, что обычно делали хорошие игры.

Supercat
источник
1
Я достиг середины этого ответа, и я не уверен, как он на самом деле отвечает на вопрос. Ваш первый абзац говорит о процессорах, координатах XY, электронных лучах, байтах памяти и спрайтах - но ничего из этого не касается прорисовки каждого кадра. Второй абзац говорит о шаблонах отображения в длину, а затем он теряет меня. Я думаю, что вам нужно принять любую часть этого на самом деле о перерисовке экрана, поднять его вверх в четком утверждении, а затем соединить все остальное, о чем вы хотите поговорить, с этим, чтобы объяснить, что происходит.
Doppelgreener
1
@doppelgreener: понятие «рисование» каждого кадра немного расплывчато. Что-то должно делать все необходимое для генерации каждого кадра, но есть много способов, которыми работа может быть разделена на процессор и оборудование. Некоторые способы требуют, чтобы процессор был задействован в каждом кадре, даже если части экрана выглядят одинаково между одним кадром и другим, в то время как другие этого не делают. В то время как любая игра на LCD или CRT в конечном счете требует, чтобы что- то выводило каждый непустой кадр [игры, использующие электронную бумагу или перекидные дисплеи, не могли), необходимые действия могут или не могут считаться «рисованием».
суперкат
Я предлагаю вам начать с простого языка (будем ли мы «рисовать рамку» постоянно) и вернуться оттуда к объяснению более технических деталей о том, почему это может быть неточным способом выразить это - вместо того, чтобы углубляться в детали. , Ваша статья нуждается в кратком изложении, в основном, и введении, прежде чем вы начнете исследовать вещи до глубины, которую вы делаете.
двойник
-11

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

Сакиб Занг
источник
9
Это даже не имеет смысла против заданного вопроса ... Я думаю, что вы перепутали "рамку" для чего-то другого ... возможно, вас путают с элементами доски объявлений? ОП специально говорит о кадрах в контексте рендеринга
Trotski94