Tagged: железо

02
Дек
2024

Новый (старый) звуковой движок

Добавление новых звуков сподвигнуло на давно назревший перенос звуков и самого движка в память AZBK. Основной обработчик прерывания по вектору 100 (кадровое прерывание) расположен в основной памяти БК, конечно.

Далее

30
Ноя
2024

Добил звуки

Сегодня весь день доделывал недостающие звуки — взятие бонусов 200, 800, 1600 очков, звук перехода из уровня в уровень, звук проигрыша и т.д. Авторы, конечно, не заморочились музыкой — довольно бредовые присвистывания вместо нее. Думаю, не стоит ли воспользоваться фишкой AZBK по проигрыванию оцифровок в фоне через DMA и добавить-таки музыку? Получится глобальная демонстрация возможностей девайса 🙂

 

29
Сен
2024

Две новости — хорошая и плохая

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

Подробнее

 

18
Сен
2024

Готов переход из одного лабиринта в другой

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

Подробнее

20
Июн
2024

Продвигаемся дальше

После долгого перерыва на отпуск, послеотпускной завал работы, простуду, я наконец-то вышел на рабочий режим, въехал в собственный код и проект «Dangerous Dave для БК0011М+AZBK» начал двигаться.
Первым делом я столкнулся с тем, что Maxiol и Gid внесли изменения в железо AZBK и его реализацию в эмуляторе GID. Изменения, собственно, я сам и запрашивал, сталкиваясь с проблемами видеовывода то в железе, то в эмуле. Эти изменения притащили с собой новый формат команд и новые команды блиттера. Пришлось долгое время переписывать все процедуры Дейва, связанные с выводом на экран, под нововведения в параметрах команд блиттера. Было много глюков — спрайты рисовали не там, где надо, весь экран начинал покрываться рябью и все таком стиле. Постепенно это все ушло в небытие и Дейв начал снова бегать по лабиринту (первый уровень мне уже порядком надоел).
Но он не просто начал снова бегать, он начал снова глючить — момент перехода рулона через ноль и переключения в этот момент страниц видеопамяти вызывает дергание экрана. Все потому что движок Дейва не всегда успевает подготовить новый кадр за 1/60 секунды, чтобы вывести новые данные в момент обратного хода луча. А если не ждать этого момента — манипуляции с экраном становятся видны. На данный момент я еще не придумал, как это побороть.
Так что я решил пока двигаться дальше — какой смысл впихивать текущую подготовку кадра в 1/60 сек, если еще не все механизмы готовы? Еще нет разлетающихся кровавых ошметков от монстров, не все монстры задействованы и т.д.
Первым делом я занялся попаданиями пули по монстрам. Тут было два варианта решения:
1.  При трассировке траектории пули на каждом шагу сверяться с массивом координат монстров и определять совпадение монстра и пули.
2. Завести слой лабиринта, по «знакоместам» которого двигать коды монстров (точнее, сразу указатели на записи о монстрах) при их передвижении по лабиринту. Тогда для проверки совпадения не нужно пробегать всех врагов, можно просто сразу получить указатель на того, что попался в этом «знакоместе» лабиринта.
Первый вариант не накладывает новых расходов на движок, зато грозит долгой обработкой кучи данных при стрельбе. Второй вариант делает стрельбу скоростной, но нужно двигать лишние данные на каждом движении монстров. Я выбрал второй путь. Это потребовало памяти, но, т.к. я использую AZBK, то памяти у меня вагон. Да и к тому же, как оказалось, страницы 5 и 6 (экраны БК0011М) теперь тоже можно использовать как обычные страницы памяти, ведь  они больше не используются для вывода на экран.
Метод был успешно реализован, теперь надо было сделать визуализацию попадания пули в монстра. В Дейве это реализовано выводом текущего спрайта монстра полностью залитым белым цветом. Я собирался генерировать такой спрайт программно, но Maxiol сказал, что это можно легко заставить делать блиттер. В итоге в новой версии блиттера (и в эмуле GIDа) к моему приезду как раз появилась такая команда. Я воспользовался ей и все сразу заработало, что удивительно. Спрайты «блымкают» белым как надо, это сразу добавило энтузиазма, как и любое продвижение вперед.
В прилагаемом ролике видны дергания экрана, это как раз те глюки при переключении страниц, которые меня вгоняют в тоску. Также там видно, что Зомби пока что слезают со ступенек раньше, чем дойдут до пола, но это все ерунда. Хуже то, что при большом количестве Зомби на экране Дейв начинает притормаживать, но я утешаю себя тем, что в реальной игре Дейв просто не может пройти через такое количество врагов, они его сожрут раньше. Но в целом, конечно, надо искать узкие места и оптимизировать.
14
Июн
2024

Новый вариант блиттера

Переписываю вывод всей графики на новый формат команд блиттера. Помимо изменения способа задания размеров спрайта, добавился и новый способ позиционирования спрайтов на экране — теперь блиттеру можно указать координату Y в виде номера строки. Раньше это был 24-битный адрес. Так что переделывать пришлось много чего. Но уже почти все получилось.
Из-за длительного перерыва (отпуск на море!) дело шло со скрипом. Все-таки пока целиком погружен в проект — пишется легко, вся структура в голове. А немного отвлекся и приходится въезжать заново 🙂

Рубрики

Поддержать проект

Свежие комментарии

Подпишитесь на нашу рассылку