Игровые спецдефекты

Материал из Posmotreli
Перейти к навигации Перейти к поиску

В отличие от кинематографических, происходящих в основном по вине постановщиков (как известно, и в 40-е с резиновыми монстриками можно было снять достаточно правдоподобно, при умелых руках) — игровые спецдефекты обычно являются неизбежной данью тому или иному этапу развития пользовательской техники. И темпам прогресса, да: даже теоретически имея возможность на том же самом железе мужественно проблему преодолеть, на это, как правило, требуется лишних эдак полгодика. Раз полгодика, два полгодика — глядишь, не только игра уже не актуальна, но и железо, в рамки которого её запоздало загнали. Плюс нехватка рук: зубробизоны типа Кармака пишут новые движки под новое железо, а недотыкомки, купившие движок Wolf3D, никак уж не в состоянии исправить в нём небо и койки. Кстати, вот с них мы и начнём…

Сюда не писать допустимые геймлейные условности — только намеренные графические решения!

CGA, EGA и тому подобные[править]

См. также Проекции графики.

Особенностью видеорежимов было ограниченное число цветов в видеорежиме, обычно четыре цвета[1]. При попытке обойти это ограничение возникали глюки. Наиболее крутые разработчики использовали эти глюки как багофичи, показывая картинку, невозможную для стандартного отображения без глюков[2].

Так, в игре Saboteur 2 для PC ниндзя был красный! Смеялись даже: пусть лучше будет зелёный, был бы ниндзя-черепашка! А в некоторых менее динамичных играх использовали 160×100×16, чуть сглаживая этот кошмар обильной псевдографикой (с её помощью можно было получить разрешение чуть получше), но рисовать её было весьма накладно в плане процессорного времени (а «камни», как известно, тоже были те ещё). Нет, такую прелесть в те годы не рисовали (это современная демка), но нарисовать среди 160×100 хотя бы глазки или кисть руки — такое встречалось.

(link)

Легендарный "color clash" на Спектруме!

Из категории «тому подобных» нельзя не упомянуть Спектрум, где отсутствовавший в CGA механизм «два цвета на знакоместо» таки был! Фирменный спецдефект таких систем — т. н. «конфликт атрибутов». Это, конечно, на две головы лучшая графика, чем CGA (хотя железо даже дешевле и тупее), но спецдефект таки «имел место быть». Поподробнее о нём тут (серьёзно, если бы эта идея озарила кого-нибудь примерно в 1993-м, когда «Спекки» был уже совсем не роскошью, не в пример «Айбиэмке», дальнейшее развитие предугадать несложно. ZX-Poly был бы роскошью, но доступной, и у кого-то бы он был. Разбрасываться 4 процами бы никто не стал, следующий софт бы писался уже с тем, чтобы они не полностью дублировали поведение друг друга, затем появился бы SIMD-процессор, потом одной штуки бы снова стало мало, в общем, лет через 5 «Спек» уверенно пёр бы по пути кластерных вычислений («много слабеньких камней вместо одного большого»). И, вероятно, сборола бы его только CUDA. А может, и она бы не осилила).

Шутеры поколения Wolf3D[править]

Основная статья: Псевдотрёхмерность

Бесперспективная перспектива[править]

Самая адова вещь, которую только можно было заложить в бедный движок. Дело в том, что в игре впервые появились полигоны: это стены, которые строго квадратны, строго 64×64 пиксела, которые перекрывают друг друга только цельными вертикальными линиями, которые строго привязаны к такой же «квадратно-гнездовой» сетке самой карты, но, к счастью, хотя бы при условии рассмотрения их только с одного ракурса могут быть «утоплены» слегка вглубь своей клетки (на этом были сделаны двери и стены-секреты; если удалить в редакторе косяк двери или в некоторых местах толкнуть секрет и быстро обежать его сбоку, чтобы сбоку посмотреть на его движение, становятся видны те «белые нитки», которыми шита эта иллюзия). На таких средствах можно сделать очень, очень мало, и, допустим, обычную койку (состоящую как минимум из двух полигонов, если рассматривать её только с одной стороны — вертикальная поверхность спинки, повёрнутая к герою, и горизонтальная поверхность самой постели) уже не сделать никак. Поэтому койка просто отрисована с одного статичного ракурса и засунута туда спрайтом, и глаз абсолютно отказывается воспринимать её как койку: малейшее движение ломает любую перспективу. Чуть лучше получилось с небом: из-за разрешения 320×200, да ещё и на слабых машинах (то есть в окошке с почтовую марку), пикселизация пейзажа (особенно ночного) начинает «переливаться» муаром, прекрасно воспринимаясь как очень далёкая. В Spear of Destiny уровень, происходящий «на крыше», смущает нарисованными на верхних частях стен «типа-как-облачками», а вот трэш-поделка NiteMare3D на том же движке давит педаль в пол — на стенах полно «движущихся картин», изображающих пейзаж в окне или движущуюся за стеной механику, абсолютно оскорбляющих зрение.

