КАК ЭТО ДЕЛАЕТСЯ!

RANARAMA

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

Автор игры - знаменитый программист из фирмы "HEWSON CONSULTANTS" - Стив Тернер. Наши читатели знакомы с его работами, например по программе "Quazatron", освещенной в "ZX-PEBЮ-92" на стр.79, а также по серии публикаций "Профессиональный подход" в '7Х-РЕВЮ-9Г.

Мы знаем, что игры лабиринтного типа явились одними из первых игр на "Спектруме" и их период расцвета относится к 1982 -1983 годам. В какой-то мере можно удивляться, что в 1987 году на рынок поступило одновременно несколько продуктов, выполненных в единой манере лабиринтной игры - "Dandy" (ELECTRIC DREAMS), "Gauntlet" (US GOLD), "Ranarama" (HEWSON CONSULTANTS) и некоторые другие. Сразу несколько фирм вернулись к старой лабиринтной идее на новом уровне. Что это - случайность или закономерность?

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

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

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

Как только он находит колдуна и входит с ним в контакт, игра переходит в режим аркадной вставки. В этом режиме надо решить головоломку типа анаграммы в ограниченное время. Злой колдун перепутал буквы в названии игры "R.A.N.A.R.А.M.А" и, оперативно манипулируя джойстиком или клавишами, Вы должны расставить их по своим местам (этот элемент напоминает схватку двух роботов за обладание системой управления в предыдущей программе С. Тернера "Quazatron"). Работа требует сообразительности, глазомера и четкой координации движений. На каждом уровне время, отведенное для решения головоломки, постепенно уменьшается. Кажется, что ввод аркадных вставок в аркадно-адвентюрную игру стал как бы визитной карточкой фирмы "HEWSON CONS." (см. например игру "Firelord").

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

