Сегодня тоже особо нет обновлений. Времени особо не было.
Но я понял, как сохранить еще немного памяти для программы.

Отрисовка экрана у меня работает в двух режимах: Multicolor Hires и Standard Text Mode.
Переключаются они с помощью прерывания на 209 растровой линии.
Так вот я наконец додумался, что память экрана с того места, где начинается Text Mode и до конца не будет использоваться, потому что Text Mode берет данные вообще из другого места.
А это аж 1600 свободных байт!

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

rays_tex_table_lo_adr
        byte    $90,$20,$d8,$14,$20,$d8,$9c,$20,$d8,$28,$20,$d8,$b8,$20,$d8,$4c

А я сделал так, и все заработало:

rays_tex_table_lo_adr
        byte    <tex_128,<tex_96,<tex_48,<tex_124,<tex_96,<tex_48,<tex_120,<tex_96

Сделал триггер вывода текста.
Всего зона для текста будет занимать 120 символов (24 символа на 5 строк). Маловато, конечно.
К тому же придется так подбирать выражения, чтобы они попадали в ширину этой зоны.

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

Но у второго подхода есть свой минус - можно не успеть прочитать текст.

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

Да даже это тестовое выражение уже занимает 53 байта.

Не придумал ничего лучше для GUI😂😂
Максимально тупая идея, но под стилистику игры подходит

Проблема в том, что Multipaint ну очень криво распределяет цвета по памяти компьютера.
Похоже придется делать все вручную...

А если переносить все, как есть, то получается вот такая каша)

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

Для конвертации PNG в коммодоровский формат я написал самый ужасный питоновский скрипт в своей жизни. Не пишите код под пивом, ребята=)

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

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

Самый оптимальный вариант - это подгружать значения цветов с дискеты (или образа дискеты). То есть порядок действий будет такой:
1. Загружаем основную программу.
2. Подгружаем с дискеты значения цветов на основной экран.
3. Ничего не ломается.
4. ...
5. Profit

Надеюсь, это сработает

Наконец-то разобрался, как подгружать данные с дискеты.
Для этого используются функции KERNAL (местная операционная система):
SETLFS (устанавливает логический номер файла и логический номер устройства);
SETNAM (устанавливает длину и адрес имени файла)
LOAD (загружает данные из файла).

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

А вот как теперь выглядит запуск игры.
Довольно забавно)

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

Проблема одна - из-за прерывания между hires и text mode, последняя линия изображения отрисовывается криво и с артефактами. Буду думать, как решить эту проблему.

А ну и попробовал добавить текст с показателями здоровья/брони/параметров и т.д. Пока что кажется, что надо текст поменять (возможно сократить каждую фразу до двух символов, что позволит расширить текстовую зону).

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

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

Надеюсь, что за следующие полгода я решу большинство этих проблем

С Новым Годом, ребята:)

Сегодня я добавил спрайты и как же я с ними намучился=)

Оказалось, что зона в памяти с $1000 по $1fff занята зеркалом Character ROM, и видеочип не может считать спрайты из этой области. А это было идеальное место под них.
Видеочип смотрит всего на 16 Кб памяти одновременно, и под спрайты места не остается.

Поэтому сперва я принял решение изменить область памяти (VIC Bank), на которую смотрит видеочип (перенести туда, где Character ROM не зеркалится). Это слабо помогло, потому что пришлось бы учесть еще кучу возможных параметров: создать новые символы, перенести область, откуда берутся цвета для hires bitmap и при каждом прерывании менять не только параметры экрана, но и VIC Bank. В общем, куча лишних действий, да и всю программу пришлось бы перелопатить.

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

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

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

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

Собрал все последние важные штуки в один пост

https://dtf.ru/retro/2403931-dungeon-crawler-na-commodore-64-chast-vtoraya

Назрел вопрос на будущее.

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

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

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

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

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

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