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

А вот самый медленный вариант - на экране много высоких столбцов от 96 до 128 пикселей в высоту

Теперь хочу рассказать, как я это сделал.
Я придумал штуку, которую назвал Triple Block Raycasting, и ее точно уже придумали до меня.
Стандартный рейкастинг работает так: на каждый столбец экрана выпускается луч, который в какой-то момент встречается со стенкой. Записывается длина этого луча. Чем дальше стена, тем длиннее луч и, соответственно, высота стены будет меньше.
На Commodore 64 было бы очень сложно это воспроизвести (много вычислений и тригонометрии).
Поэтому я поместил в память таблицу, в которой для каждого луча (а их всего 64 при ширине экрана в 128, т.к. в режиме multicolor пиксель двойной ширины) указываются:
— номера блоков, с которым может столкнуться луч;
— высота линии, в случае, если луч столкнется с блоком;
— адрес таблицы увеличения текстур, которая позволяет обойтись без дорогого умножения и деления;
— координаты столбца текстуры.

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

А в плане памяти все осталось как есть.
Раньше таблица увеличения текстур занимала 2 килобайта (от 32 до 128 пикселей высоты с шагом 2). Теперь всего килобайт (от 32 до 128 с шагом 4).
Таблица для проверок лучей занимает чуть больше 1 Кб.
То есть в итоге я почти ничего не потерял, но зато получил нормальную картинку.

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

Но для этого надо разобраться, как подгружать что-либо с дискеты=)

А вот и текстурки подъехали.
Но это все точно надо как-то оптимизировать, но пока не знаю как=(

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

Ну и нарисовал депрессивные текстуры для русского жилища. Ковер присутствует =)
На один уровень будет по 16 уникальных текстур

https://www.youtube.com/watch?v=WZQ1FMWnG9w&t=15s
И вот офигенное видео о том, как устроена память в Commodore 64, и почему BASIC ограничен 38991 байтами

За эти выходные просто дофига новостей!

Во-первых, удалось увеличить скорость отрисовки почти на 50%.
И, внезапно, в этом мне помог Кирилл Лейфер. Благодаря ему я и Commodore купил, когда увидел видео про это на его YouTube канале.

Сейчас Кирилл сам делает игру про кота для C64:
https://t.me/paw_noir

Он посмотрел на мой код, кое-где оптимизировал, а потом я сам уже убрал возможность отрисовки "комнаты за комнатой".
Это сильно снижало скорость, а еще могли бы возникнуть конфликты цветов в одном знакоместе при коллоризации.

Во-вторых, я написал собственно функцию для колоризации.

В текстуре один пиксель может принимать значения: 01, 10, 11, 00.
11 - это цвет из Color RAM (1000 байт в одном месте памяти). Он у меня везде одинаковый - тёмно-серый.
00 - это цвет фона - черный.
А вот 10 и 01 могут быть любыми цветами, которые я помещу в третье место (еще 1000 байт в другом месте в памяти).
То есть текстура - это лишь набор ссылок на другие регистры.

Цветовую палитру для каждой текстуры пришлось хранить отдельно от самих текстур. Но таким образом цвета можно менять налету

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

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

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

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

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

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

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

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

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

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

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