Наконец-то раздобыл себе второй стол и поставил все, что хотел )

Правда это все равно временное решение, потому что NEC не очень хорошо влез

Как год встретишь...

А вообще я давно хотел написать об отсутствии успехов в разработке dungeon crawler под Commodore, но раз успехов нет, то и писать почти не о чем, кроме того, что я никак не могу решить проблему наложения текстур на стены. Попозже постараюсь объяснить, в чем дело.

Допустим, есть текстура 16*16. И я хочу ее расширить до 34 в высоту, но каждый последующий столбец меньше на два пикселя (для перспективы). Делается это по столбцам.
Для каждого столбца надо пройтись по индексам новой высоты (от 0 до 33), умножить на 16 (старая высота) и поделить на 34 (новая высота).
Получается что-то вроде y = i*16/34

Умножение на 16 не проблема. Надо использовать 4 битовых сдвига влево (1 сдвиг - умножение на 2). А вот деление - довольно тяжелая операция, а с учетом, что делать это придется практически для каждого пикселя в зоне 128*128 - то, думаю, неподъемная.

Поэтому можно заняться сравнениями.
Если i*16 < 34, то берем 0 индекс исходной текстуры.
Если i*16 < 34*2, то берем 1 индекс, и так далее.

Я посчитал, и понял, что мне для этого надо умножить все возможные высоты текстур (четные числа от 32 до 128) на числа от 1 до 16. Все это можно поместить в таблицу, которая займет где-то полтора килобайта. Но можно и меньше, если умножения на 2,4,8,16 производить налету с помощью тех же битовых сдвигов.

В одном случае нагружается процессор, в другом заполняется память, а оптимальное решение я так и не нашел=(

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

Оказалось, что в одном месте я использовал не ту команду.
Мне надо было 4 раза сдвинуть биты в одном байте вправо. Для этого есть две команды: ROR и LSR.

Но они отличаются.
ROR в седьмой бит помещает значение из Carry.
Carry - это флаг переноса в старший разряд. Допустим, если прибавить 1 к 255, то 1 отправится в Carry. Так, например, работает сложение чисел, если результат больше 255.

А LSR в седьмой бит помещает 0.

И я использовал конечно же ROR, и в определенные моменты у меня число, которое должно выглядеть как 00001111 (15), превращалось в 00011111 (31) и ломало мне всю функцию. Когда я поменял ROR на LSR, то все стало нормально

Но настоящая новость в том, что я наконец-то спустя миллион лет прошел Prince of Persia: Warrior Within.
Первый раз я поиграл в нее на PSP лет в 12 наверное. И она показалась мне такой сложной, но в то же время такой крутой (чего только Godsmack стоят, когда убегаешь от Дахаки). И для двенадцатилетнего меня все это "кровь-кишки-распидорасило" смотрелось ну очень впечатляюще.
И вот наконец, спустя столько лет, я наконец-то её осилил.
Даже статью захотелось написать про историю серии

Ну и вторая функция тоже работает

На первые два вопроса я еще пытался ответить серьёзно 😂

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

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

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

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

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

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

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

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