Ограниченные проекции спрайтов[править]

  • Зеркальные спрайты. Из-за ограничения памяти спрайт противника, рассматриваемого не со спины и не с лица (то есть с любого плеча либо с промежуточных углов) использовался дважды: для этого плеча и для противоположного, просто отзеркаливаясь при отрисовке. Соответственно, винтовка, пистолет или что бы там ни было постоянно прыгало из левой руки в правую и обратно.
  • Дискретные ракурсы спрайтов. Их, как правило, всего 8, и из-за этого, например, непонятно, что делает arch-vile — его пассы хорошо видны только сбоку.
  • Односторонние спрайты как клинический случай дискретных. Трупы в Doom (а в Wolf3D — и боссы тоже!) буквально глаз не сводят с героя. Покрутись вокруг них циркуль-стрейфом — и они тоже покрутятся вокруг своей оси.
    • В Doom на консолях (SNES, 32X, 3DO, Atari Jaguar) вообще все спрайты врагов — не только трупы — были сделаны односторонними ради экономии. Сзади или сбоку к врагу не подкрасться.
      • Оба «дефекта» по сей день — и крайне эффективно — используются при создании игровой растительности. Так, для дальних планов дерево отлично подменяется на спрайт (в идеале минимум 8 проекций для хоть какого-то разнообразия), а карточки листвы умеют поворачиваться на камеру, при этом отбрасывая тени и формируя более пышную крону, чем статичная.

Шутеры поколения Doom[править]

Унаследованы с предыдущих поколений[править]

  • Ограниченные проекции спрайтов

Непрозрачная синяя вода по щиколотку[править]

Рендер полупрозрачных поверхностей очень сложен, когда им занимается процессор, да и поверхность сложной формы, да и большая к тому же…[4] Приходилось поступать очень просто: погружать героя в пол на полтора дециметра, тупо снижением точки камеры намекая, что он как бы ушёл ногами в как бы жидкий как бы «пол» сектора, ну и максимум ещё нарисовать исходящие от его движений волны на этом полу (очевидно, такие же плоские). Встречалось даже на движке самого Doom, но уже только в фанатских картах, вовсю эксплуатирующих незапланированные багофичи.

В играх с портально-секторной геометрией вода может быть и не по щиколотку, а глубокой, чтобы в неё можно было нырять. Это реализуется путём создания в секторе с водой портала, активирующегося приседанием в воде и телепортирующего игрока в другой, «подводный» сектор. Обычно она являет собой такую же неумолимую синюю границу. Но в продвинутых версиях движка Build (Blood, Shadow Warrior) её таки-сумели сделать бледно-голубой и полупрозрачной. Не везде, правда: в одной и той же игре могут по соседству встречаться непрозрачная синяя и красивенькая прозрачно-голубая вода.

В Quake 2 сделали полупрозрачность, но простейшим образом: в шахматном порядке идут пиксели воды и дна. Похожим образом на софтовых движках делались некие подобия стёкол.

Отображение стен по столбцам[править]

Движки поколения Doom рисовали стены по столбцам и полы с потолками — по строкам. Поэтому, если взглянуть вверх-вниз, перспектива изрядно портится. Прямо под ноги под углом 90° взглянуть в принципе невозможно.

Дело усугубляют спрайты, которые обычно рисуются совсем в другой перспективе. Поэтому в играх наподобие Duke Nukem 3D посмотришь сверху на труп — он лежит косо.

В современных портах с настоящим трёхмерным ландшафтом и теми же спрайтами вообще ужас: смотришь вниз и видишь, как этажом ниже на полу какие-нибудь демоны на жопах елозят и ногами дрыгают, и таким образом бегают лёжа. Как вариант — спрайты всегда вертикальны и потому сверху выглядят картонными. Это не совсем тот же самый спецдефект, но близко к тому. И только VoxelDoom сумел наконец изрубить гордиев узел на корпию — скорей бы уж хотя бы нормальная бетка, а не одни технические альфы.

