Author: grf

Наконец-то я победил эти «хвосты» при скроллинге! Можно делать игру дальше!

При больших сдвигах рулона среднего экранного слоя (где бродят Зомби) промелькивали объекты, которые должны были уже быть стерты. И борьба с ними заняла у меня три дня…

Пока я использовал блиттер в атоматическом режиме (он при этом сам стартует при каждом прерывании по вектору 100) — все было почти хорошо. Точнее, в эмуляторе было вооще все хорошо, а вот на реальном железе при глобальном скроллинге экрана иногда наблюдалось какое-то дергание экрана.  Этим, конечно же, было поручено заняться Тэду из будущего. При этом возникал вопросы о скоростном построении экрана из множества тайлов — ведь количество команд, которые можно скормить блиттеру за раз, ограничено.  А это значит, что лабиринт будет заполняться порциями, каждыя из которых будет выводиться при очередном прерывании по вектору 100 («кадровое»). С появлением в AZBK режима ручного запуска блиттера, эта проблема ушла — выдаем блиттеру пакет за пакетом и запускаем все это сами, не ожидая милостей от вектора 100. Заодно появилась возможность сбрасывать блиттеру фоновые задачи, типа «удали старые спрайты со скрытого экрана, а мы в это время посчитаем куда какому монстру сделать шаг». И вывод на экран стало возможно делать тогда, когда хочется, а не ожидая очередного «кадрового» прерывания. Вот тут и был подвох.

Как только я добавил Зомби, шагающих туда-сюда, потребовалось их еще и скроллить вместе с фоном, когда Дейв инициирует движение окна. При этом, когда скроллинг (вертикальный или горизонтальный) докручивался до максимума и надо было уже переключать окно, вдруг могли промелькнуть какие-то дополнительные фигуры Зомби, там, где их никак быть не могло. Я предположил, что это спрайты, которые не успели стереться, а это место экранной страницы было вытащено скроллингом на видимую область экрана.  Стало ясно, что эти вещи надо тоже теперь синхронизировать вручную — сдвиг рулонов и переключение видимой области экрана. Но когда пакет команд блиттеру ушел, то о том, что блиттер его обработал, можно судить только по биту 15 в регистре 177270. Т.е. надо ждать, когда этот бит сбросится в 0 и потом можно переключать  рулоны.

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

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

Вот тогда призраки и были изгнаны и «дрожь земли» пропала!

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

В цикле вывода на экран стоял wait и сам вывод начинался после возникновения прерывания по вектору 100 («кадровое прерывание» на БК). Это необходимо, чтобы спрайты не мигали на экране, ведь их приходится стирать и выводить снова, и момент, когда спрайта нет на экране не должен быть виден игроку. Но это самое ожидание обратного хода луча может все и тормозить, если программе есть чем заняться 🙂 Альтернативой является использование двух экранных страниц — одну страницу скрываем, стираем на ней спрайты (все равно она не отображается сейчас), выводим заново на новых местах, а в это время демонстрируем вторую. Таким образом момент, когда спрайты стерты, не виден.

На БК0011М экранных страниц две. А сколько их на AZBK? Да сколько хочешь, ведь вся память AZBK может быть отображена с любой страницы. И включать эти страницы можно в любые слои экрана. Вот я и завел себе две экранных страницы для верхнего экранного слоя и вывожу туда бегущего Дейва, попеременно включая то одну, то вторую. В итоге ожидания обратного хода луча нет и мигания спрайтов тоже нет.

Завтра заведу две экранных страницы и для среднего слоя, где Зомби гуляют.

Сегодня плодотворно поработал:

• исправил спрайты со смещенным контуром (один был при стрельбе влево вверх, второй — при заряжании)
• добавил анимацию перезарядки и расход патронов (собственно, добавил еще вчера, но из-за кривых спрайтов выглядело это не очень)
• оптимизировал обнаружение препятствий летящей пулей — процедура ускорилась  в 17 раз 🙂
• добавил команду «повтор спрайта» для движка движений — таблицы движений сократились даже не знаю во сколько раз
• добавил задание индивидуального шага в анимацию объектов обстановки, теперь они работают как положено, с разными скоростями — дым летит быстро, алмазы мигают медленно, очки плывут вверх средне
• допилил стрельбу — после выстрела не происходит возврат в базу, пока не отпустят кнопку выстрела
• добавил проверку попыток стрелять при пустом магазине и соответствующие движения

Завтра приступаю к запуску Зомби!

Как-то мне попалось мини-интервью Джона Ромеро, его там спросили под каким углом стреляет Дейв. Ответ был — 45 градусов. Я тогда удивился, почему вообще возник такой вопрос у народа. Поизучал траектории полета пули в оригинале и тоже удивился: что-то там не похоже на 45 градусов никак:

Пришлось немного повысчитывать, но все получилось, теперь Дейв стреляет:

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

P.S. Совсем забыл — надо же перезарядку дробовика еще сделать 🙂

Добавил анимацию стрельбы и дыма при выстрелах. 6 видов дымов! Один из спрайтов стрельбы оказался с кривым контуром — слишком толстым. Выглядит он как будто с тенью на стене. Поищем, починим. Теперь надо делать обработку попаданий и расход патронов. Гонять стало сразу куда прикольней!

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

