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

Цель у этого всего одна - избавиться от того, что процесс отрисовки виден на экране в реальном времени. Как мне кажется, это довольно сильно раздражает

Сделал вчера игровую карту и функции перемещения (ну почти) и поворота.
При каждом изменении вызывается функция отрисовки экрана, а между этим экран очищается.
И вроде как это смотрится не так уж раздражающе медленно)

А еще в конце можно увидеть, что если зайти за пределы карты, то можно отправиться путешествовать по памяти компа)

Но как это путешествие работает, надо описать:

У игрока есть позиция Y и позиция X, а у каждой строки карты размером 24*24 байта есть свой адрес. Адреса забиты в таблицу указателей на адреса строк.

То есть позиция игрока высчитывается как текущий адрес строки из таблицы со смещением Y + смещение по X.

Если выйти за пределы карты, например позиция игрока станет не 24, а 40, то адрес строки будет равен "адрес начала таблицы + 40", а что хранится в этом месте неизвестно. Это может быть указатель хоть на самую первую страницу памяти.

Зато, если уйти за пределы карты вправо, то игрок перескочит на следующую строку в противоположном конце карты, и наоборот🙈

Думаю, это можно как-нибудь использовать для секретов, главное ничего не сломать:)

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

Видео-отчет за последние несколько дней безудержного веселья.
Нет, серьезно, мне уже снятся эти байты.
Вчера мне приснилось, что для того, чтобы проснуться, надо поменять значение будильника в регистре памяти.
Я во сне написал программу на ассемблере и спокойно проснулся под будильник🤦‍♂

А они все ждут своего часа ....
Когда-нибудь я напишу что-нибудь на ассемблере для МК-90, починю арифмометры.

Но Commodore, он постоянно где-то в тени и наблюдает за мной. Требует новых игр

Видимо, надо вызывать ведьмака

Думаю, как реализовать триггеры.
Пока придумал такую штуку. Каждый триггер будет иметь такие параметры:
Позиция X и Y на карте;
Номер ключа (будет проверяться наличие ключа у игрока);
Флаги Single use и Available.
Первый флаг будет означать, что триггер срабатывает один/бесконечное количество раз и переключает флаг Available в ноль в первом случае.
Второй флаг будет означать, что в данный момент триггер можно/нельзя активировать.

Допустим, я хочу сделать триггер для двери. Так как я отказался от отрисовки "комнаты за комнатой", дверь будет обычным блоком. К этом блоку надо привязать два триггера. Первый будет телепортировать игрока в одну сторону, второй - в другую. К тому же каждый триггер будет Single use (то есть флаг Available будет выставляться в 0) и должен активировать противоположный триггер (флаг Available выставляется в 1).

Получится так:
00000001 - тип триггера "дверь".
00000011 - флаги выставлены в 1.
Два байта - позиция на карте.
Один байт - номер ключа.
Два байта - позиция для телепортации игрока.
Один байт - номер триггера, который нужно будет активировать после телепортации.

Пока что я предполагаю, что на 1 уровне будет как минимум 64 триггера. Один триггер занимает 8 байт, то есть в сумме 512 байт.

Планируются такие триггеры:
— Телепортация (односторонняя);
— Дверь (телепортация + активация другого триггера);
— Смена видимости блока (выставляем флаг Textured на блоке в 0 или 1);
— Смена коллизии блока (флаг Solid в 1 или 0);
— Смена текстуры блока (меняется номер текстуры блока от 0 до 15);
— Смена флага Single use триггера (пока не придумал конкретные ситуации, где это можно использовать);
— Смена флага Available триггера (таким образом можно активировать будущие сюжетные триггеры, которые в начале уровне не будут доступны);
— Вывод текста на экран (будет определяться адрес текста в памяти)
— Триггер для смены уровня (тут будет номер следующего уровня, на основе которого уже будут считываться нужные файлы с дискеты. Осталось разобраться, как эти файлы считывать).
Как вариант, можно сделать триггер на смену параметров другого триггера, но конкретные примеры я пока тоже не придумал.
Чувствую. что большинство триггеров я буду придумать по ходу создания уровней для конкретных ситуаций.

Немного о том, как я создаю текстуры для игры=)

Сперва я их рисую в Multipaint - программа, в которой можно рисовать для большого количества старых компьютеров, включая Commodore 64, VIC-20, ZX Spectrum и Amstrad.

Потом я своими руками переношу данные текстур попиксельно в Excel, где уже с помощью формул СЦЕП и ДВ.В.ШЕСТН создаю нужное представление последовательности байт для ассемблера.
Но я уже устал так делать😂 Пора бы что-нибудь на питоне написать для облегчения жизни

Ну и наконец видео-обновление. Перенес все текстуры в игру. Может быть потом еще придумаю, как это дело улучшить:)

Прикинул, как будет выглядеть спрайт оружия.
Здесь он состоит из двух спрайтов в столбец.
И, похоже, придется отказаться от видимого оружия в руках (либо использовать 1 спрайт, а не два), так как оно занимает половину экрана. За ним ничего видно не будет=)

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

И опять я обратился к Doom RPG.
Так же как и там я хочу добавить всего 4 параметра:
Attack - сила удара.
Defence - модификатор защиты.
Dexterity - ловкость (шанс уклониться).
Accuracy - точность (шанс попасть).

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

Но еще в Doom RPG мне нравилось, что разные враги могут по разному реагировать на разное оружие. То есть, например, зомби очень быстро отлетает от дробовика, но почти не получет урон от автомата.

И я придумал, как довольно просто это сделать.
Всего будет 8 видов оружия, а у каждого монстра 1 байт будет отвечать за флаги подверженности конкретному виду.
Если, например, нулевой бит выставлен в 0, то враг получает пониженный урон от первого оружия. Если бит == 1, то двойной урон.
Ну или как-то так

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

Дело в том, что у меня триггер прикрепляется к определенному блоку на карте по координатам.

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

Но так как оба триггера прикреплены к одному блоку, то функция проверяет их оба в цикле.
Первый триггер срабатывает нормально. Он перемещает игрока и включает второй триггер.

А вот второй триггер перемещает игрока, включает первый триггер. Но тут же в цикле отрабатывает первый триггер, который переключает все обратно😂

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

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

В итоге пошел по второму варианту=)
Теперь триггер меняет свои собственные аргументы (координаты, куда отправляется игрок) после выполнения. И места в памяти меньше занимает и работает также быстро

Ну и наконец понял, как лучше хранить информацию.

До этого триггеры у меня хранились таким образом:

trigger_1
атрибут 1, атрибут n
trigger_n
атрибут 1, атрибут n

Теперь я перевернул таблицу:

triggers_attribute_1
триггер 1, триггер n
triggers_attribute_2
триггер 1, триггер n

Такой вариант позволил избавиться от indirect indexed адресации. То есть теперь используются только команды типа lda byte,x.
И во-вторых, я избавился от таблиц ссылок на адреса триггеров, которые нужны были как раз для непрямой адресации)

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

Сегодня не так много сделано, потому что я полвечера разбирался, почему вылезает ошибка.
Оказалось, что ошибка исключительно из-за моей тупости, потому что где-то в 2000 строках кода я оставил команду LDA без операнда. Правда и IDE указывала, что ошибка находится совершенно в другом месте=)

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

И вот так, как на видео их можно комбинировать: кнопка (смена текстуры) + исчезающий соседний блок.