Улучшенная битовая графика и специальные эффекты

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

В этой главе вам встретятся некоторые Действительно интересные (и, вообще-то, довольно простые) программы. Они создают такие же сложные и реалистичные эффекты, как те, которые вы наверняка видели в компьютерных играх. Также на этих страницах вы узнаете о таком сложном приеме работы с растровой графикой, как масштабирование. Итак, в этой главе:

§ Ускорение процесса двоичного кодового преобразования (бит-блиттинга);

§ Применение логических операций;

§ Кодирование прозрачности;

§ Битовое отсечение;

§ Контроль столкновения спрайтов;

§ Дублирующая буферизация;

§ Использование сигнала вертикальной синхронизации;

§ Мультипликация с помощью цветовых регистров;

§ Освещение ваших игр;

§ Связь мультипликации с контекстом;

§ Мультипликационное движение («animotion»);

§ Прокрутка;

§ Специальные эффекты;

§ Текстуры;

§ Масштабирование растровых изображений;

§ Повороты растровых изображений.

Итак, больше дела, меньше слов!

Ускорение процесса двоичного кодового преооразовзния (бит-блиттинга)

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

При работе с такими играми (трехмерные игры, подобные Wolfenstein 3D или DOOM) компьютер большую часть времени тратит на прорисовку стен в трехмерном пространстве или на изображение двухмерных образов спрайтов, представляющих игровые объекты. Мы обсудили изображение в трехмерном пространстве в шестой главе, «Третье измерение». Поэтому теперь я хотел бы остановиться на вопросе оптимизации вывода спрайтов, поскольку это нам особенно понадобится при создании игр данного типа.

В предыдущих главах мы разобрались с понятием бит-блиттинга (глава пятая, «Секреты VGA-карт») и рассмотрели, как передается растровое изображение из одной области памяти в другую. Держу пари, что 90 процентов времени при создании игр уходит на то, чтобы придумать, как ускорить эти процессы. В восемнадцатой главе, «Техника оптимизации», мы обсудим общую теорию оптимизации и разберем несколько примеров использования соответствующей техники после завершения работы над игрой. (Не забывайте о том, что все оптимизационные трюки следует применять на заключительной стадии разработки игры!) Вы должны четко представлять, что для каждой новой игры необходимо заново создавать и реализовывать подходящие алгоритмы битового замещения; более того, вы можете исгюльзовать от двух до пяти различных способов бит-блиттинга в одной и той же игре. При этом каждый из них будет предназначаться для вполне конкретного случая. Например, вы можете обнаружить, что можно оптимизировать функцию бит-блиттинга для объектов, которые на протяжении всей игры остаются неподвижными. Если это так, создайте два преобразования: одно — для движущихся объектов, другое — для стационарных. Код для каждого процесса бит-блиттинга занимает примерно один-два килобайта ияи даже меньше.

Рассмотрим еще один пример возможной оптимизации. Естественно, что чтение данных вашей функцией бит-блиттинга определенным образом зависит от способа их хранения. И возможно, преобразование будет происходить быстрее, если представить данные в другом виде. Например, вы можете потерять эффективность, сохраняя значения пикселей построчно (в виде двухмерной матрицы), а не по столбцам (по 16 бит). Если иная форма хранения данных дает выигрыш в производительности для некоторых из ваших алгоритмов бит-блиттипга, напишите для них процедуру предварительного преобразования этих данных.

В любом случае, думайте о том, как максимально ускорить процесс бит-блиттинга. Ведь в компьютерной игре на экране присутствуют в среднем от 2 до 20 объектов размером примерно 32х32 пикселя, а это достаточно много для работы в реальном времени.

Примечание

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

