Чи всі ігри зроблені шляхом малювання кожного кадру?

Я новачок у вивченні комп'ютерної анімації (для ігор). До цих пір єдиним методом, з яким я стикався, є малювання кожного кадру, кожне оновлення кадру. Таким чином, на початку кожного кадру, весь кадр стирається, і тоді потрібні речі, для яких кадр перемальовується.

Моє питання, чи є цей метод єдиним, який використовується для створення анімації та ігор. Здається, це трохи неефективно. Я також не зовсім розумію, як цей метод працюватиме для 3d ігор. Чи може хтось пояснити це більш докладно?

61
Коментарі не для розширеного обговорення; цю бесіду було переміщено до чату .
додано Автор Eric Goodwin, джерело

6 Відповіді

Дуже старі ігри використовували техніку, де тільки ті частини кадру перемальовуються, що змінюється на цьому кадрі. Про те, що я пам'ятаю, гра «Маленька велика пригода» використовує цю техніку (1994). Але ви можете бачити, що гра має більшу частину часу статичної камери. тільки коли ви вийдете з видимої області, сцена перемальовується. Якщо ви граєте в гру, ви також помітите невелике відставання від цього кадру. На сучасних графічних процесорах з сучасними ігровими движками все змінилося. Все перемальовується на кожному кадрі. Залежно від техніки візуалізації, речі можуть бути навіть кілька разів. Обчислювальна потужність GPU просто неймовірно висока, коли ви використовуєте її правильно. Але повторне використання відбувається. Наприклад, двигун може вирішити оновити карту тіней тільки в кожному 5-му кадрі. Або освітлення не оновлюється до тих пір, поки немає джерел світла.

67
додано
@ falseether старий в ігрових умовах. Пам'ятайте, що ми перейшли від 8-бітових піксельних крапок до фотореалізму (у попередньо відтворених роліках, якщо не в живій дії) всього за 20 ~ 30 років.
додано Автор Luke, джерело
Дуже старий .. 1994 ... Я відчуваю себе старим зараз ...
додано Автор Corbin, джерело
Це не просто старі ігри. На EA з'явився поштовх для зменшення використання батареї для ноутбуків для деяких «випадкових» ігор, і одна з методів полягала в тому, щоб тільки перемалювати частини екрана. Іноді ви можете побачити це в The Sims 3, якщо ви залишили фотокамеру стаціонарною, а сим пройшов по екрану, іноді виникла помилка, де переривання не було достатньо великим, і ви б бачили пікселі, що залишилися в рядку екрану. Ви просто повинні були трохи перемістити камеру, щоб примусити повну перемальовку, і лінія зникне.
додано Автор Hesham Ahmad, джерело

Ні.

Принаймні якщо ви включаєте старі ігри з 70-х років, які використовували векторні дисплеї.

Наприклад, широко відома гра Asteroids, яка спочатку була розроблена для векторних дисплеїв, які є принципово іншим способом перетворення графіки на екран.

Векторні монітори також використовувалися деякими кінцями 1970-х і до середини 1980-х років аркадними іграми, такими як Asteroids, Tempest і Star Wars. Atariвикористовував термін Quadrascan для опису технології при використанні їх в аркадах відеоігор.

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

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

