Як відеоігри зберігають інформацію на екрані?

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

Наприклад, у New Super Bros, якщо ви потрапили на? блокувати, а потім вимкнути екран і повернутися, він все ще залишається хітом. Як ця інформація зберігається та виконується наступного разу, коли гравець завантажує блок? Чому він не просто скидається?

Зазвичай вам слід відокремити логічний стан свого ігрового середовища від візуального подання.

Гравець може бачити лише невелику частину його на екрані, але ви все одно зберігаєте стан всього рівня в пам’яті і зазвичай також розраховуєте механіку гри на весь рівень. Коли ваш світ настільки величезний, що для цього знадобиться занадто багато оперативної пам’яті та / або процесора, ви можете призупинити віддалені ділянки на жорсткому диску.

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

Ви йдете на це назад.

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

Потім ви завантажуєте ті деталі, які вас цікавлять - тобто шматки, які знаходяться поблизу гравця. Частинки, які знаходяться занадто далеко, зберігаються на диску / постійному сховищі та вивантажуються з пам'яті.

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

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

Це справедливо для будь-якої програми, яка має вихід. Якщо ви пишете програму із звичайним графічним інтерфейсом, наприклад текстовим редактором, ви, ймовірно, змоделюєте документ, і тоді графічний інтерфейс визначить стан та видимі частини документа та виведе його на екран. Або заповніть відповідні поля відповідно, або інше.

Основна суть: Подумайте, де і як ви зберігаєте дані спочатку (можливо, поряд із тим, як їх представити). Практично кожна програма має справу зі зберіганням даних. Лише дуже мало випадків, коли ви не зберігаєте жодних даних.

Як говорили інші, ви зберігаєте карту (наприклад, у масиві) і малюєте видиму її частину на екрані, а не читаєте її назад з екрана.

Але в деяких старих системах ви б буквально зберігали дані на екрані. Буде, скажімо, 400х300 пікселів відеопам'яті для дисплея 320х200, і ви б визначили огляд перегляду в цьому ("початок з X = 10 Y = 30"). Таким чином, ви могли прокручувати екран, просто налаштувавши регістр. Вам не доведеться витрачати сто тисяч циклів, необхідних для переміщення байтів, ви просто змінюєте те, де відеотехнічне обладнання починає їх читати.

NES має це в поєднанні із системою на основі плитки: http://wiki.nesdev.com/w/index.php/PPU_scrolling

NES ніколи не створює повне зображення в пам'яті, оскільки йому не вистачає оперативної пам'яті. Натомість є масив ОЗУ, який визначає набір плиток на два екрани. Один байт на вид плитки. Відеообладнання шукає координати плитки та зміщення X / Y для того, щоб визначити, який піксель повинен з’явитися в будь-якій точці.

Добре, якщо ви задаєте подібне запитання, вам належить довга дорога, щоб дістатися до тієї точки, де ви зможете зробити гру. Але, потрапивши до основи вашого питання, програма може зберегти стан багатьох різних речей у змінних, які знаходяться в задній частині вашої програми. Давайте розглянемо пару прикладів.

Mario Brothers (або подібне) зберігає стан рівня, на якому ви перебуваєте. Це може включати, як далеко ви пройшли до смерті, якщо блок потрапив чи ні. У деякому більш об'єктно-орієнтованому сенсі гра просто говорить "будь блоком тут" і блок існує. тоді, коли ви потрапляєте на блок, блок змінює власний внутрішній стан, щоб сказати "я потрапив". Такі дані можуть зберігатися різними способами.

Ваш текстовий процесор зберігає свої дані в структурі даних. Зараз існує безліч цих і багатьох способів їх реалізації, але, ймовірно, воно використовує певну форму дерева. У дереві у вас принаймні один вузол. Що-небудь додане перед тим, як перейти ліворуч. Все, що додається після цього, йде праворуч. Після додавання трьох вузлів у вас є два з них, що звисають із середнього вузла. І дерево може зростати ще більше, якщо нові куски додаються де завгодно, і дерево відновиться самостійно. Або подумайте про ігри-стрілялки, де ваш ворог бродить. У кожному з них є змінні, які відслідковують їх місце розташування, життя тощо. Так що, коли ви поранили його, він пам’ятатиме, що йому було боляче.

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