Спрайтовые клубы дыма[править]

Разного рода огни и дымы требуют большого количества спрайтов (так называемую систему частиц). Каждая частица — полупрозрачная, это изрядная нагрузка на видеоплату. Потому частиц делают мало. Посмотришь глазами стрелка — от ракеты идёт неплохой дым. Сдвинешься — идут такие колечки через метр. Так было и в Hexen, и в Unreal Tournament, и в более поздних играх; более-менее избавились в конце 2000-х.

Симуляторы дотрёхмерной эры[править]

Думаете, первые игры, где была трёхмерность,— шутеры? Нет, это были симы. Первый из ПК’шных — Aviator за авторством небезызвестного Джеффа Крэммонда. Впоследствии он же сделал автомобильный REVS.

  • Дискретные положения руля, более точно поворот руля показывается меткой (Grand Prix Circuit).
  • Полигональный кузов, а из него торчит спрайтовый шлем (серия IndyCar).
  • Ограничения по повороту камеры. Например, в первом The Need for Speed, если машину развернёт, вид переходит на хвост машины.
  • Горы — пирамиды на плоской земле (серия авиасимов Microprose).
    • Аркадные автоматы, манипулируя множеством одинаковых спрайтов, умели в перспективу задолго до того, как игры стали трёхмерными и полигональными. Погуглите Sega Super Scalers, не пожалеете.
  • У двухмерных аркадных гонок (Enduro Racer, Lotus Challenge) был свой «спецдефект» — полосатая земля.
    • Не только у них. Горизонтальная поверхность «в клетку» или «в полоску» часто использовалась везде, где разработчики добавляли параллаксную прокрутку (движение строк пола с разной скоростью друг относительно друга, что создаёт иллюзию 3D). Примеры можно найти в очень многих играх на Mega Drive (The Adventures of Batman&Robin, стол из локации Tea Time) и Super Nintendo (Battletoads in Battlemaniacs, бонусные уровни).
  • Super Nintendo, кроме того, щеголяла особым «режимом 7», который за счёт масштабирования и вращения фона правдоподобно имитировал 3D под любым углом обзора, в отличие от параллаксной прокрутки. В видео по ссылке нет ни грамма 3D. Неприятный недостаток — невозможность имитации ландшафта, «трёхмерность» абсолютно плоская. Хотя некоторые разработчики и с этим справлялись (Super Star Wars Empire Strikes Back, уровень с шагоходами AT-AT).
  • Спрайтовые клубы дыма, как без них…

Зайчатки трёхмерности (Quake, Unreal и иже с ними, до 2000)[править]

Больше не будем писать «шутеры поколения» — трёхмерность уравняла все игры в правах. Что шутеры, что гонки, что стратегии…

Разве что стратегии, которым нужно много юнитов, отстают на поколение по качеству моделей. В те времена трёхмерных было мало (Ground Control, Total Annihilation, WarZone 2100; существовали воксельные образчики вроде Myth или C&C: Tiberian Sun). Только WarCraft III (2002), с его рублеными «игрушечными» юнитами, переломил тенденцию; именно с этого момента начался массовый переход стратегий в 3D.

Унаследованы с прошлых поколений[править]

  • Спрайтовые клубы дыма.

Нехватка полигонов[править]

  • Лопаты вместо пальцев (особенно на ногах).
  • Квадратные головы и колёса.

Спрайт-заместитель[править]

И сейчас делают несколько уровней детализации моделей. Поначалу делали проще: близко — модель, далеко — спрайт. Иногда «далеко» — это были пять-десять метров! В первых стратегиях с 3D вроде Total War трёхмерным был только рельеф местности, а почти все объекты, включая и войска, состояли из спрайтов.

В недавнем прошлом похожим образом справлялись с массовкой в кинематографе. В начале битвы на Кашиике из «Мести Ситхов» вуки на переднем плане — это актёры в костюмах, чем дальше от зрителя, тем больше они разбавлены цифровыми.

В первых играх для акселераторов спрайты-заместители использовались нечасто (полупрозрачные объекты перегружали все подсистемы движка и видеоплаты, один из редких примеров — Grand Prix 3). Зато в программных движках (Descent) их использовали за милую душу.