В пол лабиринта местами встроены иероглифы (сокращенно "глифы"), которые обладают разнообразными функциями. Так, например, "голова" обозначает "глиф колдовства" (Glyph of Sorcery"). Задействовав этот глиф, Вы можете проскроллировать и исполнить те магические заклинания, к которым получили доступ в результате сбора магических рун.

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

Поскольку в игре Вам дано только две "жизни", а этого явно маловато, то очень полезно приобрести заклинания, способные перебросить Вас на более высокий уровень.

Каждый из восьми уровней имеет от 50 до 100 комнат. В начале игры вас помещают в случайно выбранной комнате. Проходя через дверь, Вы как бы "включаете свет" в очередной комнате и она становится видимой. Очень полезно воспользоваться глифом "зрения", который позволит вам увидеть все комнаты своего этажа. Правда, вам покажут только те комнаты, в которых вы уже были, но зато есть возможность увидеть невидимые двери, которые при простом обходе комнат вы не обнаружили. Впрочем, их можно оригинально обнаружить и при обычном проходе по лабиринту. Движущиеся существа могут на мгновенье "просунуть" голову сквозь стену в тех местах, где есть такая дверь.

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

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

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

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

В прошлых статьях из серии "Профессиональный подход" я немного рассказал о том, что делается на той кухне, где программисты готовят новые программы для Вашего "Спектрума". В основном это были теоретические статьи, а вот сейчас на примере программы "RANARAMA" мы посмотрим, как это происходит на практике.

Техническое задание.

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

Концепция игры пришла от программы "Paradroid", написанной для "Коммодора-64". В принципе, эта концепция была использована и при подготовке программы "Quazatron", но способ экранного представления был там совершенно иным. Во-первых, сам сценарий там был научно-фантастическим, а мне казалось, что игра на тему магии и волшебства очень хорошо впишется в структуру программы типа "Квазатрона". К моменту, когда я в принципе обдумал сценарий, стоящий за игрой, у меня уже довольно четко вырисовались требования к программе.

1. Достижение трехмерного образа на экране за счет применения теневых эффектов. К тому времени, когда я задумал эту игру, такая графика уже была испытана на "Коммодоре", но на "Спектруме" в полной мере этот прием еще не был освоен.

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

3. Двумерное представление игрового поля на экране (вид сверху). Отказ от принципа "один экран - одна комната". Одновременно на экране могут изображаться несколько комнат. В то время это было новым словом.

4. Структура игры - аналогична программе "Quazatron", но в основе сценария должна лежать магия и волшебство. Соответственно, меняется тема и содержание аркадной вставки.

5. Принцип разделения "монстров" на две категории.

Первостепенные - колдуны. Найти и победить их - необходимый элемент для успешного исполнения программы.

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

6. Техника постепенного высвечивания игрового поля. Впервые эта идея появилась во время тестирования программы "Quazatron", но туда она не пошла. Суть состоит в том, что карта игрового поля хранится "нераспакованной" для тех участков, которые еще не были исследованы, а на экране эти области затемнены. Это была пионерная идея. В то время аналогов еще не было.

7. Обработка "скрытого" изображения. Эта техника требует пояснения. Дело в том, что "монстры", находящиеся в комнатах, соседних с той, в которой находится "герой", на экране показываться не должны, но, тем не менее, должны жить собственной жизнью, перемещаться по заданным законам, в общем, вести себя так, как если бы они были видны.

Эта идея была заимствована у программы "Paradroid", но значительно переработана с целью ускорения обработки данных.

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

8. Стопроцентное использование площади экрана. К тому времени, о котором идет речь, очень широко распространилась техника выделения в качестве динамического "окна" какой-то части экрана, например одной трети или двух третей. При этом остальная площадь экрана заполняется статичной, неизменяющейся графикой или закрашивается чёрным цветом или используется для вывода текстовых сообщений.

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

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

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

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

Предварительные исследования.

1. Дизайн экрана.

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

- художественное впечатление;

- объём расходуемой памяти:

- быстродействие.

Всеми результатами я остался доволен. Особенно привлекательными мне показались добротные, прочные стены, разделяющие комнаты.

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

2. Раскладка оперативной памяти.

Закончив с первым этапом, я перешел ко второму. Поскольку у меня уже был определенный опыт, я поначалу воспользовался той картой оперативной памяти, которая сложилась после завершения программы "Quazatron", благо структура у этих двух программ была похожа. Я выделил участки памяти для хранения карты игрового поля, для хранения нужной мне графики, для всевозможных таблиц, массивов, для области рабочих процедур и программных переменных.

Как обычно, вскоре я обнаружил, что мои амбиции заходят слишком далеко и не все, что я запланировал, можно "втиснуть" в спектрумовское ОЗУ. Так, например, я хотел иметь 24 типа различных движущихся "монстров", но пришлось урезать их количество до 14.

3. Упаковка данных.

Убедившись, что оперативной памяти мне не хватает, я начал думать об упаковке данных. В первую очередь, мне предстояло хранить несколько карт игрового поля (по одной для каждого уровня) - это наиболее емкие данные.

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

В принятом мною методе на задание комнаты на карте игрового поля расходовалось всего два байта и еще по два байта уходило на описание каждой двери. Вот как это было сделано.

Единицей измерения на карте я выбрал блок из четырех знакомест (размер 16x16 пикселов).

Для комнат в первом байте я решил хранить координату левого верхнего угла комнаты, я во втором байте - размер этой комнаты. Вы знаете, что поскольку байт не может принимать значение больше 255, то мне нелегко было бы сделать достаточно большое игровое поле. Максимум - 16x16 блоков по 16x16 пикселов, то есть, чуть больше одного экрана. Это, конечно, недостаточно, поэтому координата левого верхнего угла задается не как абсолютная, а как относительная, то есть это "смещение" начала N-ой комнаты относительно N-1 -ой комнаты. Тогда все стало на свое место (пример см. на рис. 1)

Пришлось "помудрить" и со вторым байтом, задающим размер комнаты. В итоге я остановился на том, что у меня в программе будет ограниченное количество разных типоразмеров комнат и второй байт будет задавать собственно не размер комнаты, а номер ее типоразмера. Соответствующая рабочая процедура потом по этому номеру найдет в таблице данных истинный размер комнаты (пример см. на рис. 1).

Рис.1

и такдалее

ОРГАНИЗАЦИЯ ДАННЫХ ПО ДВЕРЯМ

ТИПЫ ДВЕРЕЙ

тип 4

и так далее

Рис.2

Аналогично было и с дверьми. Первый байт задает "смещение" координаты двери относительно координаты предыдущей двери. Второй байт задает тип двери. Двери могут быть четырех типов. Во-первых, они могут быть вертикальными (тип 1) или горизонтальными (тип 2), а во-вторых, они еще могут быть и невидимыми (типы 3 и 4 соответственно). Пример см. на рис. 2.

4. Специальные алгоритмы.

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

В основу была положена следующая логика работы (представим себе, что герой входит в новую комнату и ее надо "высветить" на экране):

а) По координате "героя" из упакованной карты игрового поля извлекаются координаты комнаты и дверей.

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