16
додано
@hobbs Правильно, що робить мою відповідь все ще правильною, оскільки відповідь на "Чи всі ігри зроблені за допомогою малювання кожного кадру?" це "Ні, навіть не всі ігри малюють на основі кадрів".
додано Автор Sean Houlihane, джерело
@szulat таким чином, що це правда, але, щоб бути справедливим, він все ще не малює прогалини, де дисплей чорний. Він лише оновлює видимі елементи на екрані. Тобто. в астероїдах, це тільки перемальовує корабель і інші астероїди на екрані.
додано Автор Sean Houlihane, джерело
@szulat Дуже хороша точка. Я вважаю, що це трохи заплутано, але я впевнений, що ми можемо погодитися, що векторні дисплеї - це досить гарна річ, про яку багато людей не знають, тому відповідь, що їх висвітлює, є інформативною та цікавою.
додано Автор Sean Houlihane, джерело
Векторні дисплеї навіть не мають "рамки".
додано Автор Ether Frog, джерело
однак, у більш глибокому сенсі, питання полягало в тому, щоб неодноразово малювати всі видимі елементи, а не тільки елементи, які переміщуються, і для більшості векторних дисплеїв відповідь залишається "так" (випадок для зберігання зображень був би винятком)
додано Автор user113249, джерело
@SandyChapman і на іншому рівні, насправді мало різниці. гра змінює пам'ять екрану або спрайт, коли щось змінюється. в іншому випадку відповідна частина дисплея залишається статичною. це справедливо як для растрових, так і для векторних систем - «астероїди» обробляють оновлення екрану з (векторної!) пам'яті екрана, не турбуючи процесора, аналогічно тому, як zx спектр обладнання генерує свій растровий відеосигнал. чи реальний або уявний промінь crt малює полігони або сканує екран у фіксованому вигляді, є вторинним.
додано Автор user113249, джерело
@SandyChapman погодився! :-)
додано Автор user113249, джерело

На найнижчому рівні графічний процесор на вашому комп'ютері дійсно буде обчислювати кожен кадр з нуля і надсилати його на ваш екран. Проте ви будете лише цим піддаватися, але якщо ви самі керуєте цим матеріалом на низькому рівні [1] Будь-яка графіка (і з цим, ігровий движок), однак, буде обробляти ці речі для вас, і ви вільно виражаєте сцену в термінах багатьох об'єктів, які можна було б змінити між кадрами, але будуть стійкими.

... як цей метод буде працювати для 3D ігор ...

Елементи в 3D-просторі стійкі, графічний движок знову перерахує зображення на екрані для будь-яких змін, що відбулися (рух камери тощо).

[1] ... наприклад, якщо ви пишете власний движок [2] з чимось на зразок OpenGL. Навіть у цьому випадку ви, ймовірно, зберігатимете стійкі речі між кадрами.

[2] Це не опція на вашому нинішньому рівні кваліфікації.

11
додано
@Kromster: Це в основному ефективність. Оскільки кожен фрейм може вимагати повного обчислення, і невідомо, які саме частини не потрібні, вам знадобиться дорогий обчислення, щоб точно визначити, які біти можна зберегти. Навіть якщо це буде чисте підвищення ефективності, це призведе до непослідовних частот кадрів.
додано Автор Jon Schneider, джерело
У вас є посилання на підтримку "графічного процесора на вашому комп'ютері дійсно буде обчислювати кожен кадр з нуля"?
додано Автор Kromster, джерело
@MSalters, як це сформульовано, суперечить багатьом пунктам у багатьох відповідях сусідів.
додано Автор Kromster, джерело
Я навіть не впевнений, що це буде посилання на "екран повинен бути очищений", але мають посилання на те, як фрейм відображається в Doom: adriancourreges.com/blog/2016/09/09/doom-2016-graphics-study ; не забувайте, що графічна карта з високим рівнем потужності повинна управляти трильйонами обчислень в секунду, кількома тисячами на піксель.
додано Автор Jesse Lawson, джерело
Я б сказав, що твердження "графічний процесор на вашій машині дійсно буде обчислювати кожен кадр з нуля" технічно не відповідає дійсності. Графічний процесор обчислює саме те, на що ви його розповідаєте. Якщо ви хочете повторно використовувати попередній кадр, то він (дійсно, це його за замовчуванням). Багато сучасних ігрових двигунів (і навіть графічних інтерфейсів з операційною системою) починають з нуля (коли попередній кадр відображається лише в тому випадку, якщо новий кадр не завершив рендеринг в часі), але вони не повинні.
додано Автор Mary, джерело

Коротко кажучи, я б сказав, що не всі кадри намальовані, а тільки ті, які потрібні для того, щоб представити свою історію або тему гри або гри. Крім того, важливо було б визначити час, коли ви хотіли б статися в певних випадках.