К спрайтовой графике вернулись около 2000, когда модели уже стали достаточно детальными, а прозрачность — не таким узким местом. Но это уже другой этап.

Спецэффекты в программном режиме и светофильтры в аппаратном[править]

До появления шейдеров программист был ограничен теми эффектами, которые были заложены в видеоплату. Поэтому в программном режиме он мог наложить какой-то постфильтр (пикселизованный экран, если ослеплён в Counter-Strike, колышущуюся воду в Quake). А в Direct3D/OpenGL — нет!

Видна граница уровней детализации текстур[править]

Трилинейная (и тем более анизотропная) фильтрация текстур очень дорога, обходятся билинейной. Когда смотришь на большую поверхность под острым углом (например, на дорогу в гонке, или на большой плац), видишь границы уровней детализации. В Minecraft и по сей день видна та резкая линия, где рельсы или приставная лестница внезапно превращаются в кашу.

Низкая дальность прорисовки[править]

Даже несчастная сотня многоугольников может немало затормозить игру. Поэтому в закрытых пространствах делали вечные коридорчики, тамбурчики и поворотики, разрывающие обзор. А в открытых — рисовали очень близко (подчас на 10 метров). Оттуда родом штамп «дистанционный туман».

Ошибки и условности анимации[править]

Игру не стоит делать реалистичной. Поэтому, например, во многих шутерах не реализовано движение ползком — персонаж идёт на корточках. Или бегать можно не только вперёд, но и назад. И как такое анимировать? К тому же для большей красоты комбинируют готовую и алгоритмическую анимацию, а людям свойственно ошибаться.

Два примера из одной игры, ставшие мемами — крабошпион и запутывающиеся ноги разведчика в Team Fortress 2.

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

Растворяющиеся трупы[править]

Два врага расходуют многоугольников как остальная сцена. Вместо полчищ спрайтов (Doom) игра делает парочку интересных врагов (Quake) — и этим, кстати, освежила жанр. А чтобы враги не отъедали многоугольники надолго, труп через некоторое время «растворяется». Встречается даже в настоящее время, иногда пытаются обосновать.

Во всех Quake, кстати, враги остаются, а растворяющиеся появились в Turok.

Ограничения отражений[править]

В Duke Nukem 3D по другую сторону зеркала поставлена такая же геометрия, а спрайты дублируются. Такое крайне редко делают и в играх трёхмерной эры. Но зеркало — не единственный отражающий предмет…

Самый простой способ сделать отражения в объекте сложной формы — кубическая текстура. Аппаратно этот метод реализован в GeForce 256. Однако эта текстура рендерится на этапе разработки и не может отражать реальное состояние игрового мира. Есть и более сложные методы реализации отражений, у каждого свои проблемы. Радикально решено только трассировкой лучей, которая всё ещё сложна и доступна только самым богатым.

Развитие видеоускорителей (до середины 2000-х)[править]

Унаследованы с прошлых поколений[править]

  • Спрайтовые клубы дыма.
  • Ошибки и условности анимации.
  • Растворяющиеся трупы.
  • Ограничения отражений.

Видна смена уровня детализации объектов[править]

Если и делают спрайты-заместители, то ставят их очень далеко. Зато модель уже не делают из минимума многоугольников, лишь бы форма узнавалась — поэтому появляются уровни детализации моделей. Для этих уровней детализации трилинейную фильтрацию уже никак не сделаешь, можно только сменять скачком. Артефакт хорошо заметен в Mafia: The City of Lost Heaven, когда у машины вдруг появляются стёкла!

    • Вовсе нет, смену ЛОДов можно совместить с подрисовкой следующего ЛОДа через полупрозрачность. Создаётся некий намёк на плавную подмену, но лучше грамотно моделировать ЛОДы, не полагаясь на автоматические алгоритмы, и выстраивать дистанцию видимости сообразно топологии модели и ракурса, под которым её будут наблюдать.

Глюки рэгдоллов[править]

Основная статья: Рэгдолл

В 2000 году вышел Hitman: Codename 47, ставший пионером алгоритмической анимации (так уж вышло, что без рэгдоллов там никак, ведь таскать трупы — часть геймплея). С тех пор и повелось: там, где персонаж себя не контролирует, анимировать алгоритмически. Алгоритмы там, как правило, простые (разностная схема Верле плюс кое-какие ограничения), потому трупы часто неестественно выворачиваются.

Современность (примерно 2007 и далее)[править]