Итак, шкафы Дейв научился открывать и пришло время брать из этих шкафов всякие бонусы. А значит, нужно было  заняться анимацией вещей типа цифр с количеством очков, которые вылетают при взятии предметов. Сначала я выяснил, что в оригинале Дейв выводится поверх этих самых «очков». Стало быть, надо накладывать эти спрайты на фон, а уже на них накладывать Дейва. Напомню, что в AZBK есть три экранных слоя, каждый из них обладает независимым скроллингом. Самый нижний слой у меня использован под фон, а также на нем выводится анимация статичных предметов — тех самых алмазов. Анимация выводится на фон, фон двигается, все отлично. Спрайты очков, как выяснилось, тоже привязаны к фону — если Дейв берет предмет и убегает, то цифра с очками уезжает в сторону вместе с фоном. Значит эту анимацию логично вывести на нижний (фоновый) слой и забыть о ней — она сама уедет куда надо, когда фон сдвинется. Но вот только при этом надо сохранять фон, который запортится при выводе спрайтов. Или же выводить заново тайлы обстановки, по которым проедутся спрайты цифр. Последовательность «запомнить фон — вывести спрайт — восстановить фон» тоже не так проста, как кажется. Ведь на этапе «запомнить фон» можно запомнить фон вместе с куском уже выведенного рядом спрайта такой же анимации — ведь очки вылетают и из убитых врагов, которые могут ходить толпами. Поэтому сначала надо восстановить фоны под ВСЕМИ спрайтами анимации, потом запомнить «чистый» фон для каждого спрайта, а потом уже выводить новые спрайты. Ну и при этом всем фон у меня имеет хитрую структуру с разными пересекающимися областями, там черт ногу сломит.

Но у нас же есть слои! Долой рутину с оперных подмостков!

Итак, к черту запоминание фонов и все вот это. Будем выводить спрайты анимации на СРЕДНИЙ слой экрана. Это позволит нам не запоминать никаких фонов, а просто стирать выведенные спрайты прямоугольниками с заливкой прозрачным цветом. И выводить спрайты тоже можно прямоугольниками — никаких тебе BIC по маске и BIS. Правда, на этом слое у нас обитает Дейв — ну и выселим его на верхний слой, там ничего кроме обоймы с патронами нет. Интересно, может ли Дейв допрыгнуть до обоймы? Да, может, как выяснилось. Есть такие места. Ну и ладно, пусть об этом думаешь Тэд из будущего.

Вывести анимацию на средний слой — это шикарное избавление от кучи проблем. Но ведь они должны быть привязаны к фону и двигаться вместе с ним. И тут пригождается независимый скроллинг слоев. Не эти ваши всякие паралаксы же реализовывать ими! Делаем средний слой всего одним квадратом 512х512. Видимая часть у нас 256х192. Синхронизируем это с нижним слоем так, чтобы средний слой всегда имел запас по краям со всех сторон видимой области — это позволит выводить анимацию в еще невидимые области на границах отображаемой части, чтобы объекты могли входить в кадр справа-слева-сверху-снизу и при этом не надо было заботиться об обрезке спрайтов границами экрана. Нижний слой, состоящий из кучи страниц, переключает скроллится в одну сторону, над ним второй слой перематывает сам себя и все время начинается на координаты -200 по X и -140 по Y относительно рабочего окна. Над всем этим стационарно висит слой с Дейвом без всякого скролла. Трехмерная модель высылается по запросу (шутка).

Процесс синхронизации занял у меня довольно много времени, так как я наткнулся на непонятную проблему — при спуске вниз анимация внизу экрана успешно работала, но если Дейв поднимался чуть выше и слой двигался, то в нижней трети экрана спрайты анимации вообще исчезали. Сначала я подумал, что не туда позиционируется вертикальный скроллинг. Потом — что я неправильно задал длину вертикального рулона и поэтому часть строк просто не выводится при прокрутке. Затем начались подозрения на глюк в прошивке AZBK… Наконец, мне пришла в голову гениальная мысль — к черту эти рулоны, надо лечь спать, а то уже два часа ночи.

Как известно, утро вечера всякоразней. С новыми силами и новыми матами я разбирался в этих заморочках с рулонами и координатами и вдруг выяснил, что при выводе спрайта на строки ниже 400 (8) у меня возникает переполнение при вычислении адреса в памяти AZ — там же 24-битные адреса и я на это регулярно натыкался первое время. Ну и вот опять. Спрайты анимации просто переставали выводиться туда, куда надо при определенном соотношении смещения слоя и его виртуального начала относительно фона.

Пофиксил вычисление адреса и все успешно заработало. Записал ролик, выложил его на ютуб и заметил, что теперь не все алмазы мигают как надо 🙂 Но это ерунда, починим!

Сделал вывод анимированных объектов со второго слоя лабиринта — алмазов и прочих бонусов:

Заодно теперь можно открывать шкафы:

А также, провел пару тестов по всенаправленному скроллу для ОБЫЧНОЙ БК0011М, без AZBK. Прикидываю, возможно ли сделать Дейва и для обычной БКшки, ведь все алгоритмы у меня будут. Тесты получились такими (в первом спрайты черезстрочные, во втором полноценные):

Кажется, Дейв вполне возможен и для обычной БК 🙂