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


60

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

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


Коментарі не для розширеного обговорення; ця розмова переміщена до чату .
Джош

Джон Кармак майже винайшов підхід на ПК робити повне екранне прокручування боком, намалювавши лише тонкий вертикальний зріз екрана, який змінився. Персональні ПК просто не змогли оновити повноекранний дисплей досить швидко без цієї методики. Він використовував це у багатьох 2d іграх на початку 90-х, таких як Commander Keen. Докладніше читайте у "Masters of Doom".
Ясен

Відповіді:


68

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


22
Це не просто старі ігри. У компанії EA з'явився поштовх до скорочення використання акумулятора ноутбука для певних «випадкових» ігор, і одна техніка полягала в тому, щоб лише перемальовувати частини екрану. Іноді це можна побачити в програмі The Sims 3, якщо ви залишили камеру нерухомою, а сим пройшов по екрану, іноді з'явиться помилка, де перемальовка не була достатньо великою, і ви побачили пікселі, залишені в рядку поперек екран. Вам просто довелося злегка перемістити камеру, щоб змусити повне перемальовування, і лінія зникне.
Кевін Плата

12
Дуже стара .. 1994 рік ... Я відчуваю себе старою зараз ...
alseether

4
@alseether старий в ігрових умовах. Пам'ятайте, що ми перейшли від 8-бітових піксельних крапель до фотореалізму (у попередньо відреагованому кроці, якщо не в прямому ефірі) всього за 20 ~ 30 років.
Джаред Сміт

16

Немає.

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

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

Векторні монітори також використовувались аркадні ігри з кінця 1970-х до середини 1980-х років, такі як "Астероїди", "Буря" та "Зоряні війни". Атаріус використав термін Quadrascan для опису технології при використанні у своїх аркадах відеоігор.

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

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


7
Векторні дисплеї навіть очевидно не мають "кадру".
варення

2
@hobbs Правильна, що робить мою відповідь ще правильною, оскільки відповідь "Чи всі ігри зроблені шляхом малювання кожного кадру?" "Ні, навіть не всі ігри малюються на основі кадрів."
Сенді Чапман

1
однак, у більш глибокому розумінні, питання полягало у повторному малюванні всіх видимих ​​предметів, а не лише предметів, які рухаються, а для більшості векторних дисплеїв відповідь все ще "так" (тюбик для зберігання зображень був би винятком)
szulat

@szulat таким чином, що є правдою, але якщо бути справедливим, він все ще не малює прогалини, де дисплей чорний. Він лише оновлює видимі елементи на екрані. Тобто в астероїдах, це лише перемальовування корабля та решти астероїдів на екрані.
Сенді Чапман

@SandyChapman та на іншому рівні різниці дійсно мало. гра оновлює пам'ять екрану або спрайт, коли щось змінюється. інакше відповідна частина дисплея залишається статичною. це справедливо як для растрових, так і для векторних систем - "астероїди" обробляють оновлення екрану з (векторної!) екранної пам'яті, не турбуючи процесор, аналогічно тому, як апаратне забезпечення zx спектру генерує свій растровий відеосигнал. незалежно від того, чи справжній чи уявний crt-промінь малює багатокутники або сканує екран за фіксованим малюнком, є другорядним.
szulat

11

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

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

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

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

[2] Що не є варіантом на вашому поточному рівні кваліфікації.


Чи є у вас посилання на підтримку "графічний процесор на вашій машині дійсно буде обчислювати кожен кадр з нуля"?
Кромстер

@Kromster: Це здебільшого ефективність. Оскільки кожен кадр може зажадати повного обчислення, і невідомо, які саме частини не мають, вам знадобиться дорогий розрахунок, щоб точно визначити, які біти можна зберегти. Навіть якщо це буде чистим покращенням ефективності, це призведе до невідповідності частоти кадрів.
MSalters

@MSalters, як це висловлено, суперечить багатьом пунктам у багатьох відповідях сусідів.
Кромстер

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

Я навіть не впевнений, що буде посиланням на "екран має бути очищений", але я маю посилання на те, як кадр відображається в Doom: adriancourreges.com/blog/2016/09/09/doom-2016- графіка-дослідження ; не забувайте, що відеокарта середнього класу повинна вміти керувати обчисленнями трильйона в секунду, декількома тисячами за піксель.
pjc50

2

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

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

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

Вирішіть, яку частоту кадрів в секунду ми хотіли в грі (наприклад, 30).

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

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

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

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

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

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


1
Я пам’ятаю гру «Золота сокира». Коли грали на 8086, геймплей був повільнішим і набагато простіше в обробці, ніж грав на 286, наприклад, коли справи рухалися швидше. Просто FYI.
акостадінов

0

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

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

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

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


1
Я дістався на півдорозі через цю відповідь, і я не впевнений, як це насправді відповідає на питання. Ваш перший абзац стосується процесорів, координат XY, електронних променів, байтів пам'яті та спрайтів, але нічого з цього не видно про малювання кожного кадру. Другий абзац говорить про шаблони відображення в довжину, а потім мене втрачає. Я думаю, що вам потрібно взяти будь-яку частину цього питання про фактичне перемальовування екрана, викласти його вгорі в чіткому викладі, а потім підключити все, що вам потрібно поговорити, щоб пояснити, що відбувається.
doppelgreener

1
@doppelgreener: Поняття "малювати" кожен кадр трохи розпливчасто. Щось потрібно зробити для створення кожного кадру, але є багато способів, які можуть бути розділені між процесором та обладнанням. Деякі способи вимагають участі процесора в кожному кадрі, навіть із частинами екрану, які однаково між одним кадром і наступним, а інші - не. Хоча будь-яка гра LCD або CRT вимагатиме, щоб щось виходило з кожного порожнього кадру [ігри з використанням електронного паперу або дисплеїв з відворотною точкою можуть не бути], необхідні дії можуть бути або не вважатись «малюванням».
supercat

Я пропоную вам почати з прямої мови (чи будемо ми постійно «малювати кадр») і повертатися звідти, пояснюючи більше технічних деталей, чому це може бути не правильним способом, а не занурюватися прямо в деталі . Перш за все, ваша публікація потребує підсумкового резюме та вступу, перш ніж розпочати вивчення речей до глибини, яку ви робите.
doppelgreener

-11

Якщо коротко сказати, я б сказав, що не всі кадри намальовані, а лише ті, що потрібні для представлення вашої історії чи теми гри чи гри. Плюс термін того, що ви хотіли б статися в певних випадках, матиме значення.


9
Це навіть не має сенсу проти поставленого питання. Я думаю, ви переплутали "кадр" у чомусь іншому ... чи, можливо, ви плутаєтеся з елементами дошки історії? ОП спеціально говорить про кадри в контексті візуалізації
Trotski94
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.