Прошлые пункты захватывали 4–5 лет, этот — почти 10 (статья была написана примерно в 2017 году, но и через пять лет после этого эпоха не сменилась...). Причин этому много.

  • Компьютеры начали приближаться к физическому пределу транзисторной техники.
  • А вот трудоёмкость игр поднялась до предела и будет мало подниматься. Игроделы захватили всю публику, готовую играть, остаётся один резерв — оплата по частям (эпизоды и DLC).
    • Эпизоды в итоге "не выгорели" (взять хотя бы разорение Telltale, специализировавшейся на них), а DLC стали общим местом, несмотря на ворчание игроков.
  • Многим нужно окно в Интернет, да и всё, и желательно такое, чтобы можно было таскать с места на место. Это противоречит понятию «быстрый компьютер». Автор этих строк всё ещё играет с соседскими детишками в Unreal Tournament 99 — игра старше ребят. У самого-то компьютер тянет игру, не напрягаясь, а их машинки выдают 45 и 70 fps (на фанатских рендерерах, разумеется.)
  • А на стационарных рабочих местах — разрешение поднялось как никогда, расплодились многомониторные системы и 4K. Сделать бы на них картинку без тормозов…
  • А в консолях революция должна была пройти одномоментно: с появлением телевидения высокой чёткости количество пикселей на экране разом выросло в 6 раз.

Унаследованы с прошлых поколений[править]

  • Глюки рэгдоллов.
  • Ошибки и условности анимации.
  • Видна смена уровня детализации объектов.
  • Ограничения отражений.

Края объекта не несут рельеф[править]

Всё чаще используют рельефное текстурирование (бамп-мэппинг). Но когда неровности слишком велики, иллюзия пропадает, если посмотришь на ребро. Например, стена обшита вагонкой, а края абсолютно ровные.

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

Общая пластиковость внешнего вида[править]

Еще одна проблема бамп-мэппинга, когда на объект натягивается малоразмерная, излишне упрощенная карта нормалей. При этом грубая интерполяция совершенно не воспроизводит тонкие шерховатости, и предмет кажется залитым гладким, неровным пластиком. Проявляется в основном при текстурировании кожи, которая кажется пластиковой или скорее даже целлулоидной, как детская игрушка типа пупс. Надо ли говорить, что реализма это игровым персонажам не добавляет? Более того, зачастую персонажи из старых игр без бамп-мэппинга выглядели реалистичнее, чем персонажи из навороченнейших шутеров той эпохи.

  • По состоянию на 2023 год проблема не решилась, а стала ещё шире: разработчики применяют против "зловещей долины" мультяшность, а для того, чтобы пейзаж не слишком нагружал компьютер, не детализируют его, а увеличивают контрастность. Иногда им удаётся сделать так, чтобы стиль скрывал недостаток проработки, но чаще всего игра начинает выглядеть аляповато, а игроки смеются над тем, что она выглядит хуже, чем в 2010 году.

Заботливо замазанные ограничения слабого «железа»[править]

Основная статья: Мыльное кинцо

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

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

Раздутый размер игр[править]

Повторяющаяся проблема в разных "поколениях" компьютеров. Впервые она возникла ещё в 1980-х годах, когда игру обычно приходилось запускать с дискеты: в память компьютера она могла и не поместиться. Решилось распространением увеличителей объёма памяти, а затем жёстких дисков. Примерно в 1993-1998 годах, она проявилась вновь: жёсткие диски (размером до 5 Гб в среднем) могли вместить одну-две игры на CD (компакт-дисках размером 650-700 Мб) или тысячи игр на дискетах (одна игра занимала меньше 10 Мб).

Затем на долгие годы проблема, казалось, была решена: размер игр рос очень медленными темпами. В начале 2000-х годов нормой были игры не более 700 Мб, а если игра была крупнее - её можно было установить частично (остальные файлы загружались с диска, вставленного в привод; если игра на нескольких дисках - что было редкостью - то в игре появлялось сообщение с требованием сменить диск). Затем формат CD в бытовых компьютерах сменился на DVD, но и тогда игры были объёмом не более 2 DVD (около 8 Гб). Вполне можно было держать на одном ПК одновременно несколько десятков современных игр.