в) По номеру комнаты из специальной таблицы сценария извлекаются данные о наличии в ней объектов и предметов.

г) По их номерам и координатам они изображаются на экране.

д) Если в таблице программных переменных есть "монстры", находящиеся в данный момент в этой комнате, то изображаются и они.

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

"Шэдоу-процессор" позволил сэкономить еще изрядное количество памяти.

Рис. 3

5. Проверка концепции.

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

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

Дизайн программы.

Закончив с предварительными исследованиями, я перешел к проработке структурной диаграммы. В статьях "Профессиональный подход" (см. "7Х-РЕВЮ"-91) мы уделили серьезное внимание тому, как создаются структурные диаграммы, зачем они нужны и чем они отличаются от алгоритмических блок-схем. Там же мы упомянули и о том, что при всем многообразии игровых программ, структура их может оказываться удивительно похожей. Так случилось и в этот раз. Практически эта важная и ответственная работа превратилась в пустую формальность. Почти на 100 % подошла структура, ранее разработанная для программы "QUAZATRON". Конечно мне помогло то, что я начал разработку новой программы не на пустом месте, а уже имея солидный опыт программиста игровых программ. Если же Вам когда-то придется начинать это дело "с нуля", то для справки я привожу структурную диаграмму на рис. 4.

Машинный код.

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

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

Основную трудоемкость, как ни странно, составило не программирование машинного кода, а борьба с разного рода мелкими неприятностями. Примерно месяц ушел на то, чтобы выловить все "жучки" в ассемблирующей программе. Я пользовался ассемблером "ОСР", а он регулярно разрушал мои таблицы меток. Еще столько же времени ушло на борьбу с механическими помехами (дребезг контактов на разъеме, через который подключались дисковод и принтер).

Но так или иначе, рано или поздно, наступает такой момент, когда перед Вами еще гора работы, а сделано уже так иного, что отступать нельзя. Вот на этой стадии мне и пришлось столкнуться с концептуальной проблемой, связанной с моим героем. Как оказалось, у меня на него осталось так мало места в оперативной памяти, что сделать приличного чародея я уже не мог. Как я ни экспериментировал, он меня не устраивал. Спас положение Эндрю Брейбрук, который предложил сделать героя лягушкой и тогда спрайт 16x16 получается намного лучше. В поисках приемлемой картинки для своей лягушки я перелистал несколько томов по биологии, неплохо ознакомился с жизнью земноводных и, самое главное, узнал, что лягушка по латыни звучит, как RANA. Так и родилось название игры RANARAMA.

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

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

Однажды рано утром я сидел и экспериментировал с клочками бумаги на столе, пытаясь придумать оригинальное изображение титульного экрана с названием игры, выполненным крупными буквами. В этот момент меня осенило. Я понял, что аркадной вставкой может стать перестановка букв в слове RANARAMA. Как оказалось, название программы очень соответствует этой задаче. Поскольку в слове есть 4 буквы "А", то аркадная вставка получилась скорее динамичной, чем головоломной. Первые же эксперименты убедили меня в том, что это решение удачно. Труды предыдущего месяца были сняты с полки и полетели в мусорную корзину, а через пару дней проблема перестала существовать.

