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

Я думаю, что 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, практически не получают данных вообще.

40 голосов | спросил 2 revs, 2 users 100%
Corey
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

4 ответа


24

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

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

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

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

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

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

ответил davidv 8 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 08 Sep 2013 17:30:15 +0400 2013, 17:30:15
10

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

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

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

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

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

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

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

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

Что касается среды разработки, то я видел несколько фотографий, где люди работали над некоторыми сертифицированными древними компьютерами, подключенными к горелкам EEPROM для работы. Инструментальная отладка не была действительно возможной до истечения времени SNES [2]. Это основная причина, по которой многие старые игры имеют «очевидные» ошибки в них и почему такие вещи, как Gameshark, могут делать то, что они делают; здоровье игрока всегда будет в mem-location X, так что вы можете заставить его быть 100 в любое время.

Если вы найдете эти вещи интересными, я рекомендую вам посмотреть, например. http://wiki.nesdev.com/w/index.php/Nesdev_Wiki Существует немало курсов программирования дляРЭШ также можно найти в Интернете.

Надеюсь, что этот упрощенный обзор дал некоторое представление о разработке игр эпохи 80-х годов.

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

ответил davidv 8 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 08 Sep 2013 17:30:15 +0400 2013, 17:30:15
3

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

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

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

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

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

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

ответил davidv 8 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 08 Sep 2013 17:30:15 +0400 2013, 17:30:15
0

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

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

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

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

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

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

ответил davidv 8 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 08 Sep 2013 17:30:15 +0400 2013, 17:30:15

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132