ZX News #02 30 ноября 1996

Программирование

Как устроены игрушки - статья о том как делаются игры лабиринтного типа с большим игровым пространством.

(C) Bob Klubov.


        Как устроены игрушки.


 В  этой  статье  пойдет речь о том, как
делаются   игры   лабиринтного   типа  с
большим    игровым   пространством.   Мы
затронем  вопросы  связанные с графикой,
ее хранением и использованием.
 Еще   давно,   когда  я  играл  в  свой
кассетный  Краснодар-48 , то меня всегда
мучал  вопрос:  как  в  такую  маленькую
память  Спектрума  влазит такое огромное
количество   игровых   экранов.   Взять,
например,  игру SABOTEUR 2 - она вмещает
в   себя   более   пятисот  экранов!  Из
простого подсчета можно понять, что если
хранить  в памяти экраны в таком виде, в
каком  они  представляются играющему, то
их  будет  очень ограниченное количество
(даже  если размер игрового окна невелик
и экраны компрессированы). На самом деле
все   делается  немного  хитрее.  Каждый
игровой   экран   состоит  из  небольших
фрагментов    изображения   (элементов),
точно   также,   как  стена  состоит  из
кирпичиков.  Все эти элементы хранятся в
памяти.    Их   может   быть   различное
количество  и  каждому элементу присвоен
свой   номер.   Элементы   могут   иметь
фиксированный         размер        или,
соответственно,  нефиксированный  и, как
правило,  размер  элемента всегда кратен
восьми    точкам.    Так    их   удобнее
использовать.  Форма  элемента не всегда
бывает   квадратная  или  прямоугольная,
иногда  бывают  элементы  более  сложной
формы. Таким образом в памяти компьютера
хранятся    игровые    экраны   в   виде
последовательности   номеров  элементов.
Нетрудно  посчитать сколько памяти будет
занимать  экран  размером,  например, 32
знакоместа   по   горизонтали  и  24  по
вертикали  (весь  экран  Спектрума)  при
размере  элемента два на два знакоместа:
(32*24)/(2*2)=192   байта.  Если  размер
элемента увеличить в два раза (четыре на
четыре),  то  объем  памяти,  занимаемый
одним экраном сократится в четыре раза и
станет равным 48 байтам. Если, к томуже,
скомпрессировать  эту последовательность
номеров  элементов,  то  результат будет
еще  лучше. У некоторых может возникнуть
резонный   вопрос:  а  как  же  хранится
информация  об  игровом  пространстве  в
играх    со   скроллируемым   ландшафтом
(А.М.С.,  Буратино). В программах такого
типа   вся   карта   игры  разделена  на
отдельные   одинаковые   экраны.  Каждый
экран строится вышеописанным способом, а
во   время  игры  происходит  незаметный
переход от одного экрана к другому. Хотя
в  некоторых  играх  (Tomcat, Fly shark)
карта  непрерывна.  Она как-бы выполнена
одним  экраном,  только этот экран имеет
небольшое    количество   элементов   по
горизонтали    и   огромное   количество
элементов по вертикали.
 Почему  же одни авторы игр используют в