Колдуны

Ракеты противника Ракеты героя Руны Сцена

Мультипликация Аркадная вставка Исполнение специальных операций, например показ карты этажа

Расчет координат "монстров", не изображаемых в этот момент на экране

Изменение энергии главного героя

Рис.4 Структурная диаграмма программы RANARAMA

Звук и музыка.

Музыку в программу я добавляю в самый последний момент. Это происходит потому, что музыкальные и звуковые процедуры работают в режиме прерываний 2-го рода - IM2.

Примечание ИНФОРКОМа: В последнем издании книги, посвященной машинным кодам, мы широко рассмотрели применение прерываний 2-го рода. Это издание объединяет выпущенные ранее в 1990 году три тома и примерно на 20% дополнено. Общий объем - 271 стр. Заказы принимаются на приобретение отдельных экземпляров и на лицензированный тираж в регионе принимаются.

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

"Спектрум" имеет очень ограниченные звуковые возможности. У него есть всего лишь один звуковой канал, который может находиться в двух состояних - "вкл"/"выкл". Пульсирующий сигнал определенной частоты вызывает появление звукового тона соответствующей частоты (см. рис. 5).

Время

Рис. 5

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

Тот принцип, который мы здесь рассмотрим, может быть использован и владельцами 128-килобайтных машин при программировании встроенного звукового процессора. Я применял этот прием и для "Коммодора 64" при озвучивании программы "URIDIUM". Аналогичную технику используют и синтезаторы серии "Ямаха DX".

Предлагаемая Вашему вниманию программа выполняет линейную модуляцию частоты. Таким образом, частота изменяется вверх или вниз в соответствии с данными, взятыми из специальной таблицы. На рис. 6 и 7 показаны графики частот.

Рис. 6

Рис.7

Одноступенчатая модуляция.

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

Пилообразная модуляция

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

Рис. 8

Треугольная модуляция

(рис. 9) обеспечивается тоже с помощью счетчика тактов, но в этом случае при обнулении счетчика происходит не восстановление исходного значения частоты, а изменение знака ее приращения.

Рис. 9

Двуступенчатая модуляция

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

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

Рис. 10

Программа.

Вашему вниманию я предлагаю программу для испытания звуков. Назовем ее SOUNDTESTER. Она состоит из двух блоков. Первый блок - БЕЙСИК-загрузчик (Листинг 1). Он загружает второй блок и выполняет настройку параметров, которые Вы пожелаете изменить. Здесь Вы задаете закон, по которому будет происходить модуляция частоты, здесь же задаются настроечные параметры. Второй блок - в машинных кодах (Листинг 2). Он, собственно, и выполняет все необходимые расчеты и выдает сигнал на порт звукового динамика.

ЛИСТИНГ 1

10 CLEAR 40000

15 LET sontab = 45235: LET sonreq = 45234 20 LOAD "sound" CODE 45000 30 DIM a(10)

40 FOR x=1 TO 9: LET A(x)=0: NEXT x 1000 CLS: PRINT " SOUNDTEST"

1010 PRINT ' "1. SOUND NUMBER", a(1) 1020 PRINT "2. START FREQ. ", a(2) 1030 PRINT "3. FREQ. CHANGE". a(3) 1040 PRINT "4. CHANGE TIMES". a(4) 1050 PRINT "5. REPEAT TIMES". a(5) 1060 PRINT "6. MODULATE TYPE",a(6) 1070 PRINT " 0 = SAWTOOTH"' " 1 = 2nd MOD DOWN"' " 2 = 2nd MOD UP"' " OTHERS = TRIANGLE" 1080 PRINT "7. RESET FREQ", a(7) 1090 PRINT "8. CHAHGE T RESET",a(8) 1100 PRINT "9. CHAIN TO NO",a(9) 1110 PRINT "10. DELAY", a(10)

