Як запрограмовані ігри на основі картриджів? [зачинено]


44

Я думаю, як SNES, N64, Atari ... навіть DS сьогодні, я думаю.

Ігри SNES зазвичай не займають більше 4 Мб місця, а ігри N64 зазвичай мають дані від 32 до 64 Мб.

У ці дні ти ледве можеш скласти "привіт світ!" програма без отриманої компіляції, генеруючи 1,21 гігабайт !! даних. (Жартуючи вбік, файли сьогодні займають багато тонн місця в порівнянні з деякими технологіями тоді.)

Отже ... як вони це зробили?

  • У чому вони програмували ці ігри? ASM? Вся справа в ASM ?!
  • Як створювалася графіка? Яку технологію вони мали створити спрайтові аркуші, а в деяких випадках (як N64), 3D-моделі?
  • Як вони вмістили стільки рівнів, персонажів, квестів та предметів на цих картриджах? Я маю на увазі, Super Mario World на SNES-годиннику становить близько 1 МБ, і він має 96 виходів! Ocarina of Time, Banjo-Kazooie, DK64 та кілька інших ігор займають менше 64 Мб і мали величезні світи, тонни вмісту та 3D-моделі!

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

Мені це захоплююче, тому що навіть найдрібніші та найтривітніші файли та ігри встигають зайняти принаймні декілька МБ, тож уявляючи, що величезний рівень, як у GoldenEye 007, не зміг взяти майже жодних даних.


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

Можливий дублікат: gamedev.stackexchange.com/questions/443/…

1
NES (див. Джерело Metroid в MDB) та SNES (вихідний код деяких випадкових сторонніх ігор є в Інтернеті), використовуваний ASM, N64 (Zelda: екран налагодження MM відображає ім'я файлу в інформації про збої), що використовується C.
Ivo Wetzel

Ігрове програмування було дуже масштабним ще за 8-бітні дні. Наприклад, зробити так, щоб Pacman коштував цілий капітал, коли це можна зробити сьогодні досить дешево. Причини полягають у тому, що обмеження апаратних засобів були більш обмежуючими, ніж сьогодні, в тисячу разів (або більше). Це означало, що вам довелося покластися на код асемблера для цих 8-бітних ігор. Причина сьогоднішніх ігор настільки велика не в тому, що їм потрібно бути. В основному вони можуть бути. Ви можете прочитати про закон Вірта.
вовчий світанок

Так, 8-бітні ігри часто писали в Асамблеї. Ігри з SMS були зроблені на увазі Z80, це добре відомо. Коли ви пишете в Асамблеї, ви все одно можете створювати корисні бібліотеки. Я не бачу, наскільки збереження коду компактним має відношення до розробки ігор сьогодні. Це здається, що хтось питає, як годувати та доглядати коней на сучасному автомобільному форумі. Якщо ви пишете рідні бінарні інструкції, то в машині з однією метою, звичайно, ви можете і, ймовірно, збережете код компактним. Наскільки може бути роздутим, коли вам потрібно, щоб ваш код працював на кілька мегагерців. :)
вовчий світанок

Відповіді:


25

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

Використовуючи N64 як приклад, більшість сторонніх ігор склали 8, 12 або 16 Мбіт. Ігри на 32 та 64 Мбіт були в основному від Nintendo, оскільки це було так дорого, щоб перевозити на візках, великих для всіх інших. Це звучить крихітно, але тоді це були художні активи та кінцевий візуальний вихід. Ви повинні пам’ятати, що більшість ігор N64, розміщених на 320x240, не сьогоднішні 1280x760 або більше. З такою невеликою вихідною роздільною здатністю текстур та спрайтів було значно менше, ніж сьогодні.

Через крихітний кеш текстури на N64, більшість текстур склали 32х64 пікселів з палітрою 4/8 біт (він же 16/256 кольорів). Додаткові кольорові деталі часто робили шляхом змішування текстур і вершинних кольорів. Ігри Банджо є хорошим прикладом цього.

Сьогодні для однієї скелі в грі Unreal Engine буде кілька 512x512x24bpp або навіть 32bpp. Плюс замість лише однієї дифузної текстури, тепер у вас є звичайні карти, окуляри, маски, відображення, кубічні карти та інше. Тож об’єкт, який раніше мав 4 Кб текстур, тепер охоплений кількома МБ даних.

Старі ігри також мають велику кількість повторного використання мистецтва. Кущі в Супер Маріо Брос - ті самі справи, що і хмари, пагорби такі ж, як і гриби. Різні символи - це лише змінені кольором версії одних і тих же мистецьких ресурсів. Все це отримало більше використання від кожної текстури або спрайту, що знаходився на візку.

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


8
Ах, маріо кущі / дерева інцест з логічним поясненням! Відмінно.
Kzqai

10
Варто відзначити, що вози часто розміром в мега біт , а НЕ мега байт . Ці візки на 64 Мб були лише 8 Мб.
Даш-Том-Банг