Но в 2010-х годах у многих разработчиков отказал инстинкт самосохранения... простите. У них перестала работать логика, подсказывающая работать с массовым пользователем - а следовательно, рассчитывать на не очень мощные компьютеры с небольшим объёмом памяти (и, понятное дело, получать больше дохода от благодарных масс). Поэтому они стали меньше оптимизировать игру и вкладывать усилия в архивирование её файлов, раздувая её объём. Уровень графики стал расти всё медленнее, иногда скатываясь назад, а размеры игр - всё быстрее. Кроме того, обычный пользователь чаще всего не может играть на высоких настройках - игра будет тормозить. В итоге снова постепенно откатываемся к положению 1990-х.

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

Вопиющие знаменитые примеры (по состоянию на 2023 год; дата выхода дана на ПК; кстати, ММОFPS и MMORPG не берём!):

  • Call of Duty: Black Ops Cold War (2020) - 250 Гб.
    • ремейк Call of Duty Modern Warfare (2019) - 231 Гб. Не в последнюю очередь из-за множества карт для сетевого режима. А длина сюжетной кампании уж очень невелика.
    • Call of Duty: Vanguard (2021) - 177 Гб.
    • Call of Duty: Infinite Warfare (2016) - 101 Гб. Был 13-й игрой в серии, и символично, что с него её закат стал очевидным.
    • Call of Duty: Black Ops 3 (2015) - 113 Гб.
  • Quantum Break (2016) - 178 Гб. Немалая часть размера обусловлена встроенным в игру сериалом (!) с живым видео. А в следующей игре Remedy всё вернулось в норму: Control занимает ненамного больше средней игры.
  • ремейк Hitman 2 (2018) - 150 Гб. Нужно учесть вновь сетевой режим, а ещё то, что игра включает в себя предыдущую часть.
  • Red Dead Rememption 2 (2019) - 115 Гб. При этом около половины локаций в заданиях не используется. С другой стороны, пейзажи, по мнению игроков, там красивейшие.
  • Borderlands 3 (2019) - тоже 115 Гб. Тут вообще непонятно, почему (ведь игра даже отдалённо не реалистично выглядит).
  • Assassin's Creed: Odyssey (опять 2018) - 110 Гб. Как и в RDR 2, из-за громадных локаций и проработанных текстур.
  • Middle-earth: Shadow of War (2017) - 95 Гб. Вновь большие локации и их количество.
  • Grand Theft Auto 5 (2015) - 90 Гб. Впрочем, в 2015 году она занимала около 50 Гб, а остальные 40 Гб занимают дополнения и патчи, из которых большинство предназначено для сетевой игры. И игрокам-одиночкам, к сожалению, нельзя не устанавливать всё это... хотя, с другой стороны, существуют модификации, переносящие контент сетевой игры в одиночную (и занимают они всего несколько Мб, так как контент в игре уже есть, но недоступен).
  • Final Fantasy XV (2018) - 86 Гб. Хотя тенденция была задана ещё Final Fantasy XIII (2010): она занимала тогда целых 38 Гб, что втрое превышало объём любой ААА-игры 2010 года. В то же время все последние FF критикуются за однообразные локации второй половины игры.
  • Forza Horizon 4 (2020) - 77 Гб. При этом аналогичные по графике гоночные игры занимают 25-35 Гб (например, Dirt Rally).
  • Deus Ex: Mankind Divided (2016) - те же 77 Гб. При этом игру критикуют за оборванный посредине сюжет и краткость прохождения.
  • Metro Exodus (2019) - 70 Гб. Потрачено на большие локации (однообразные и неоптимизированные).
  • Half-Life: Alyx (2020) - 68 Гб. Причина в том, что это VR-игра, а на реализацию данной технологии требуются дополнительные текстуры.
  • Death Stranding (вновь 2020) - 64 Гб. Снова большие локации.
  • специальная награда для Warcraft III: Reforged (2020) - 27 Гб. Казалось бы, это гораздо меньше, чем у "конкурентов" по этому списку, но это же ремейк игры, которая (вместе с дополнением Frozen Throne) занимает всего 1,5 Гб! И заметьте: уровень графики видеороликов не слишком поднялся (а иногда и опустился), а в самой игре наибольшим изменениям подверглись анимации персонажей и войск, но не игровая карта.

Шутеры (всех поколений)[править]

Невозможно увидеть ноги[править]

С появлением трёхмерности можно смотреть по полной сфере, 4π стерадиан. А ноги-то свои не увидишь никак!

Исключения можно пересчитать по пальцам, даже на 2016 год.

Большая пушка пересекается со стеной[править]

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