Ось кілька хороших вихідних матеріалів:

• http://visualgo.net/

Це певна функція того, як відображається 3D. Наприклад, OpenGL автоматично викреслить геометрію за межами діапазону -1,0, +1,0 у екрані XY (Z є складнішим, але схожим). Обчислена геометрія ніколи не генерує фрагментів (приблизно пікселів) і, отже, ніколи не перетворюється на фактичні зображення, незважаючи на те, що вони надсилаються в систему для візуалізації. У будь-якому випадку неможливо записати у простір поза вікном візуалізації (якщо все працює як слід).

У деяких контекстах достатньо покластися на таку поведінку як на оптимізацію. Однак вам все одно доведеться пройти всі свої ігрові дані хоча б на одному етапі візуалізації (вершинні шейдери), перш ніж відеокарта зможе дізнатися, що видно. Щось таке, скажімо, Skyrim, це було б недоцільно. Ви не тільки повинні відправляти кожну вершину у світі через конвеєр візуалізації, але й вам потрібно завантажувати кожну вершину в системну / відеопам'ять. Це неефективно, якщо навіть можливо.

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

Справжня суть цього в тому, що візуальні фільми - лише продукт гри. Фактичні дані не мають нічого спільного з тим, що ви бачите чи не бачите більшу частину часу, і дані фільтруються на різних етапах, щоб видалити сторонні відомості, перш ніж потрапляти в точку, де картинка записується на екран. Залежно від дизайну двигуна, візуальні зображення можуть бути надзвичайно відокремлені від фактичної логіки гри, оскільки щось на зразок наявності 2D та 3D інтерфейсу для однієї гри - це можливість. Навіть можливо, що багато ігрових двигунів працюють без будь-якого випуску; іноді це використовується для тестування ІГ гра.

Ось де все може ускладнитися. У чомусь такому простому, як гра Маріо, не надто надмірно обчислювати рух усіх ворогів за рівнем, навіть якщо вони не видно. У сучасних контекстах те, що відбувається поза екраном, є актуальним питанням серйозного розгляду. Якщо є кілька цілих міст NPC, як ви поводитесь, як вони поводяться, коли вони повністю повалені - як, коли гравець перебуває в іншому місті? Ви дійсно хочете обчислювати сотні рішень НПС по всій карті? Відповідь, як правило, ні, але точний підхід до цього не може відрізнятися, і це може мати певний вплив на гру.

Важливо зазначити, що саме так зараз працюють . Самі старі ігри Маріо, ймовірно, були запрограмовані дуже різними способами (я не можу говорити з точними способами), враховуючи на той час екстремальні обмеження на обладнання. Концепція 3D тоді ще не існувала; але сьогодні майже всі ігри, навіть ті, які повністю 2D, використовують 3D-рендерінг в якійсь формі, навіть якщо вони не знають, що роблять. Сучасне відео апаратне забезпечення спочатку 3D, і 2D-рендерінг (принаймні, коли він належним чином використовує обладнання) просто ігнорує 3-й вимір.

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

Ігри, які використовують відео оперативну пам’ять безпосередньо для державних цілей, були приблизно у 80-х роках у 8-бітовій, можливо, навіть у 16-бітній епосі, але якщо ви не розробляєте для цієї платформи або для якогось µC, який замість неї накопичує оперативну пам’ять у КБ ГБ, забудьте про це.

Зважаючи на це, вам здається, що ви абсолютно новачок у всьому, що стосується програмування, інакше питання не виникало б. Я пропоную перейти до цього крок за кроком, програмуючи спочатку дуже прості речі; можливо щось, що має лише текстові введення / виведення (прості підказки та все таке). Якщо чесно, то час, коли я це зробив, минув близько 30 років, тому у мене немає для вас справді хороших ресурсів, але ваша місцева бібліотека може бути просто кращою за Інтернет, щоб дати вам справді хороший старт у програмуванні.