Рассмотрим еще один важный аспект бит-блиттинга объектов, который вы сможете с выгодой использовать. Если вы твердо знаете, что размер ваших объектов будет фиксированным (например, 16х16 или 32х32), то можете написать отдельный алгоритм бит-блиттинга, специально оптимизированный для каждого из этих размеров. Помните: не существует общих правил быстрого написания компьютерных игр. Нет уже готовых алгоритмов и написанных кем-то библиотек. Вы должны будете использовать по максимуму весь свой творческий потенциал. Только, не пугайтесь. Даже самая замысловатая игра использует алгебру и геометрию не более чем на уровне высшей школы. Это, конечно, не значит, что вы не можете использовать сверхсложные алгоритмы и забираться в дебри, высшей математики. Однако в результате может оказаться, что двенадцатилетний подросток найдет путь в 100 раз более быстрый и эффективный только потому, что он не такой умный как вы!

Применение логических операций

Для того чтобы переместить образ (процесс блиттинга) на экран или даже вынести его за пределы рабочей области экрана, можно выполнять логические операции с исходными и результирующими пикселями. Если вы внимательно посмотрите на функцию DrawSprite () в Листинге 5.13 пятой главы, «Секреты VGA-карт», то увидите, что она на самом деле не просто замещает данные, а предварительно проверяет их тип:

§ Если пиксели «непрозрачные (то есть они не черного цвета), то на экране происходит замена исходных данных соответствующими пикселями;

§ Если пиксели «прозрачны», то экранные данные остаются без изменений.

Все происходит так, как если бы в объекте имелись дырки, через которые можно смотреть. Для получения " прозрачности" нужно поместить внутрь цикла бит-блиттинга условный оператор примерно следующего вида:

if ((data=work_sprite[work_offset+x]))

video_screen[offset+x]=data;

Оператор IF выполняется много раз. Если быть точными, то число повторов этой операции равно произведению высоты спрайта на его ширину. Так для образа 64х64 это составит 4096 раз. Не слишком ли много?!

Однако в некоторых случаях можно отказаться от использования оператора IF и выводить спрайт без проверки пикселей на «прозрачность». Если нарисованный нами спрайт имеет точно прямоугольную форму и целиком занимает объем 64х64 пикселя, исходные данные без ущерба можно замещать на реэультирующие (конечно, если внутри самого изображения нет «прозрачных» областей). Увы, так бывает довольно редко! Конечно, в подобных случаях мы можем применять и такой вариант блиттинга (например, при текстурировании стен), но, тем не менее, попробуем найти «золотую середину» между использованием оператора IF и функции memсру ().

Один из способов размещения данных на экране состоит в употреблении поразрядных логических операций типа OR, XOR, AND и NOT. Таким образом, мы можем воспользоваться ими вместо оператора IF, поскольку они быстрее обрабатываются центральным процессором. Осталось только выяснить совсем немного — какой же из логических операторов применить и что он будет делать? Вспомним, как представлены данные в режиме 13h. Каждый пиксель задается одним байтом, значение которого используется в качестве индекса в таблице выбора цвета. Если мы начнем производить логические операции с исходными и результирующими пикселями, то изменим индекс цвета, а, следовательно, и сам цвет, чего нам совсем не нужно!

Рассмотрим несколько примеров. Допустим, мы отображаем пиксель красного цвета (со значением 10) на экран в точку (100, 100), в которой уже находится розовый пиксель (56). В результате отображения мы хотели бы увидеть на экране наш красный пиксель (10) в положении (100, 100). Однако при использовании имеющихся в нашем распоряжении логических операций, вместо этого мы получим значения, приведенные в таблице 7.1.

Таблица 7.1. Результаты логических операций.

Дано: 56 - 00111000b и 10 = 00001010b:

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

Однако нам никто не запрещает совершить более одной логической операции с исходными и результирующими данными для достижения желаемого результата. Мы можем делать все, что захотим, но главное при этом — не потерять тот выигрыш в быстродействии, который мы получаем при использовании логических операций. Ведь оператор IF осуществляет только два действия: сравнение и переход в нужное место. Так не окажется ли применение оператора IF более целесообразным, нежели многократное повторение логических операций? Чтобы выяснить это, давайте сравним коды, реализующие оба способа (Листинги 7.1 и 7.2), и посмотрим, как обстоят дела на самом деле.