(бухай): программируй
148 subscribers
465 photos
96 videos
3 files
65 links
Мысли, дегустация и код
Download Telegram
Поэтому можно заняться сравнениями.
Если 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, то все стало нормально
👍1
Но настоящая новость в том, что я наконец-то спустя миллион лет прошел Prince of Persia: Warrior Within.
Первый раз я поиграл в нее на PSP лет в 12 наверное. И она показалась мне такой сложной, но в то же время такой крутой (чего только Godsmack стоят, когда убегаешь от Дахаки). И для двенадцатилетнего меня все это "кровь-кишки-распидорасило" смотрелось ну очень впечатляюще.
И вот наконец, спустя столько лет, я наконец-то её осилил.
Даже статью захотелось написать про историю серии
👍4🔥1
Наконец-то дело сдвинулось с мертвой точки.
Написал основную функцию для увеличения столбцов текстуры и еще одну функцию, которая уменьшает следующие столбы для перспективы.

Конечно, это все еще оптимизировать и оптимизировать, потому что пока что работает оно довольно неторопливо, но по крайней мере, работает=)

Что до памяти, то тут все неплохо. Таблицы деления я ужал с 6Кб аж до двух (но за счет лишних операций, которые с ними надо производить), а сам код программы занимает пока что всего 373 байта.

Теперь надо написать две функции:
— первая увеличивает следующие столбцы (для стен в правой части экрана)
— вторая рисует текстуру прямо (для стен перед глазами)
Ну и вторая функция тоже работает
👍1
На первые два вопроса я еще пытался ответить серьёзно 😂
Тут подъехал суровый тест. Помогите ответить на вопросы...😅🙈
🤡1
И наконец я добился того, что хотел. Теперь получается генерировать разные виды лабиринта на основе того, что видит игрок (правда, ходить пока нельзя, да и карты как таковой еще не существует).
Текстура тоже пока одна, но это дело времени. Пока что я доволен, что наконец-то стали отрисовываться очертания лабиринта.
❤‍🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Скорость конечно не вау, но для пошагового лабиринта сойдёт. Вот это средняя скорость, когда на экране не так много высоких столбцов.
Но я буду думать, как все это дело ускорить
👍2
This media is not supported in your browser
VIEW IN TELEGRAM
А вот самый медленный вариант - на экране много высоких столбцов от 96 до 128 пикселей в высоту
👍2
Теперь хочу рассказать, как я это сделал.
Я придумал штуку, которую назвал Triple Block Raycasting, и ее точно уже придумали до меня.
Стандартный рейкастинг работает так: на каждый столбец экрана выпускается луч, который в какой-то момент встречается со стенкой. Записывается длина этого луча. Чем дальше стена, тем длиннее луч и, соответственно, высота стены будет меньше.
На Commodore 64 было бы очень сложно это воспроизвести (много вычислений и тригонометрии).
Поэтому я поместил в память таблицу, в которой для каждого луча (а их всего 64 при ширине экрана в 128, т.к. в режиме multicolor пиксель двойной ширины) указываются:
— номера блоков, с которым может столкнуться луч;
— высота линии, в случае, если луч столкнется с блоком;
— адрес таблицы увеличения текстур, которая позволяет обойтись без дорогого умножения и деления;
— координаты столбца текстуры.

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

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

Но для этого надо разобраться, как подгружать что-либо с дискеты=)
👍2
А вот и текстурки подъехали.
Но это все точно надо как-то оптимизировать, но пока не знаю как=(
🔥2
Сегодня сделал пару новых штук.
Во-первых, немного оптимизировал процесс отрисовки. Например, указал, что пустые пиксели закрашивать не надо.
Во-вторых, сделал прозрачные текстуры (и оптимизация полетела к чертям). То есть, если сквозь текстуру можно смотреть, то рисуются блоки позади.
Но пока что еще нет функции, которая определяет текстуру блока и раскрашивает пиксели в нужный цвет
❤‍🔥1
Ну и нарисовал депрессивные текстуры для русского жилища. Ковер присутствует =)
На один уровень будет по 16 уникальных текстур
3
Сегодня особо похвастаться нечем.
Я немного оптимизировал процесс отрисовки.
Для этого пришлось пожертвовать 1000 байт памяти. Если раньше у меня предрасчитанные значения индекса текстур лежали в одном байте попарно (от 0 до 15), то сейчас я их распределил по одному байту для каждого значения. Из-за этого теперь не приходится делать лишние операции сдвига.

Во-вторых, переписал функцию отрисовки пикселя на экране.
Раньше я брал первый блок строки и прибавлял к нему смещение по Y. Но сейчас я считаю блоки построчно, и к ним прибавляю индекс по Х. Получается без лишних 16 битных сложений.

Но все равно медленно!
❤‍🔥1