Гонки (всех поколений)[править]

Адаптация интерьера кабины под мониторный угол зрения и прикрученный к столу контроллер-руль[править]

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

В первых трёхмерных гонках (The Need for Speed, IndyCar 2, Grand Prix 2) была вообще старательно прорисованная двухмерная кабина.

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

Адаптация гоночной сигнализации под мониторный угол зрения[править]

  • rFactor буквально спамит стартовыми светофорами. Другие игры отображают светофоры в углу экрана.
  • Grand Prix Legends: несмотря на полнейший хардкор (не было даже спидометра и часов — просто потому, что в тогдашней «формуле» их действительно не было), таблички отображались увеличенно в углу экрана.

Странное поведение рук пилота[править]

  1. У всех машин, кроме картов, руль ходит как минимум на 3/4 оборота в каждую сторону. В гонках — часто на 120°, и всё.
  2. Когда реальный пилот за компьютером нажал на кнопку переключения, виртуальный пилот всё ещё держит руки на руле. Потому рука едва ли не телепортируется к рычагу.

Потому хардкорные симуляторы часто отключают виртуальные руки (а то и виртуальный штурвал).

А теперь представьте себе такую же ситуацию в кабине тепловоза — а лучше в рубке пассажирского лайнера! Игры, в которых аватар игрока «играет на органе» в кабине, можно пересчитать по пальцам одной руки. Обычно тело скрыто, так как это нетривиальная (а иногда — неосуществимая) задачка. В эпоху виртуальной реальности открывает новые возможности для игрока.

Связанные с живой съёмкой[править]

  • 3D-фон не поспевает по качеству за живой съёмкой.
    • Живой актёр разговаривает с явно компьютерными войсками (C&C).
  • Плохо объединили рендеренный фон и живую съёмку.
  • «Эффект портрета», например, в realMyst. Живой спрайт «следит» за игроком.
  • Зелёные отражения от «зелёного экрана».

Связанные с пререндерами[править]

  • Marvel’s Spider-Man 2018 года — вместо традиционных непрозрачных окон и честного рендера комнат за окном в виде ниши в стене на стены налепили гипертекстуру с уже отрендеренной комнатой, которая меняет свой внешний вид в зависимости от угла зрения. Но только вот забыли про угловые комнаты. В результате на западной стене мы заглядывали в окно и видели, что на юг окна не выходят. А снаружи на юге окно, заглядывали туда — и видели, что на западе окон нет (да и вообще комната какая-то совсем другая стала). А счастье было так возможно — всего-то навесить каждой комнате правильную гипертекстуру, в которой есть хотя бы непрозрачное окно (а через два стекла под прямым углом даже IRL почти ничего не видно).