10
додано
Це навіть не має сенсу проти запитаного питання .. Я думаю, що ви збентежили "кадр" для чогось іншого ... Ви, можливо, плутаєтеся з елементами дошки історій? Операційна програма конкретно говорить про фрейми в контексті рендеринга
додано Автор Morning Star, джерело

Коротка відповідь: Ні.

Довга історія:

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

Вирішіть, який коефіцієнт fps ми хотіли б в грі (30 наприклад).

Напишіть код, який додає 1 до лічильника для кожного інтервалу (33 мсек за 30 кадрів в секунду). Цей код виконується одночасно з ігровим циклом.

Тоді ігровий цикл, який виконує обчислення для гри (оновлення стану гри), зменшить той самий лічильник на 1 для кожного кадру. Але графічні розрахунки та малювання на екрані будуть зроблені тільки, якщо лічильник знаходиться на нулі.

Результатом є те, що графічна частота кадрів буде коригуватися в залежності від того, наскільки добре процесор обробляє обчислення в грі. Коли в грі відбувається не так вже й багато, розрахунки прості, а частота графічних кадрів буде вищою, ніж фактичне оновлення стану гри (в основному, витрачаючи цикли, оскільки ми малюємо ту ж саму гру більш ніж один раз на екрані).

Але тоді в грі багато що відбувається, процесор буде мати більше роботи, щоб зробити, і оновлення стану гри буде пріоритетним над малюванням на екрані.

Велику частину часу, гра буде продовжувати оновлюватися за запланованою швидкістю, але з'явиться "лагом", оскільки ви не побачите кожного оновлення на екрані. Це може бути краще для всієї гри уповільнення, тому що ви змушуєте його малювати кожне оновлення на екрані.

Все це було зроблено за допомогою C ++ і ніякого ігрового движка, ні відеокарти. Все працювало на одному процесорі ядра. Ми використовували деякі бібліотеки для 2d графіки.

2
додано
Я пам'ятаю гру "Золота сокира". При відтворенні 8086 геймплей був більш повільним і набагато простішим в обігу, ніж грав на 286 наприклад, коли речі рухалися швидше. Просто FYI.
додано Автор Alexander Mills, джерело

Перш ніж можна сказати, чи відео "витягують" дисплей у кожному кадрі, потрібно спершу визначити, що означає "малювати". Є, звичайно, багато відеоігор, звичайно, не всі малюють кожен кадр, збираючи растровий малюнок з нуля; дійсно, багато ігрові платформи ніколи не збирають повні растрові зображення взагалі .

Є кілька підходів відеоігор, які можна зробити для створення дисплея. Дуже невелике число може включати і вимикати електронний промінь, або для кожного пікселя, або для ігор для векторного сканування встановлювати координати XY кожної точки. Більшість ігор, які роблять це, роблять це здебільшого для демонстрації того, що процесор досить швидкий. Найчастіше ігри будуть мати апаратні засоби, які, за відсутності залучення процесора, будуть виводити деяку картину пікселів або векторів на дисплей повторно. Цей шаблон може бути отриманий шляхом зчитування даних послідовно з області пам'яті і інтерпретації кожного біта або групи бітів у вигляді кольору пікселя (це називається відображенням бітової карти). У деяких випадках апаратні засоби можуть читати байт пам'яті для кожної області 8x8, 16x16 або іншого розміру дисплея, а потім використовувати цей байт для вибору діапазону пам'яті для зчитування для даних пікселів (це часто називається відображенням символьної карти). ). Деякі апаратні платформи можуть накладати кілька растрових дисплеїв із конфігурованими позиціями. Їх називають спрайтами.