3
Вихід не був 320 x 240 в N64. Деталі невірні. Більшість гри, ймовірно, використовували 256 × 224. дивіться тут
вовчий світанок

13

Що стосується NES (а також переважно SNES), то ось основний огляд. Я не писав жодних ігор NES, але писав емулятор NES (Graybox) і робив неабияку кількість інноваційних технологій старих візків.

Що стосується мови програмування: так, це все було складання. Програмування NES означало роботу безпосередньо з апаратними перериваннями, портами DMA, комутацією банків тощо. На щастя, програмування 6502 (а точніше, 2A03) досить просто [1]:

  • Є кілька регістрів: в основному, A, X і Y, останні два використовуються лише для індексації та ітерації
  • набір інструкцій невеликий і переважно прямий
  • не багато пам’яті: основна оперативна пам’ять - 2 КБ, з додатковим розширенням на 8 КБ. З цього 2 КБ 256 байтів зарезервовано для стека, а на сторінці 0 (перші 256 байт) було місце, де ви хочете зберігати найбільш використовувані вказівники та значення через деякі спеціальні режими адресації

Ці 3 речі разом створюють обстановку, яку досить легко запам'ятати під час роботи з нею. Так, ви керуєте всією пам'яттю самостійно, але це означало по суті, що ви створюєте повну карту того, де все йде вперед, і ця карта не дуже велика, тому що ви повинні турбуватися лише про 2K, щоб ви могли побудувати це на шматочку графічний папір. Вам довелося спланувати речі трохи більше і статично призначити змінні та константи місцям RAM та ROM (на картриджі).

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

Це може бути використано, хоча програміст хоче, але в якості прикладу може бути гра з 3 рівнями, з усіма даними рівня, метаданими та кодом для кожного рівня, набитими в окремі області пам'яті 8KB картриджа. Рівень може мати зворотні виклики, наприклад, ініціалізація, оновлення кадру тощо. "Завантаження" рівня означало б відображення цього 8 кБ фрагмента пам'яті, наприклад, 0xC000. Потім можна вказати, що програма init завжди знаходиться на рівні 0xC000, процедура оновлення кадру - на 0xC200, а дані рівня починаються з 0xC800. Основний код гри, розміщений в іншому фрагменті пам’яті, потім керує змінами рівня, просто поміняючи правильний фрагмент і переходячи до абсолютних адрес 0xC000 та 0xC200 у відповідний час.

Графічні дані Wrt: дані плиток NES - це 2-бітні карти 8x8 пікселів. Для фону вони поєднуються з 2-бітовим шаром роздільної здатності 1/4. Ці 4-бітні значення потім були індексовані в 16-палітровій палітрі, я вважаю, що наявних 53 ефективних унікальних кольорів. Спрайти також використовували дані 2-розрядних пікселів, і кожен спрайт вказував свій власний 2-розрядний груповий індекс, знову утворюючи 4-розрядний індекс pal. Зображення BG на екрані - це масив розмірами 32x30 з індексом плиток.

По суті, маючи тону повторень та індексів в індекси, ви можете зберегти дані дуже малі. Дані про рівень часто зберігаються у вигляді вертикальних смуг індексів плитки, і оскільки ті вертикальні смуги також були повторно використані, вони також були індексовані і зберігалися лише один раз на картриджі. Прості методи стиснення даних працюють аналогічно. Це дозволило Маріо 1 отримати 32 КБ даних (з простором місця) та 8 КБ растрових даних.

Що стосується середовищ розробників, я бачив кілька фотографій, на яких люди працювали на сертифікованих старовинних комп’ютерах, підключених до пальників EEPROM для роботи. Налагодження за допомогою інструментів насправді не було можливим до настання віку SNES [2]. Це головна причина того, що багато старих ігор мають "очевидні" помилки в них і чому такі речі, як Gameshark, можуть робити те, що вони роблять; Здоров'я гравця завжди буде в пам'яті X, тому ви можете примусити його бути 100 завжди.

Якщо ви вважаєте, що ці речі цікаві, я рекомендую вам подивитися, наприклад, http://wiki.nesdev.com/w/index.php/Nesdev_Wiki Існує досить багато курсів програмування для NES, які також можна знайти в Інтернеті.

Сподіваюся, цей спрощений огляд дав деяке розуміння розвитку ігор 80-х років.

[1] Відносно кажучи. Також я упереджений, як я написав сам Graybox приблизно в 85% PowerPC збірці. [2] Дивіться створення статті FF6: http://www.edge-online.com/features/the-making-of-final-fantasy-vi/


3

У майже всіх питаннях, які ви задаєте, є багато підтемати. Оптимізація - це величезне поле все для себе, і є багато чого вивчити.

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

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

