Bullets [s2]) then begin

// Попавшая пуля перемещается за границы экрана

Bullets [s2].PosY := -10;

DeadMonster (s1); // Заменить образ монстра

end;

// Столкновения монстров, берутся в расчет только живые чудовища

for s1 := 0 to NumMonsters - 2 do

for s2 := si + 1 to NumMonsters - 1 do

if Monsters [s1].Live and Monsters [s2].Live and

SpritesCollidePixel (Monsters [si], Monsters[s2]) then begin

Monsters [si].Hit(Monsters [s2]);

Monsters [s2].Hit(Monsters [si]);

end;

Result := DDJDK;

end;

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

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

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

Скорость работы игры повысилась существенно, инициализация и восстановление происходят мгновенно, и нет ощутимой паузы в моментах замены картинки спрайтов.

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

Образы спрайтов хранятся в единственном компоненте класса Timage (рис. 5.5).

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

procedure TWarrior.Show;

begin

if Direction = dirRight

// rcRect устанавливается в координатах образа, хранящего все картинки

then SetRect (rcRect, 0, 70, SpriteWidth, 70 + SpriteHeight)

else SetRect (rcRect, SpriteWidth, 70, 2 * SpriteWidth, 70 +

SpriteHeight);

// Осуществляется блиттинг FDDSImages, а не поверхности спрайта

frmDD.FDDSBack.BltFast(PosX, PosY, frmDD.FDDSImages, @rcRect,

DDBLTFAST_DONOTWAIT or DDBLTFAST_SRCCOLORKEY);

end;

Также этот пример отличается от предыдущего тем, что пространство игры не ограничивается одним экраном, воин может продвигаться дальше правой границы, всего я использую два растровых фона, каждый размером 640x480 пикселов. Напоминаю, что некоторые видеокарты не позволяют создавать поверхности, превышающие в размерах первичную поверхность. Поэтому для хранения этих растров использую две поверхности - Foosone и FDDSTWO. Значение целочисленной переменной iftRect указывает ширину прямоугольника, вырезаемого из второй поверхности:

SetRect(rcRectOne, IftRect, 0, ScreenWidth, ScreenHeight);

// Первый фон

FDDSBack.BltFast(0, 0, FDDSOne, @rcRectOne, DDBLTFAST_WAIT);

if IftRect > 0 then begin // Присутствует ли часть второго фона

SetRect(rcRectTwo, 0, 0, IftRect, ScreenHeight);

FDDSBack.BltFast(ScreenWidth - IftRect, 0, FDDSTwo, SrcRectTwo,

DDBLTFAST_WAIT);

end;

Работа с клавиатурой

При изучении двух предыдущих примеров вам, наверняка, не понравилась скорость перемещения нашего воина, и, возможно, вы гадали, почему я не установил величину приращения побольше. Объяснение вы найдете в настоящем разделе.

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