Деякі платформи не дозволяють змінювати шаблон відображення під час його надсилання на екран, але замість цього потрібно, щоб всі оновлення відбувалися після того, як промінь закінчив малювання одного кадру, але перед тим, як він почав малювати наступний. На таких платформах все, що буде з'являтися на кадрі, потрібно завантажувати в апаратне забезпечення перед початком цього кадру, і дисплей буде обмежений показом шаблону, який можна налаштувати відразу. Якщо процесор зупинився під час показу кадру, той самий кадр буде показуватися нескінченно. Інші платформи дозволяють змінювати або змінювати шаблон, коли він звертається до екрану. Це робить можливим показати екран, який є набагато складнішим, ніж відео-схема, яка може працювати сама по собі. Це може зробити апаратну платформу, яка має вісім спрайтів, можливість показувати більшу кількість рухомих об'єктів, встановлюючи позиції верхньої восьми об'єктів на екрані, очікуючи, що промінь досягне точки десь між дном першого об'єкта і верхня частина дев'ятого, встановлюючи положення дев'ятого об'єкта, чекаючи, поки промінь потрапить між дном другого об'єкта і вершиною десятого (якщо його вже немає), встановивши положення десятого об'єкта Зверніть увагу, що цей підхід вимагає залучення процесора під час кожного згенерованого кадру відео, навіть якщо жоден з об'єктів помітно не рухається, але процесор не буде залучений до "малювання" кожного об'єкта.

Більшість персональних комп'ютерних ігор використовують апаратні засоби, призначені для малювання одного растрового екрану, а потім малюють на цей екран все, що має відрізнятися від того, що вже є. Іноді може бути легше малювати речі, не беручи до уваги, чи це дійсно необхідно в конкретному випадку, але якщо код може легко сказати, що немає ніяких причин для зміни частини екрана, продуктивність може бути покращена, пропустивши цю частину. Сьогоднішні платформи часто досить швидко, щоб вони могли промальовувати весь екран багато разів під час кадру, але історично це не було так. Наприклад, найшвидший код для запису всіх пікселів на екрані високої роздільної здатності комп'ютера Apple II займе більше двох кадрів і найшвидший код для копіювання всіх пікселів на екрані високої роздільної здатності комп'ютера Apple II з іншого буфера займе вдвічі більше. Отримання гарної продуктивності вимагало, щоб ігри лише оновлювали речі, які фактично змінювалися, і це те, що хороші ігри взагалі робили.

0
додано
Я пропоную вам почати з простої мови (чи ми постійно «малюємо рамку») і працювати звідти, пояснюючи більше технічних деталей навколо того, чому це не може бути точним способом - замість того, щоб зануритися прямо в деталі . Ваш пост потребує Резюме, в основному, і Вступ, перш ніж почати вивчати речі на глибині, які Ви робите.
додано Автор Silly Freak, джерело
Я дійшов на півдорозі через цю відповідь, і я не впевнений, як він насправді відповідає на запитання. Ваш перший абзац говорить про центральні процесори, координати XY, електронні промені, байти пам'яті і спрайти - але нічого з цього не можна помітити щодо малювання кожного кадру. Другий абзац говорить про шаблони відображення в довжину, а потім він втрачає мене. Я думаю, що вам потрібно взяти будь-яку частину цього, насправді, про перемальовування екрану, покласти його на вершину в чітку заяву, а потім підключити все, що вам потрібно, щоб говорити про це, щоб пояснити, що відбувається.
додано Автор Silly Freak, джерело
@doppelgreener: Поняття "малювання" кожного кадру трохи розпливчасте. Щось має робити все необхідне для створення кожного кадру, але існує багато способів, за якими робота може бути розділена на процесор і апаратне забезпечення. Деякі способи вимагають, щоб процесор був задіяний на кожному кадрі навіть з частинами екрану, які з'являються однаково між одним кадром і наступним, а інші не. Хоча будь-яка гра з РК-дисплеєм або CRT вимагатиме, щоб щось виводило кожну не-порожню рамку [ігри, які використовують електронний папір або дисплеї з фліп-точками, можливо, не будуть], необхідні дії можуть бути або не враховуватися " ".
додано Автор Brad Roekle, джерело