Добавлю 3 от себя, которые подошли бы в Recomended, а не Optional-path
Pattern-Oriented Software Architecture - если паттерны из GoF про design-for-change или language idioms, то тут ещё и паттерны архитектуры, некоторые из которых, как и у Кристофера Александера, очень даже timeless.
Agner Fog Optimization manuals - про стоимость абстракций C++, и объяснение архитектуры современных процессоров на уровне, ещё понятном для прикладных программистов (хотя уже ближе к разработчикам компиляторов и embedded). Объясняет нелюбовь геймдев-программистов к виртуальным функциям, лишним ветвлениям, исключениям, и любовь к cache-locality.
Development and Deployment of Multiplayer Online Games - архитектура сетевых игр, от fast-paced шутеров, для mmo rpg.
Лучше отделить мух от котлет, у гейм-дизайнеров свой путь, я такое рисовал (но я тоже программист, просто интересно было)
Серией Gems странная достаточно, как по мне, её лучше на уровне оглавления читать, чтобы просто знать, что там есть. Там по порядку книг вроде более простое в начале, дальше более сложное. Но одновременно в старых книгах много того, что уже устарело, или вообще вредное.
Это сумма не то чтобы большая, с успешного ларька с шаурмой можно кажется похоже заработать. И автор с дтф там не разрабатывает, он фрилансеров нанимает дешёвых (соответствующего качества, судя по расходам). Дальше окажется, что ларёк масштабировать проще -- продать 100 треш-проектов не получится также, как продать 8. И 100 таких нанятых треш-программистов не смогут сделать одну хотя бы среднего качества игру.
Помогает в какой-то степени. Алгоритмы можно понять и изучая код — структуры данных в сеговских играх те же, алгоритмы компрессии, связанные с разработкой игр алгоритмы — AI врагов, поиск пути, допустимые упрощения в этих алгоритмах. Понимая ассемблер, можно намного лучше разобраться в низкоуровневой оптимизации, в том, какой оверхед дают скриптовые и высокоуровневые языки, в том, во что именно компилируется ваш код.
Вы будете иметь представление о том, как защитить вашу программу от исследования и модификации. И самое полезное — улучшатся ваши навыки отладки и поиска ошибок в своих программах.
Я явно не упоминал в статьях, что число кадров в секунду, отрисовываемое видеопроцессором — постоянное число. Нельзя добиться торможения выводом большого числа спрайтов — видеопроцессор пропускает лишние и будет рендерить дальше с прежней скоростью.
Тормоза связаны с тем, что разработчики написали слишком медленный игровой код, в примере с контрой причина в физическом движке. Там, фактически, реализована честная модель разрушаемости уровня. Любой враг выстрелом может разбить любой разрушаемый блок на уровне (например, пробить гранатой стенку, которая сдерживала катящуюся бочку), а не только попасть в игрока.
В бетмене не мигает. Там разработчики реализовали интересную логику (думаю, в других играх это тоже встречается). Важные объекты, например, сам персонаж и босс рисуются в первую очередь, и из-за этого не мерцают, а пули и спрайт гуи — во вторую очередь и программно рисуются через кадр, т.е. мерцают они всегда, и пропускаться при превышении лимита в 8 спрайтов начинают тоже в первую очередь они. Вероятно, разработчики предполагали ситуацию, когда в строке с гуи будет перебор спрайтов, из-за за этого сделали спрайт с буквами «неважным», чтобы зарезервировать место для немерцающих объектов на этой строке.
В Mistume Ga Tooru такой логики разделения нет, поэтому мигает всё. Как упоминали выше, можно в эмуляторе отключить лимит на вывод спрайтов в одной строке, и мерцание пропадёт.
С мерцающими объектами это не баг, а фича. Разработчики специально выводят их в каждый раз в обратном порядке, чтобы один кадр рендерились одни объекты, а пропускались другие, а затем наоборот. Это не приводит к другим артефактам, кроме мерцания — лишние спрайты (а точнее даже строки спрайтов), просто будут пропущены.
Каша из тайлов вызывается сбитыми таймингами — где-то в коде игры предполагается, что видеопроцессор находится в определённом месте кадра, а это почему-то не так. Отличий в таймингах денди от других режимов много — wiki.nesdev.com/w/index.php/Clock_rate, точно я не возьмусь предположить, что именно вызывает отличия, вполне возможно, что это связано с Time during which OAM can be written (это как раз время, за которое игра должна успеть записать данные о всех спрайтах на экране).
Хороший вопрос. У меня глаз настолько замылился с этими спецэффектами, что я даже не замечал этого мерцания в гуи.
Аппаратных причин для этого никаких нет. То, что этот спрайт выводится через кадр просто прописано в коде игры. Разработчики, скорее всего, случайно сделали вывод его той же функцией, которой рендерятся снаряды — там как раз программный вывод через кадр оправдан, чтобы показывать более 8 снарядов в линию (на чётных кадрах выводится одна половина снарядов, на нечётных – другая). Проверю внимательнее к следующей статье.
Таким же способом, как и в Super Spy Hunter, отдельный скроллинг каждой линии.
(линии в каждой строке наслаиваются и сливаются, поэтому в статье я оставил пример, в котором «слой» состоит из нескольких строк, чтобы было нагляднее).
Да, в большинстве игр глюки именно из-за того, что момент переключения скролла неверно определяется. В Battletoads там не только скролл переключается, ещё и гашение луча происходит в ходе кадра, можете в этой и предыдущей статье примеры посмотреть.
Для Elimination Boards (версия игра для региона PAL) строки разделения экрана на слои
в режиме PAL:
в режиме Dendy (сбиты тайминги рассчёта строк, на которых надо разделять экран и тайминг переключения банка памяти с графики GUI на банк с графикой облаков):
Addresses $3F10/$3F14/$3F18/$3F1C are mirrors of $3F00/$3F04/$3F08/$3F0C. Note that this goes for writing as well as reading
Нулевой цвет зеркалируется для обеих палитр, т.е. если вы в цикле записываете 32 байта в две палитры, то вы сначала пишете нужный цвет в палитру фона, а потом записью в 0x3F10 его затираете. И наоборот, записью в 0x3F10 вы меняете цвет в 0x3F00.
Так что при записи палитры спрайтов нужно отдельные байты записывать, пропуская адреса, которые зеркалируются.
Не согласен. Трюки и хитрости программисты графики использовали всегда, просто тогда это были трюки для того, чтобы сделать что-то, не умеет процессор. Позже — трюки, чтобы сделать то, что умеет последняя версия DirectX/OpenGL, а сейчас, чаще — трюки для обхода косяков Unity3D.
Разница в том, что тогда они всё-таки были намного ближе к железу, и у них было меньше возможностей написать код, который работает, но они не знают почему. Ну и тогда разработчик графики мог быть иногда ещё и художником, вот это сейчас уже действительно редкость.
Парой предложений понятнее целой статьи не распишешь. Если относительно NES сходу непонятно, сначала попробуйте разобраться с определениями индексированных цветов и палитровой графики.
Добавлю 3 от себя, которые подошли бы в Recomended, а не Optional-path
Pattern-Oriented Software Architecture - если паттерны из GoF про design-for-change или language idioms, то тут ещё и паттерны архитектуры, некоторые из которых, как и у Кристофера Александера, очень даже timeless.
Agner Fog Optimization manuals - про стоимость абстракций C++, и объяснение архитектуры современных процессоров на уровне, ещё понятном для прикладных программистов (хотя уже ближе к разработчикам компиляторов и embedded). Объясняет нелюбовь геймдев-программистов к виртуальным функциям, лишним ветвлениям, исключениям, и любовь к cache-locality.
Development and Deployment of Multiplayer Online Games - архитектура сетевых игр, от fast-paced шутеров, для mmo rpg.
Лучше отделить мух от котлет, у гейм-дизайнеров свой путь, я такое рисовал (но я тоже программист, просто интересно было)
Серией Gems странная достаточно, как по мне, её лучше на уровне оглавления читать, чтобы просто знать, что там есть. Там по порядку книг вроде более простое в начале, дальше более сложное. Но одновременно в старых книгах много того, что уже устарело, или вообще вредное.
Это сумма не то чтобы большая, с успешного ларька с шаурмой можно кажется похоже заработать. И автор с дтф там не разрабатывает, он фрилансеров нанимает дешёвых (соответствующего качества, судя по расходам). Дальше окажется, что ларёк масштабировать проще -- продать 100 треш-проектов не получится также, как продать 8. И 100 таких нанятых треш-программистов не смогут сделать одну хотя бы среднего качества игру.
Вы будете иметь представление о том, как защитить вашу программу от исследования и модификации. И самое полезное — улучшатся ваши навыки отладки и поиска ошибок в своих программах.
Тормоза связаны с тем, что разработчики написали слишком медленный игровой код, в примере с контрой причина в физическом движке. Там, фактически, реализована честная модель разрушаемости уровня. Любой враг выстрелом может разбить любой разрушаемый блок на уровне (например, пробить гранатой стенку, которая сдерживала катящуюся бочку), а не только попасть в игрока.
В Mistume Ga Tooru такой логики разделения нет, поэтому мигает всё. Как упоминали выше, можно в эмуляторе отключить лимит на вывод спрайтов в одной строке, и мерцание пропадёт.
Каша из тайлов вызывается сбитыми таймингами — где-то в коде игры предполагается, что видеопроцессор находится в определённом месте кадра, а это почему-то не так. Отличий в таймингах денди от других режимов много — wiki.nesdev.com/w/index.php/Clock_rate, точно я не возьмусь предположить, что именно вызывает отличия, вполне возможно, что это связано с Time during which OAM can be written (это как раз время, за которое игра должна успеть записать данные о всех спрайтах на экране).
Хороший вопрос. У меня глаз настолько замылился с этими спецэффектами, что я даже не замечал этого мерцания в гуи.
Аппаратных причин для этого никаких нет. То, что этот спрайт выводится через кадр просто прописано в коде игры. Разработчики, скорее всего, случайно сделали вывод его той же функцией, которой рендерятся снаряды — там как раз программный вывод через кадр оправдан, чтобы показывать более 8 снарядов в линию (на чётных кадрах выводится одна половина снарядов, на нечётных – другая). Проверю внимательнее к следующей статье.
(линии в каждой строке наслаиваются и сливаются, поэтому в статье я оставил пример, в котором «слой» состоит из нескольких строк, чтобы было нагляднее).
www.emu-land.net/forum/index.php?topic=78279.0
Да, в большинстве игр глюки именно из-за того, что момент переключения скролла неверно определяется. В Battletoads там не только скролл переключается, ещё и гашение луча происходит в ходе кадра, можете в этой и предыдущей статье примеры посмотреть.
Для Elimination Boards (версия игра для региона PAL) строки разделения экрана на слои
в режиме PAL:
в режиме Dendy (сбиты тайминги рассчёта строк, на которых надо разделять экран и тайминг переключения банка памяти с графики GUI на банк с графикой облаков):
Это что за чёрные списки такие, поделитесь, кто и по каким законам их будет составлять?
Это те, которых роскомнадзор заблокировал случайно?
Нулевой цвет зеркалируется для обеих палитр, т.е. если вы в цикле записываете 32 байта в две палитры, то вы сначала пишете нужный цвет в палитру фона, а потом записью в 0x3F10 его затираете. И наоборот, записью в 0x3F10 вы меняете цвет в 0x3F00.
Так что при записи палитры спрайтов нужно отдельные байты записывать, пропуская адреса, которые зеркалируются.
Разница в том, что тогда они всё-таки были намного ближе к железу, и у них было меньше возможностей написать код, который работает, но они не знают почему. Ну и тогда разработчик графики мог быть иногда ещё и художником, вот это сейчас уже действительно редкость.
habrahabr.ru/post/348212
dendy.migera.ru/nes/g02.html
Парой предложений понятнее целой статьи не распишешь. Если относительно NES сходу непонятно, сначала попробуйте разобраться с определениями индексированных цветов и палитровой графики.