Редактирование: Игровые спецдефекты

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

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

== CGA, EGA и тому подобные ==
: См. также '''''[[Проекции графики]]'''''.

Особенностью видеорежимов было ограниченное число цветов в видеорежиме, обычно четыре цвета<ref>У CGA четыре цвета и четыре палитры в теории, чаще всего две на практике: бело-розово-голубая и зелёно-жёлто-красная плюс цвет фона (в теории любой из 16 возможных, на практике чёрный). Зато, в отличие от многих других компьютеров того времени, никаких конфликтных зон. И плюс ультра-лоу-рез 160×100 с 16 цветами сразу (чреватый «снежком» на экране). У EGA любые 16 цветов из 64 доступных.</ref>. При попытке обойти это ограничение возникали глюки. Наиболее крутые разработчики использовали эти глюки как [[Багофича|багофичи]], показывая картинку, невозможную для стандартного отображения без глюков<ref>Так, конфликт одновременного доступа к видеопамяти, который в виде бага предстаёт «снежком», в виде багофичи позволяет в том же 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-м или совместимым аналогом, и вся синхра посыплется).</ref>.

Так, в игре Saboteur 2 для PC ниндзя был красный! Смеялись даже: пусть лучше будет зелёный, был бы ниндзя-черепашка! А в некоторых менее динамичных играх использовали 160×100×16, чуть сглаживая этот кошмар обильной псевдографикой (с её помощью можно было получить разрешение чуть получше), но рисовать её было весьма накладно в плане процессорного времени (а «камни», как известно, тоже были те ещё). Нет, [https://int10h.org/blog/img/1k03_16c_cga_ansi_from_hell.png такую прелесть] в те годы не рисовали (это современная демка), но нарисовать среди 160×100 хотя бы глазки или кисть руки — такое встречалось.
{{video|1PI6GwKVAeY|Легендарный "color clash" на Спектруме!}}
Из категории «тому подобных» нельзя не упомянуть Спектрум, где отсутствовавший в CGA механизм «два цвета на знакоместо» таки был! Фирменный спецдефект таких систем — т. н. «конфликт атрибутов». Это, конечно, на две головы лучшая графика, чем CGA (хотя железо даже дешевле и тупее), но спецдефект таки «имел место быть». Поподробнее о нём [https://habr.com/ru/post/472232/ тут] (серьёзно, если бы эта идея озарила кого-нибудь примерно в 1993-м, когда «Спекки» был уже совсем не роскошью, не в пример «Айбиэмке», дальнейшее развитие предугадать несложно. ZX-Poly был бы роскошью, но доступной, и у кого-то бы он был. Разбрасываться 4 процами бы никто не стал, следующий софт бы писался уже с тем, чтобы они не полностью дублировали поведение друг друга, затем появился бы SIMD-процессор, потом одной штуки бы снова стало мало, в общем, лет через 5 «Спек» уверенно пёр бы по пути кластерных вычислений («много слабеньких камней вместо одного большого»). И, вероятно, сборола бы его только CUDA. А может, и она бы не осилила).

{{note|dr| Вообще история графики в «пека» — это история одного огромного фейла. IBM почему-то ставила на графические подсистемы людей с марсианской логикой, обеспечивших «Эпплу» длительное процветание в области, где была нужна хоть какая-то графика.
* 1981 — MDA, не умеющий нарисовать простенькой диаграммы (хотя памяти, в теории, хватило бы на 180x175 в монохроме, если использовать двойные скан-линии). «У нас машины для серьёзного бизнеса, им графика не нужна». Это не говоря уже о возможности просто разбить скромную видеопамять (а именно она определяла цену — двухпортовые чипы стоили немало) на 6 банков, использовать стандарт разложения, опирающийся на общепринятый NTSC (640x480 при 16 цветах), и, получив в итоге 6 строк, генерировать в конце каждой строки аппаратное прерывание (IRQ), чтобы процессор подрисовал следующую (хватило бы и двух, но раз есть память на 6, а увеличение разрешения удорожит остальные узлы…) Впрочем, для этого нужно психологически примириться с тем, что у нас давно не мейнфрейм с терминалами, где процессорное время используется полностью, а именно что ''персоналка'' (посчитала график — показывает график, юзер думает над ним — проц простаивает, так пусть и обновляет пару пикселов в каждой строке, для рисования кривой больше и не нужно; Atari 2600 уже давно так умела и при этом оставалось на саму игру, но это требовало лютых усилий от программиста, а тупо рисовать диаграмму для физика или pie chart для экономиста проще раз в 20). А деление на «монохромный/цветной» по уму относится к монитору, а не всей системе «видеокарта-формат кадра-протокол видеосигнала-монитор», например, monoVGA выпускаются до сих пор. Парадокс в том, что в картах того поколения не было DAC, поэтому что один канал, что четыре — на себестоимость карты это практически не влияло (в отличие от объёма двухпортовой памяти), а дороже был именно что сам цветной монитор, т. е. наличие второго (цветного графического, но кладущего процессор) режима не было бы чем-то заметным в итоговом ценнике.
* 1981 — CGA, не умеющий выключать знакогенератор в режиме низкого разрешения. В результате программисты ''использовали символы, у которых в верхних двух рядах пикселов была подходящая форма''. Плюс странный режим 640х200 и ничего общего в плане совместимости с MDA. Совершенно самостоятельная ветка, предназначенная именно для игр (даже есть хитрый выход на NTSC с намного более качественными цветами). При этом разрешение в текстовом режиме так себе, из-за чего при закупке приходилось выбирать. Вдобавок, даже работая на разных адресах, карты вместе не уживались — легендарный Питер Нортон упоминает машины с открытыми крышками, в которых приходилось переставлять адаптеры в зависимости от того, какой именно софт надо запустить! Каждый раз, конечно, с полным отключением и ручной парковкой жёсткого диска.
* 1982 — Фирма Hercules на пальцах объяснила IBM, что несовместимость MDA и CGA была на редкость бессмысленным ходом. Закон Мура устаканился ещё в 1975-м, и MDA был нужен только чтобы «день простоять да ночь продержаться» — урезанный CGA с такими же адресами, но урезанной видеопамятью и за счёт этого монохромным 80х25 был бы тем же самым по цене и возможностям, что и MDA, но не оставил бы пользователей, успевших купить MDA, с тупиковой ветвью на руках. В итоге IBM подарили «Геркулесу» долю на рынке для целой линейки.
* 1983 — а почему никто не помнит IBM PCjr и его видеоадаптер VGA (не путать с VGA 1987-го!)? А потому что даже сама IBM предпочитает лишний раз не вспоминать про PCjr. Тем не менее, он нашёл своё второе рождение в компьютере Tandy 1000, будучи переименованным в TGA и слегка модифицированным. По сути это был тот же CGA, но теперь несколько расширенный: появились дополнительные режимы 320×200×16 и 640×200×4, и наконец-то можно было выбирать палитру из любых доступных цветов (правда, всего 16-ти), а не из трёх палитр одна вырвиглазнее другой. И да, адаптеры оригинального PCjr и Tandy 1000 были ''немножечко'' несовместимыми в плане распределения видеопамяти<ref>Мы не будем распространяться, что '''ещё''' надо было бы сделать по-другому, чтобы не войти в "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, тем более для бытового сегмента - однозначно адаптер курильщика.</ref>.
* 1984 — ладно Эппл, но уже два года как прогремели «Спектрумы», «Коммодоры» и всякие прочие «Амиги». В EGA же был только запоздалый пинок «Геркулесу», неполная совместимость с CGA и никаких спектрумо-подобных режимов с высоким разрешением графики и низким разрешением цветности (т. е. когда есть два цвета на область примерно 3х3, и вместо 9 байт они кодируются только двумя: первый выбирает из 16-цветной палитры цвет фона и цвет переднего плана, а второй задаёт, какие именно пикселы имеют цвет переднего плана, а какие — фона. И да, для кодирования 9 пикселов достаточно 8 бит, потому что можно переставить нибблы байта атрибутов и таким образом задать цвет 9-го). Хотя возможности, в принципе, уже позволяли создать линейно-развиваемую систему с расширяемой видеопамятью, в которой разрешение просто меняется путём задания в регистрах надлежащей скорости сканирования.
* 1984 — PGC. Шикарный графический монстр, сводившийся к ещё одному XT в слоте расширения первого. Великолепная 3D-графика, заточенная наконец-то под серьёзные САПР, и невозможность как-то ещё его использовать. Такая как бы CUDA наоборот — не графический процессор, которому дали возможность считать неграфическую нагрузку, а обычный процессор, который лишили возможности считать таковую. Предсказуемо продержался всего 3 года и развития не имел, хотя просто правильным BIOS'ом можно было буквально сделать две машины в одной. Плюс, из-за компактности, он был дороже многих конфигураций «просто XT».
* 1987 — наконец-то всё на регистрах! В VGA можно было очень гибко задавать пределы сканирования, частоты, выбирать режимы и цвета (ну, кроме описанного спектрумо-подобного режима, подобие которого программисты вымучивали ещё в CGA и который легко делается отключением знакогенератора, потому что у знакоместа и так есть атрибуты фона и цвета, осталось только выключить сам символ и вместо него взять биты его кода). Видимо, IBM решила, что изобрела что-то настолько гениальное, что у них обязательно это украдут, и '''закопирастила инструкцию на адаптер!!!''' Нет, серьёзно. Инструкция была материалом для внутреннего пользования. В результате видеокарты работали от силы на ½ своих возможностей — т. е. в тех режимах, которые IBM же предусмотрела в своём говноBIOSе (про X-Mode знают все, а все ли в курсе, что там был, например, похоронен аппаратный сплитскрин?) Это, наверное, был апогей идиотии. Эппл продолжал безраздельно царствовать на рынке графики и ржать, как индюк, плывущий галопом (а процессора IBM Power PC, который IBM им скармливала, ещё не было, так что даже косвенной прибыли IBM с «Маков» не имела).
* 1989 — специально с целью оттереть идиотов от дальнейшего захламления рынка кадаврами, был создан VESA, тут же разродившийся SVGA (заради чего и был, собственно, создан). Цирк уродов кончился, собственный IBM'овский XGA послали лесом, началось триумфальное шествие карт и мониторов высокого разрешения, причём, зараза, [[А что, так можно было?|совместимых]] при помощи VBE!
* 1996 — не без участия отца Quake Джона Кармака на арену выходят графические ускорители, демонстрируя, «как надо». Абсурдная ситуация, когда абсолютно доминирующая на рынке платформа из-за криворукости одного подразделения бездарно сливает разрозненным конкурентам, прекратилась. Apple подпрыгивает в ужасе и начинает упирать на «элитарность продукции», производители консолей судорожно крестятся и скупают геймдевов, чтобы удержать покупателей эксклюзивами. Догнали наконец.}}

== Шутеры поколения Wolf3D ==
{{main|Псевдотрёхмерность}}

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

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

== Шутеры поколения Doom ==

=== Унаследованы с предыдущих поколений ===
* Ограниченные проекции спрайтов

=== Непрозрачная синяя вода по щиколотку ===
Рендер полупрозрачных поверхностей очень сложен, когда им занимается процессор, да и поверхность сложной формы, да и большая к тому же…<ref>В 256-цветовых режимах существовал очень простой и быстрый (по сравнению с тупым суммированием RGB) способ отображения прозрачных объектов. Для каждого из типов прозрачности готовим таблицу 256×256: что впереди, что на фоне — что в результате будет. Для поверхностей с априори ограниченными цветами (16 оттенков синего для воды, 4 оттенка серого для стекла, 32 оттенка оранжевого и красного для огня и т. д.) можно было брать меньшие таблицы — 256×16, 256×4, 256×32. Использовалось в продвинутых версиях движка Doom — Heretic, Hexen, порты Doom. Особым образом собрав таблицу, можно сделать, чтобы огонь был прозрачным, а палка — нет, при том, что весь факел — один спрайт! Каждая таблица занимала 64k памяти, таблиц обычно делали четыре-пять для разных видов объектов, да и на первых порах такты приходилось жёстко экономить — потому применяли уже в играх с хорошими требованиями вроде ЦП 80486, ОЗУ 8 мегабайт. Да и, учитывая то, что для каждого пиксела пришлось бы рендерить воду, дно и залезть в таблицу — дальше спрайтов по понятной причине дело не пошло.</ref> Приходилось поступать очень просто: погружать героя в пол на полтора дециметра, тупо снижением точки камеры намекая, что он как бы ушёл ногами в как бы жидкий как бы «пол» сектора, ну и максимум ещё нарисовать исходящие от его движений волны на этом полу (очевидно, такие же плоские). Встречалось даже на движке самого Doom, но уже только в фанатских картах, вовсю эксплуатирующих незапланированные багофичи.

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

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

=== Отображение стен по столбцам ===

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

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

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

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

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

== Симуляторы дотрёхмерной эры ==

Думаете, первые игры, где была трёхмерность,— шутеры? Нет, это были симы. Первый из ПК’шных — ''Aviator'' за авторством небезызвестного Джеффа Крэммонда. Впоследствии он же сделал автомобильный ''REVS''.
* Дискретные положения руля, более точно поворот руля показывается меткой (''Grand Prix Circuit'').
* Полигональный кузов, а из него торчит спрайтовый шлем (серия ''IndyCar'').
* Ограничения по повороту камеры. Например, в первом ''[[Need for Speed|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», который за счёт масштабирования и вращения фона правдоподобно [https://youtu.be/DFRlPjG1sio?t=205| имитировал 3D под любым углом обзора], в отличие от параллаксной прокрутки. В видео по ссылке нет ни грамма 3D. Неприятный недостаток — невозможность имитации ландшафта, «трёхмерность» абсолютно плоская. Хотя некоторые разработчики и с этим справлялись (Super Star Wars Empire Strikes Back, уровень с шагоходами AT-AT).
* Спрайтовые клубы дыма, как без них…

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

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

Разве что стратегии, которым нужно много юнитов, отстают на поколение по качеству моделей. В те времена трёхмерных было мало ([[Ground Control]], [[Total Annihilation]], [[WarZone 2100]]; существовали [[воксель]]ные образчики вроде [[Myth]] или [[Command & Conquer|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]], когда у машины вдруг появляются стёкла!
** Вовсе нет, смену ЛОДов можно совместить с подрисовкой следующего ЛОДа через полупрозрачность. Создаётся некий намёк на плавную подмену, но лучше грамотно моделировать ЛОДы, не полагаясь на автоматические алгоритмы, и выстраивать дистанцию видимости сообразно топологии модели и ракурса, под которым её будут наблюдать.

=== Глюки рэгдоллов ===

{{main|Рэгдолл}}

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

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

Прошлые пункты захватывали 4<nowiki>–</nowiki>5 лет, этот — почти 10. Причин этому много.
* Компьютеры начали приближаться к физическому пределу транзисторной техники.
* А вот трудоёмкость игр поднялась до предела и будет мало подниматься. Игроделы захватили всю публику, готовую играть, остаётся один резерв — оплата по частям ([[эпизодическая игра|эпизоды]] и [[DLC]]).
* Многим нужно окно в Интернет, да и всё, и желательно такое, чтобы можно было таскать с места на место. Это противоречит понятию «быстрый компьютер». Автор этих строк всё ещё играет с соседскими детишками в Unreal Tournament 99 — игра старше ребят. У самого-то компьютер тянет игру, не напрягаясь, а их машинки выдают 45 и 70 fps (на фанатских рендерерах, разумеется.)
* А на стационарных рабочих местах — разрешение поднялось как никогда, расплодились многомониторные системы и 4K. Сделать бы на них картинку без тормозов…
* А в консолях революция должна была пройти одномоментно: с появлением телевидения высокой чёткости количество пикселей на экране разом выросло в 6 раз.
=== Унаследованы с прошлых поколений ===

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

=== Края объекта не несут рельеф ===

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

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

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

{{main|Мыльное кинцо}}

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

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

== Шутеры (всех поколений) ==

=== [[Призрак от первого лица|Невозможно увидеть ноги]] ===

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

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

=== Большая пушка пересекается со стеной ===

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

== Гонки (всех поколений) ==

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

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

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

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

=== Адаптация гоночной сигнализации под [[мониторный угол зрения]] ===
* ''[[Симрейсинг|rFactor]]'' буквально спамит стартовыми светофорами. Другие игры отображают светофоры в углу экрана.
* ''Grand Prix Legends'': несмотря на полнейший [[хардкор]] (не было даже спидометра и часов — просто потому, что в тогдашней «формуле» их действительно не было), таблички отображались увеличенно в углу экрана.

=== Странное поведение рук пилота ===

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

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

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

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

== Примечания ==
<references />

{{Nav/Games}}