2000 INPUT "ENTER 0 TO FIRE SOUND OR NUMBER TO CHANGE VALUES"; i

2010 IF i = 0 THEN GO TO 3000

2020 IF i>10 OR i<1 THEN GO TO 2000

2030 LET x=INT (i)

2040 INPUT "NEW VALUE 0. . . 255 "; i 2050 IF i<0 OR i>255 THEN GO TO 2040 2060 LET a(x) = INT (i) 2063 IF x=1 THEN GO TO 2500 2065 REM Запись звуков в таблицу. 2070 LET z=sontab + (a(1)*8)+x-2 2080 POKE z,a(x) 2090 GO TO 1000

2500 REM вызов звука на редактирование 2510 LET z=sontab + (a(1)*8)

252O FOR x=2 TO 9: LET a(x)=PEEK z: LET z=z+1: NEXT x 2530 GO TO 1000

3000 REM Вызов звука на прослушивание 3005 LET x=a(10)

3010 PRINT AT 20, 1; "PRESS 0 ТО REPEAT SOUND OR 1 TO CHANGE. " 3020 POKE SONREQ, a(1)+1 3025 PAUSE 20

3030 RANDOMIZE USR 45000: FOR y=0 TO x: NEXT y: IF INKEY$="" THEN GO TO 3030 3060 IF INKEY$ ="0" THEN GO TO 3020 3070 GO TO 1000

9000 FOR x= 45227 TO 45400: PRINT PEEK x: NEXT x

КОММЕНТАРИИ

Строка Содержание

1010 Номер звука а(1)

1020 Начальная частота а (2)

1030 Скорость изменения частоты a(3)

1040 Количество модуляций в звуке а (4)

1050 Количество повторений звука а(5)

1060 Вид модуляции а(6):

0 - пилообразная,

1 - двухступенчатая нисходящая,

2 - двухступенчатая восходящая, пр. - треугольная,

1070 Частота сброса a(7)

1080 Темп изменения частоты сброса а(8)

1090 К какому звуку "привязать" данный звук? а(9)

1100 Пауза а(10)

2000 Введите 0 для прослушивания звука или число от 1 до 10 для внесения

изменений.

3010 Нажмите 0 для повтора или 1 для редактирования.

Листинг 2

ORG 0AFC8H

1. От редакции - время подвести некоторые итоги, обсудить возникшие проблемы и наметить планы на будущее.
2. Beta Basic - команды: DPEEK, EOF, FILLED, HEX$, INARRAY, INSTRING, ITEM, LENGTH, MEM, MEMORY, MOD, NUMBER, OR, RNDM, SCRN$, SHIFT$, SINE, STRING$,TIME$, USING$, XOR. А так-же ключевые слова и сообщения об ошибках.
3. Защита программ - заканчиваем печать третьего тома книги В.С. Михайленко, посвященной вопросам защиты программ для "Синклер"-совместимых компьютеров.
4. Ошибки ПЗУ - продолжаем разговор о вскрытых ошибках и неточностях стандартного ПЗУ "Спектрума". Начало статьи см. в предыдущем выпуске на стр. 209 - 210.
5. Профессиональный подход - продолжение разговора о некоторых приемах, позволяющих придать "профессионализм" вашим программам.
6. Профессиональный подход - ввод параметров при помощи оператора INPUT.
7. Как это делается! - приемы построения игр на примере игры RANARAMA.
8. Советы экспертов - описание игры ATF.
9. Советы экспертов - описание игры FLYER FOX.
10. Советы экспертов - описание игры COBRA FORCE.
11. Советы экспертов - описание игры THUNDER BLADE.
12. Советы экспертов - описание игры SANXION.
13. Советы экспертов - описание игры AIR WOLF.
14. Советы экспертов - описание игры 1943 THE BATTLE OF MIDWAY.
15. THE DARK WHEEL - продолжение повести. Глава 3-4.