Как программировались игры на картриджах? [закрыто]

Я думаю о SNES, N64, Atari ... даже о DS сегодня, я полагаю.

Игры SNES обычно не занимали более 4 МБ пространства, а игры N64 обычно имели объем данных от 32 до 64 МБ.

В наши дни вы едва можете скомпилировать "Привет, мир!" программа без результирующей компиляции генерирует 1,21 гигабайта !! данных. (Шутки в сторону, файлы сегодня занимают тонны и тонны пространства по сравнению с некоторыми технологиями того времени.)

Итак ... как они это сделали?

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

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

Для меня это увлекательно, потому что даже самые крошечные и самые тривиальные файлы и игры могут занимать как минимум несколько МБ, так что воображать, что огромные уровни, подобные тем, что были в GoldenEye 007, почти не могли взять данные, просто невероятно.

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

Используя N64 в качестве примера, большинство сторонних игр были 8, 12 или 16 МБ. 32- и 64-мегабайтные игры были в основном от Nintendo, так как отправлять их на тележках было очень дорого для всех остальных. Это звучит крошечно, но так же были художественные активы и окончательный визуальный вывод. Вы должны помнить, что большинство игр N64 отрисовываются с разрешением 320x240, а не 1280x760 или более сегодня. При таком маленьком выходном разрешении текстуры и спрайты были намного меньше, чем сегодня.

Из-за крошечного кеша текстур на N64 большинство текстур имели размер 32x64 пикселя с палитрой 4/8 бита (16/256 цветов). Дополнительные цветовые детали часто делались путем смешивания текстур и вершинных цветов. Банджо-игры являются хорошим примером этого.

Сегодня один камень в движке Unreal Engine будет иметь кратные 512x512x24bpp или даже 32bpp. Кроме того, вместо простой диффузной текстуры теперь у вас есть карты нормалей, маски бликов, маски отражений, кубические карты отражений и многое другое. Таким образом, объект, который имел 4Kb текстур, теперь покрывается несколькими МБ данных.

Старые игры также имеют огромное количество повторного использования искусства. Кусты в Super Mario Bros. такие же спрайты, как облака, холмы такие же, как грибы. Разные персонажи - это просто сдвинутые по цвету версии одних и тех же художественных ресурсов. Все это получило большее использование от каждой текстуры или спрайта, которые были в корзине.

Аудио - еще одна большая разница для современных игр. Почти все в старые времена было сделано с последовательными треками. Теперь музыкальные треки, голосовые и звуковые эффекты хранятся в различных сжатых аудиоформатах. Хотя они, конечно, меньше, чем несжатые данные, они все же значительно больше, чем их последовательные эквиваленты.

Что касается NES (и SNES тоже в основном), вот основной обзор. Я не писал ни одной игры для NES, но написал эмулятор NES (Graybox) и проделал довольно много рев-инжиниринга старых тележек.

Что касается языка программирования: да, это была вся сборка. Программирование NES означало работу непосредственно с аппаратными прерываниями, портами DMA, переключением банков и т. Д. К счастью, программирование 6502 (или, скорее, 2A03) довольно просто [1]:

• регистров немного: в основном A, X и Y, последние два можно использовать только для индексации и итерации
• набор инструкций небольшой и в основном простой
• не много памяти: основной объем оперативной памяти составляет 2 КБ, с дополнительным 8KB расширением с батарейным питанием. Из этих 2 КБ 256 байт зарезервированы для стека, а на странице 0 (первые 256 байтов) вы хотели бы хранить наиболее часто используемые указатели и значения из-за некоторых специальных режимов адресации.

Эти 3 вещи вместе создают среду, которую достаточно легко запомнить при работе с ней. Да, вы сами управляете всей памятью, но это по сути означало, что вы создаете полную карту, где все идет вперед, и эта карта не очень большая, потому что вам нужно беспокоиться только о 2К, так что вы можете построить это на куске миллиметровая бумага. Вы должны были распланировать вещи немного больше и статически назначить переменные и константы местам RAM и ROM (на картридже).

Это становится немного сложнее, когда данные вашего картриджа выходят за пределы адресуемой границы ЦП. Это 64 КБ, из которых нижние 32 КБ установлены в камне и сопоставлены со всеми видами аппаратных портов и оперативной памяти. Именно здесь в игру вступает переключение банков, что означает отображение раздела ПЗУ в (часть) более высокого адресного пространства 32 КБ.

