После долгого перерыва на отпуск, послеотпускной завал работы, простуду, я наконец-то вышел на рабочий режим, въехал в собственный код и проект «Dangerous Dave для БК0011М+AZBK» начал двигаться.
Первым делом я столкнулся с тем, что Maxiol и Gid внесли изменения в железо AZBK и его реализацию в эмуляторе GID. Изменения, собственно, я сам и запрашивал, сталкиваясь с проблемами видеовывода то в железе, то в эмуле. Эти изменения притащили с собой новый формат команд и новые команды блиттера. Пришлось долгое время переписывать все процедуры Дейва, связанные с выводом на экран, под нововведения в параметрах команд блиттера. Было много глюков — спрайты рисовали не там, где надо, весь экран начинал покрываться рябью и все таком стиле. Постепенно это все ушло в небытие и Дейв начал снова бегать по лабиринту (первый уровень мне уже порядком надоел).
Но он не просто начал снова бегать, он начал снова глючить — момент перехода рулона через ноль и переключения в этот момент страниц видеопамяти вызывает дергание экрана. Все потому что движок Дейва не всегда успевает подготовить новый кадр за 1/60 секунды, чтобы вывести новые данные в момент обратного хода луча. А если не ждать этого момента — манипуляции с экраном становятся видны. На данный момент я еще не придумал, как это побороть.
Так что я решил пока двигаться дальше — какой смысл впихивать текущую подготовку кадра в 1/60 сек, если еще не все механизмы готовы? Еще нет разлетающихся кровавых ошметков от монстров, не все монстры задействованы и т.д.
Первым делом я занялся попаданиями пули по монстрам. Тут было два варианта решения:
1. При трассировке траектории пули на каждом шагу сверяться с массивом координат монстров и определять совпадение монстра и пули.
2. Завести слой лабиринта, по «знакоместам» которого двигать коды монстров (точнее, сразу указатели на записи о монстрах) при их передвижении по лабиринту. Тогда для проверки совпадения не нужно пробегать всех врагов, можно просто сразу получить указатель на того, что попался в этом «знакоместе» лабиринта.
Первый вариант не накладывает новых расходов на движок, зато грозит долгой обработкой кучи данных при стрельбе. Второй вариант делает стрельбу скоростной, но нужно двигать лишние данные на каждом движении монстров. Я выбрал второй путь. Это потребовало памяти, но, т.к. я использую AZBK, то памяти у меня вагон. Да и к тому же, как оказалось, страницы 5 и 6 (экраны БК0011М) теперь тоже можно использовать как обычные страницы памяти, ведь они больше не используются для вывода на экран.
Метод был успешно реализован, теперь надо было сделать визуализацию попадания пули в монстра. В Дейве это реализовано выводом текущего спрайта монстра полностью залитым белым цветом. Я собирался генерировать такой спрайт программно, но Maxiol сказал, что это можно легко заставить делать блиттер. В итоге в новой версии блиттера (и в эмуле GIDа) к моему приезду как раз появилась такая команда. Я воспользовался ей и все сразу заработало, что удивительно. Спрайты «блымкают» белым как надо, это сразу добавило энтузиазма, как и любое продвижение вперед.
В прилагаемом ролике видны дергания экрана, это как раз те глюки при переключении страниц, которые меня вгоняют в тоску. Также там видно, что Зомби пока что слезают со ступенек раньше, чем дойдут до пола, но это все ерунда. Хуже то, что при большом количестве Зомби на экране Дейв начинает притормаживать, но я утешаю себя тем, что в реальной игре Дейв просто не может пройти через такое количество врагов, они его сожрут раньше. Но в целом, конечно, надо искать узкие места и оптимизировать.
Сегодня ножи, которыми кидаются Бабки, полноценно полетели по лабиринту — они находят стены и разбиваются о них:
Не обошлось без неожиданных глюков:
Теперь можно начать обрабатывать попадания в монстров. Тут две задачи:
Спрайт монстра, при попадании пули, нужно превратить в целиком белый спрайт. Средствами блиттера этого не сделать, там нет таких фич. Палитрой этого тоже не сделать. Придется попробовать генерить новый, белый спрайт из текущего спрайта монстра.
Разлетание ошметков мяса — та еще задачка. Надо поизучать, как эти куски разлетаются на самом деле. Влияют ли на это стены, чтобу будет, если кусок мяса падает в яму и т.д.
Итак, Бабки научились кидаться ножами. Применил такую же стереофонию, как в «Prince of Persia»: звук броска слева — воспроизводится в левом канале, звук броска справа — в правом. Однако, возник интересный глюк — при левом броске звук воспроизводится с искажениями, хотя массив играется один и тот же. Похоже, что-то я сломал в звуковом стерео-движке, пока переделывал его под Goonies:
Все время думал, что в Дейве ножами кидаются Бабки. Как оказалось, так думал не один я, но и многие другие игроки. В своем время Джона Ромера даже специально спрашивали об этом персонаже и оказалось, что это мужик-горбун, да еще и Игорь:
«Old lady»
The knife-throwing creature which is first encountered on upper floors of the first level was affectionately called «old lady» by many fans, though it is actually a male hunchback, similar to classical Igor from Frankenstein movies.
Итак, сегодня Бабуляторы появились и в моем ремейке Дейва:
Спрайты все еще мигают, так как фикса эмулятора пока еще нет. Честно говоря, они мигают куда мощнее, это я уже изголяюсь, чтобы ролик записать более-менее прилично 🙂 Когда-нибудь проблема будет пофикшена и сразу все перестанет мигать. А пока — пишу дальше так.
После длительных разборок с видеовыводом на железный и эмулируемый блиттер, я решил пока забить на глюки и просто делать игру дальше. Первым делом обучил Зомби распознавать лестницы и добавил нужную анимацию шагов вниз по ступенькам:
Наконец-то я победил эти «хвосты» при скроллинге! Можно делать игру дальше!
При больших сдвигах рулона среднего экранного слоя (где бродят Зомби) промелькивали объекты, которые должны были уже быть стерты. И борьба с ними заняла у меня три дня…
Пока я использовал блиттер в атоматическом режиме (он при этом сам стартует при каждом прерывании по вектору 100) — все было почти хорошо. Точнее, в эмуляторе было вооще все хорошо, а вот на реальном железе при глобальном скроллинге экрана иногда наблюдалось какое-то дергание экрана. Этим, конечно же, было поручено заняться Тэду из будущего. При этом возникал вопросы о скоростном построении экрана из множества тайлов — ведь количество команд, которые можно скормить блиттеру за раз, ограничено. А это значит, что лабиринт будет заполняться порциями, каждыя из которых будет выводиться при очередном прерывании по вектору 100 («кадровое»). С появлением в AZBK режима ручного запуска блиттера, эта проблема ушла — выдаем блиттеру пакет за пакетом и запускаем все это сами, не ожидая милостей от вектора 100. Заодно появилась возможность сбрасывать блиттеру фоновые задачи, типа «удали старые спрайты со скрытого экрана, а мы в это время посчитаем куда какому монстру сделать шаг». И вывод на экран стало возможно делать тогда, когда хочется, а не ожидая очередного «кадрового» прерывания. Вот тут и был подвох.
Как только я добавил Зомби, шагающих туда-сюда, потребовалось их еще и скроллить вместе с фоном, когда Дейв инициирует движение окна. При этом, когда скроллинг (вертикальный или горизонтальный) докручивался до максимума и надо было уже переключать окно, вдруг могли промелькнуть какие-то дополнительные фигуры Зомби, там, где их никак быть не могло. Я предположил, что это спрайты, которые не успели стереться, а это место экранной страницы было вытащено скроллингом на видимую область экрана. Стало ясно, что эти вещи надо тоже теперь синхронизировать вручную — сдвиг рулонов и переключение видимой области экрана. Но когда пакет команд блиттеру ушел, то о том, что блиттер его обработал, можно судить только по биту 15 в регистре 177270. Т.е. надо ждать, когда этот бит сбросится в 0 и потом можно переключать рулоны.
А рулоны двигаются совсем в другом месте — в подпрограмме перемещения слоев в зависимости от деятельности Дейва. Блиттер работает сам по себе где-то в фоне, а вот регистры скроллинга изменяют изображение сразу. Значит, нам в этой подпрограмме нельзя изменять сами регистры, нужно просто вычислять новые значения, чтобы применить их потом, сразу кучей, после того, как блиттер закончит стирать/выводить спрайты и все будет готово к отображению нового кадра. Причем желательно это сделать как раз в момент обратного хода луча, чтобы было незаметно.
В итоге, я завел несколько переменных, содержащих копии регистров управления слоями экрана и движок теперь изменяет не сами регистры, а эти переменные. А перенос значений из этих переменных в сами регистры происходит в тот момент, когда все готово и блиттер завершил обработку команд.
Вот тогда призраки и были изгнаны и «дрожь земли» пропала!
Да, еще я напоролся на небольшие грабли: если пакет команд маленький, то блиттер так шустро его выполняет, что бит 15 (признак работы блиттера) и установиться не успевает. И это приводило к бесконечным ожиданиям «когда ты там начнешь команды обрабатывать??» и зависаниям.
В цикле вывода на экран стоял wait и сам вывод начинался после возникновения прерывания по вектору 100 («кадровое прерывание» на БК). Это необходимо, чтобы спрайты не мигали на экране, ведь их приходится стирать и выводить снова, и момент, когда спрайта нет на экране не должен быть виден игроку. Но это самое ожидание обратного хода луча может все и тормозить, если программе есть чем заняться 🙂 Альтернативой является использование двух экранных страниц — одну страницу скрываем, стираем на ней спрайты (все равно она не отображается сейчас), выводим заново на новых местах, а в это время демонстрируем вторую. Таким образом момент, когда спрайты стерты, не виден.
На БК0011М экранных страниц две. А сколько их на AZBK? Да сколько хочешь, ведь вся память AZBK может быть отображена с любой страницы. И включать эти страницы можно в любые слои экрана. Вот я и завел себе две экранных страницы для верхнего экранного слоя и вывожу туда бегущего Дейва, попеременно включая то одну, то вторую. В итоге ожидания обратного хода луча нет и мигания спрайтов тоже нет.
Завтра заведу две экранных страницы и для среднего слоя, где Зомби гуляют.
Свежие комментарии