своих  программах элементы фиксированных
размеров,  скажем два на два, а другие -
нефиксированных?  На  этот вопрос трудно
дать  однозначный  ответ,  однако  можно
сделать  кое-какие предположения. Дело в
том, что каждому элементу стараются дать
однобайтный номер (двухбайтный "съедает"
вдвое  больше  памяти),  в  таком случае
максимальное  количество  -  256. Если в
игре  не  очень  много графики, то можно
обойтись  и  этим  количеством элементов
при   сравнительно   небольших  размерах
последнего,  а  в  программах типа DIZZY
такого  количества  элементов может и не
хватить.  Рассмотрим  пример.  Имеются в
игре  рисунки двух камней: один размером
одно на одно знакоместо, а второй восемь
на  восемь  знакомест.  Как  пришлось бы
делать    при    фиксированном   размере
элементов:   принимаем  размер  элемента
один  на  один.  Тогда  маленький камень
будет  состоять  из  одного  элемента, а
большой  из  64!  Можно  конечно принять
размер  элемента  и  восемь  на  восемь,
тогда  элемент  для  первого камня будет
нерационально   использован.   В   таких
случаях     и     нужно     использовать
нефиксированные      элементы,     тогда
маленький  камень,  как и большой, будет
состоять   всего   из  одного  элемента,
только   разных   размеров.   Что  можно
сказать в защиту элементов фиксированных
размеров? Такие элементы проще рисовать,
хранить  и  из  них проще конструировать
экраны.   Что   касается   раскрашивания
элементов,  то тут поступают по разному.
Иногда     располагают     подряд    ч/б
изображения   всех  элементов,  а  потом
цветовую  составляющую, иногда после ч/б
части  одного элемента идет информация о
его цвете, а порой после восьми байт ч/б
стоит  один  байт  атрибутов.  В играх с
монохромной (двухцветной) графикой такой
проблемы  вообще не возникает. Программа
устанавливает   в  начале  своей  работы
цвет,  а потом вносит изменения только в
ч/б  часть изображения. Следует обратить
внимание  на  еще один интересный способ
экономии   памяти   при  конструировании
экранов.   Иногда   несколько  элементов
объединяют  в  группу и присваивают этой
группе    элементов    какой-то   номер.
Подпрограмма, которая генерирует игровой
экран   предварительно   "разворачивает"
группу    на    отдельные   элементы   и
производит    рисование   экрана   Таким
образом  игровой  экран  может  состоять
всего  из  нескольких байт, но каждый из
них   будет   указывать   на   множество
отдельных  элементов. Ну с формированием
экрана   вроде  бы  разобрались,  пойдем
дальше.  Теперь  я  попробую  разъяснить
необходимость  (или ненужность) теневого
(виртуального)  экрана.  Одним из важных
требований    к    любой    компьютерной
программе     (будь    то    музыкальная
демонстрация   или  игра)  является  то,
чтобы освежение (перерисовывание) экрана
происходило   как   можно   быстрее,  ну
максимум  за  1/50  секунды,  чтобы  луч
кинескопа не пересекал картинку во время
ее  вывода  на экран. В противном случае
будет    наблюдаться    так   называемая
"подрезка",   что   выглядит  на  экране
совсем  не лучшим образом. Так вот, если
программа    успевает   произвести   все
манипуляции   с   графикой  (перемещение
персонажей,  анимация  ландшафта и т.д.)
за 1/50 секунды, то теневой экран совсем
не   нужен.   Ярким  представителем  игр
такого  типа  является  сериал  DIZZY. В
этих  играх  в  основном движется только
главный  персонаж, что отнимает не очень
много   времени,   и   притом  отказ  от
теневого   экрана   дает  дополнительные
килобайты  памяти под графику. Но если в
игре  огромное количество персонажей, то
без   теневого  экрана  обойтись  просто
невозможно.   Программа   приготавливает
кадр  видеоизображения в теневом экране,
а    когда   все   готово,   то   быстро
перебрасывает   все   это  хозяйство  на
экран.  Чем  меньше  промежуток  времени
между  перебросами  данных из теневого в
основной     экран,    тем    динамичнее
программа.  Необходимо  уделить  немного
внимания  способам  переброски  теневого
экрана  на  основной. В разное время это
делали     по    разному    -    техника
программирования   на   СПЕКТРУМе  очень
быстро   совершенствовалась.   В  первых
программах  этот вопрос решали с помощью
обычных  циклов или команды LDIR, но шло
время и был найден новый, более быстрый,
способ  - это серия операторов LDI. Этот
способ  переброски является доминирующим
на сегодняшний день . Также иногда можно
наблюдать  использование  стека для этой
цели  .  Ну  и самым эффективным методом
переноса  данных  является  переключение
страниц видеопамяти (в режиме 128К). Тут
даже  нет  как такового переноса, просто
изображение  строится  на экране, только
не   на  отображаемом  в  данный  момент
времени  (LEMMINGS PSG edition) Скорость
переключения   страниц   равна  скорости
переключения   триггера,   а  это  почти
мгновенно.   Сейчас   я  приведу  далеко
неполный  список игр, которые используют
теневой  экран  и  освежение  основно го
экрана   с  помощью  кучи  LDI:  CAPTAIN
DYNAMO, S.W.I.V., JOE BLADE (все), OMEGA
ONE,   TOMCAT,   ELVEN  WARRIOR,  PRINCE
CLUMSY, LICENCE TO KILL и т.д.
 Еще  хочу  поделиться  одним интересным
наблюдением.  В  играх JOE BLADE, R.A.M.
игровой    экран    имеет   внушительные
размеры,  однако  действие происходит на
нижней  половине.  Так вот теневой экран
содержит     только     нижнюю     часть
отображаемого  экрана,  а  верхняя часть
является  статической.  Хотя в ходе игры
не    каждый    заметит,    что    экран
используется не полностью.
 А теперь немного затронем вопрос вывода
спрайтов.    Перед   тем,   как   спрайт
накладывается  на  сформированный  экран
(спрайт  обычно накладывается по маске),
то  область  под  спрайтом  копируется в
буфер,   чтобы   для   следующего  кадра
картинка  была  восстановлена  и спрайты
были наложены по новым координатам. Если
спрайтов  много,  или  они имеют большой
размер,  то  нет  смысла хранить область
экрана  под  ними,  а  более рационально
перерисовать    экран    заново.   Также
целесообразно  полностью  перерисовывать
теневой  экран  в  случае,  если  на нем
много    анимации    ландшафта.   Иногда
используют   иной   способ  накладывания
спрайтов.      В      теневом     экране
конструируется    изображение    и   без
наложения    спрайтов   переносится   на
основной  и  только  потом нашлепываются
спрайты.  Конечно  некоторое время экран
остается   без  спрайтов,  что  вызывает
небольшое  их  мерцание, но тем не менее
этим     приемом    часто    пользуются.
Положительной   стороной   этого  метода
является   то,   что  нет  необходимости
хранить  подспрайтовую  область теневого
экрана.
 На   этом  мы  закончим  наш  маленький
экскурс в тонкости компьютерной графики.
          Продолжение следует.
    ______________________________