Примечания[править]

  1. У CGA четыре цвета и четыре палитры в теории, чаще всего две на практике: бело-розово-голубая и зелёно-жёлто-красная плюс цвет фона (в теории любой из 16 возможных, на практике чёрный). Зато, в отличие от многих других компьютеров того времени, никаких конфликтных зон. И плюс ультра-лоу-рез 160×100 с 16 цветами сразу (чреватый «снежком» на экране). У EGA любые 16 цветов из 64 доступных.
  2. Так, конфликт одновременного доступа к видеопамяти, который в виде бага предстаёт «снежком», в виде багофичи позволяет в том же CGA каждую строчку выводить в своей палитре + свой цвет фона из 16, что даёт изрядно-до-фига цветов. Делается это примерно так (не гарантирую, что на 8086, где был актуален CGA, ресурсов хватит, но на 286-х по идее работать должно):
    • Выделяется память под промежуточный фреймбуфер 321×200, где лишний байт в начале строки кодирует как раз палитру и фон для этой строки. Ну, или отдельно буфер 320×200, а отдельно 200 байт для палитр (так быстрее копировать).
    • Таймер часов реального времени ускоряется в N раз, DOS такое прощала (однозадачность же, мешать некому. А сама ОС утрётся, она не гордая). N должно быть таким, чтобы частота была чуть выше строчной.
    • Ставится кастомный обработчик прерывания от таймера, который раз в N вызовов дёргает стандартный (итого часы идут с той же скоростью).
    • Помимо этого, обработчик ждёт, пока бит D0 регистра ISR0 не станет 1. Это значит, что строка закончена и луч двигается обратно.
    • Если бит D3 регистра ISR0 тоже стал 1, то это была последняя строка. Нужно скопировать буфер 320×200 в видеопамять, чтобы не поиметь уже настоящий «снежок» (ну, или перерисовать спрайты и прочие обновлённые части экрана, если у нас нет ресурсов проца и памяти на полноценный первый пункт).
    • Если же D0 == 1, а D3 == 0, то это не последняя строка (тут приходится самим считать, в который раз нас вызвали), и нужно скинуть в регистр CSR тот самый дополнительный байтик от данной строчки, чтобы она отрисовалась уже в нужной палитре.
    • Всё остальное время (пока процессор в основном коде, а не в обработчике прерывания) идёт обычный процесс обсчёта игры и заполнения этого самого фреймбуфера, причём с попытками более-менее оптимально подогнать палитры для каждой строчки (реально, конечно, кадр тупо разбивается на «вода-лабиринт-небо» и каждая часть так и остаётся в своей палитре, dithering там никто делать не станет, не те ресурсы процессора. Да там даже рисование спрайта нецензурно ресурсоёмкое бывает! Куда уж там подгонять палитры по месту). Часть этого процесса (ту, которая допускает постоянные перерывы на чтение ISR0) можно вынести в обработчик прерывания, чтобы не ждал конца строки в пустом цикле, ресурсов у нас и так настолько ниже плинтуса, что про скроллеры можно забыть — хорошо, если у платформера успеешь спрайты перерисовывать.
    Бывает, конечно, просто покомандная синхронизация процесса игры и подмены палитры, но это или самогенерирующийся код (а это уже демосцена, целую игру фиг нагенерируешь) или оно работает только ровно на том железе, под которое написано (это ж не игровая приставка, и замени тут 8088-й 8086-м или совместимым аналогом, и вся синхра посыплется).
  3. Мы не будем распространяться, что ещё надо было бы сделать по-другому, чтобы не войти в "25 худших проектов за всю историю вычислительной техники", но в 1983-м году уже была, мягко говоря, не в моде конфигурация с 1-2 сегментами по 64Кб, так что идея привязать адресное пространство к одному сегменту достаточно очевидна. В максимуме, со всеми апгрейдами ("640Кб хватит каждому" и 64Кб видеопамяти) получается отличное, кратное разложение на 384 строки по 512 точек, объединённых в группы 4х3 (то есть 128х128 групп). Каждой группе сопоставляется один dword, в котором прекрасно умещаются сами пикселы (12 бит), 10 бит цвета фона (3-4-3, потому что к зелёному глаз более чувствителен; позже мы увидим подобное в SVGA) и 10 бит цвета пиксела. Если забить на 8 строк сверху и снизу и оставить их чёрными, получается NTSC-совместимый режим, который не стыдно и к телевизору подключить (домашнюю систему ведь делаете, ироды!) Ну, а для стартовых конфигураций, конечно, нужны режимы поскромнее - сами придумайте их для своего "попаданца в IBM 80-х". Конечно, всё равно потом не избежать постраничного доступа к памяти размером более 64К, производящегося через окно в 64К - но это всё будет потом, а на фоне "Спектрумов" иметь на платформе IBM PC с её мегабайтом адресуемого пространства не подлежащий никакому апгрейду TGA, тем более для бытового сегмента - однозначно адаптер курильщика.
  4. В 256-цветовых режимах существовал очень простой и быстрый (по сравнению с тупым суммированием RGB) способ отображения прозрачных объектов. Для каждого из типов прозрачности готовим таблицу 256×256: что впереди, что на фоне — что в результате будет. Для поверхностей с априори ограниченными цветами (16 оттенков синего для воды, 4 оттенка серого для стекла, 32 оттенка оранжевого и красного для огня и т. д.) можно было брать меньшие таблицы — 256×16, 256×4, 256×32. Использовалось в продвинутых версиях движка Doom — Heretic, Hexen, порты Doom. Особым образом собрав таблицу, можно сделать, чтобы огонь был прозрачным, а палка — нет, при том, что весь факел — один спрайт! Каждая таблица занимала 64k памяти, таблиц обычно делали четыре-пять для разных видов объектов, да и на первых порах такты приходилось жёстко экономить — потому применяли уже в играх с хорошими требованиями вроде ЦП 80486, ОЗУ 8 мегабайт. Да и, учитывая то, что для каждого пиксела пришлось бы рендерить воду, дно и залезть в таблицу — дальше спрайтов по понятной причине дело не пошло.