Ось деякі речі, які я можу придумати, що можуть допомогти команді отримати гру в менші розміри:

  • Повторне використання того, що ви можете: повторне використання одних і тих же спрайтів і варіантів, які ви можете легко зробити з одного спрайтового зображення (наприклад, відображення, обертання, зсув палітри), заощадять вам простір. Те саме стосується коду, музики та майже всього іншого в грі.
  • Стисніть те, що ви можете: існує ряд схем стиснення, і знати, які з них використовувати, може бути величезною економією місця. Навіть іноді прості схеми стиснення, такі як кодування довжини пробігу, можуть зробити дивовижну зміну. Мало того, але існують схеми стиснення (і альтернативні формати, які не є точно стисненнями) для окремих типів файлів, часто із якісними компромісами. Наприклад, звукові файли хвиль / компакт-дисків можуть бути стиснуті з певною незначною втратою інформації в MP3-файли. Крім того, формати файлів на зразок MIDI та MOD на основі вибірки - це альтернативні формати, які займають набагато менше місця, але кодують музику зовсім по-іншому і вимагають різних навичок, щоб вони звучали добре.
  • Втрачайте те, що вам не потрібно: ви можете зробити це дешевше? Наприклад, ви все ще можете отримати "особистість" персонажа в меншій кількості пікселів (або полігонів)? Чи потрібно розміщення плиток точно визначати дизайнер чи вони можуть бути випадковим чином згенеровані у вашому програмному коді?
  • Код часто дешевший: хоча ви пожартували про те, скільки місця для компіляції коду зазвичай займає ідеї (і є причини, чому ця "платформа" з роками зростає, і способи зменшити її, коли вам абсолютно потрібно), але, як правило, якщо ви можете легко щось алгоритмічно / процедурно / вводити, цей підхід також буде простіше налаштувати та повторно використовувати для інших подібних, але інших вигідних / відчуваючих активів. Фрактали - це особливо легкий приклад: ви можете мати зображення хитромудрого фрактала, який займає багато місця порівняно з математичною формулою, яка його породжує. Математична формула, крім того, може мати параметри, які можуть генерувати подібні, але іноді напрочуд різні зображення.

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


Також використовуйте технологію, яка використовує менше місця.
швидкість

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

Ще один вхід: / У будь-якому разі, використовуйте технологію, що використовує менше місця, як процедурні карти (у Noctis є ціла галактика з кількома мільйонами сонячних систем, з планетами, на яких можна висадити і побачити життя, дерева, руїни, будівлі ... менше ніж 3 Мб ), модульна музика (музика у форматах .mod, .xm, .it ...), процедурні текстури (див. werkkzeug, mapzone та інше програмне забезпечення), процесуальні звукові ефекти (практично будь-який звуковий ефект можна зробити з математики) рівняння, або маніпулювання основними звуковими хвилями) тощо.
швидкісник

@speeder легко натиснути "редагувати" або "видалити" на випадкові коментарі ...
dash-tom-bang

Re: "Стисніть все, що можете", на старому апаратному забезпеченні, яке ви зазвичай стискаєте до того, з чим може працювати апаратне забезпечення. Ви ніколи не стискали б аудіо в MP3, тому що аудіо апаратне обладнання не справлялося з ним спочатку, і ви не хотіли б витрачати час на декомпресію його на центральний процесор, коли ви могли просто передати його прямо з носія в аудіо апаратне забезпечення. MIDI був чудовим, хоча тому, що кожен мав (і мав) синхронний синтезатор на борту; просто завантажте свої зразки, і ви їдете.
Даш-Том-Банг

0

Одне, я не впевнений, чи він все ще стоїть в епоху пост N64, але SNES і N64 часто повторно використовували текстури на інших 3D-об'єктах, що часто економить багато місця і попередньо надає мистецтво, яке фони часто підробляють. Ще одна хитрість полягає у створенні прикордонного фонового туману.

У Сан-Франциско Rush N64 завжди був якийсь туман, хоча налаштування могли змінити щільність, де аркада Сан-Франциско-Раш не мала, і ви могли побачити міст Золотих воріт на треку 1 порівняно з версією N64.

Також ігри часто повторно використовують музику на зразок Zelda Ocarina of Time багаторазово використовує музику, яку мені дратує, бо там можна було зробити кращу роботу, як, наприклад, як у Banjo Kazooie / DK64 часто були теми в темах!

Зельда Окаріна часу могла мати “Подземний світ”, а потім підводну версію теми, якщо ви ходите під водою чи виготовляєте інструменти в Темі магазину, що відображають зовнішню територію, де флейти та пуховики будуть використовуватися для магазину та рогів Kokiri Forest. труби для магазину Hyrule Castle Town та барабани в селі Горон.etc

3D-модулі ПК складаються в бібліотеки для швидкого доступу до них за допомогою програми для розпакування, але я не впевнений, що це так з Nintendo, який базується на ROM. ПК - це оперативна пам'ять, як увійти в безладну кімнату, в якій речі не завжди залишаються там, де вони, як передбачається, і інформація може бути перезаписана до того моменту, як комп'ютер навіть не запуститься!

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.