Это можно использовать по желанию программиста, но в качестве примера можно использовать игру с 3 уровнями, в которой все данные уровней, метаданные и код для каждого уровня втиснуты в отдельные области памяти по 8 КБ на картридже. Уровень может иметь обратные вызовы, например, для инициализации, обновления для каждого кадра и т. Д. «Загрузка» уровня будет означать отображение фрагмента памяти размером 8 КБ, например, при 0xC000. Затем можно указать, что подпрограмма init всегда имеет значение 0xC000, подпрограмма обновления кадра - 0xC200, а данные уровня начинаются с 0xC800. Основной код игры, размещенный в другом блоке памяти, затем контролирует изменения уровня, просто меняя правый блок и переходя к абсолютным адресам 0xC000 и 0xC200 в соответствующее время.

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

По сути, имея массу повторений и индексов в индексах, вы можете хранить данные очень маленькими. Данные об уровне часто сохранялись в виде вертикальных полос индексов листов, и поскольку эти вертикальные полосы также использовались повторно, они также были проиндексированы и сохранялись только один раз на картридже. Простые методы сжатия данных работают аналогично. Это позволило Mario 1 иметь 32 КБ данных (с запасом места) и 8 КБ растровых данных.

Что касается среды разработки, я видел несколько фотографий, где люди работали на некоторых древних компьютерах, подключенных к EEPROM для работы. Отладка с помощью инструмента не была действительно возможна до окончания возраста SNES [2]. Это главная причина, по которой во многих старых играх есть «очевидные» ошибки и почему такие вещи, как Gameshark, могут делать то, что делают; здоровье игрока всегда будет в mem-location 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/.

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

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

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

Вот некоторые вещи, которые я могу придумать, чтобы помочь команде получить игру меньшего размера:

• Повторно используйте то, что вы можете: повторное использование тех же спрайтов, и вариации, которые вы можете легко сделать из одного изображения спрайта (такие как отражения, повороты, смещения палитры), сэкономят ваше пространство. То же самое касается кода, музыки и почти всего остального в игре.
• Сжатие, что вы можете: существует множество схем сжатия, и знание того, какие из них использовать, может значительно сэкономить место. Даже иногда простые схемы сжатия, такие как кодирование по длине прогона, могут иметь удивительное значение. Мало того, но есть схемы сжатия (и альтернативные форматы, которые не совсем сжаты) для отдельных типов файлов, часто с качественными компромиссами. Например, аудиофайлы wave / CD могут быть сжаты с некоторой незначительной потерей информации в файлы MP3. Кроме того, форматы файлов, такие как MIDI и MOD на основе сэмплера, являются альтернативными форматами, которые занимают намного меньше места, но кодируют музыку совершенно по-разному и требуют различных навыков, чтобы они звучали хорошо.
• Потерять то, что вам не нужно: можете ли вы сделать это дешевле? Например, можете ли вы по-прежнему показать «характер» персонажа в меньшем количестве пикселей (или многоугольников)? Нужно ли точно определять расположение плиток дизайнером или они могут генерироваться случайным образом в коде вашей программы?
• Код часто бывает дешевле: хотя вы пошутили о том, сколько места компиляции кода обычно занимает идеи (и есть причины, почему эта «платформа» увеличилась за эти годы, и способы уменьшить ее, когда вам это абсолютно необходимо), но, как правило, если вы можете легко что-то делать алгоритмически / процедурно / в коде, этот подход также будет легче настроить и использовать повторно для других похожих, но отличающихся по внешнему виду активов. Фракталы - это особенно легко увидеть пример: у вас может быть изображение запутанного фрактала, который занимает много места по сравнению с математической формулой, которая его генерирует. Кроме того, математическая формула может иметь параметры, которые могут генерировать похожие, но иногда удивительно разные изображения.

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

Во-первых, я не уверен, сохранился ли он в эпоху после N64, но SNES и N64 часто повторно использовали текстуры на других трехмерных объектах, которые часто экономят значительное пространство и предварительно визуализированные изображения, фоны которых часто являются поддельными. Еще одна хитрость заключалась в том, чтобы создать пограничный фоновый туман.

В Сан-Франциско Rush N64 всегда было немного тумана, хотя настройки могли изменить плотность, где аркада Сан-Франциско Rush не имела такового, и вы могли видеть мост Золотые Ворота на дорожке 1 по сравнению с версией N64.

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

У Зельды Окарины времени мог быть Hywle Overworld, а затем подводная версия темы, если вы идете под водой или делаете инструменты в Магазине. Тема отражает внешнюю область, где флейты и скрипки будут использоваться для магазина Kokiri Forest, а также рогов и трубы для магазина Hyrule Castle Town и барабаны в деревне Goron.etc

В ПК 3D-модули скомпилированы в библиотеки для быстрого доступа к ним с помощью программы для распаковки, но я не уверен, так ли это с Nintendo, которая основана на ПЗУ. ПК - это ОЗУ, как будто вы попадаете в грязную комнату, в которой вещи не всегда остаются там, где они должны быть, а информация может быть перезаписана до такой степени, что компьютер даже не запустится!

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