Тут еще вопрос как будет выглядеть поворот камеры, учитывая, что минимальное смещение камеры 1 тайл (8 пикселей).
Осталось написать рейтресинг и можно будет попробовать собрать демку. Интересно как оно будет выглядеть.
Еще нужно определиться с оптимальной геометрией локации. Угол обзора, площадь одного блока карты, дальность обзора, высота стен.
Пока буду ориентироваться на 16 тайлов как максимальную высоту стены. Угол обзора думаю взять 90 градусов, так будет детальнее сцена. При 32-х лучах на 90 градусов получаем 2.8 градуса на луч.
Еще можно сделать масштабирование текстур. Нарисовать 3-4 варианта и подставлять нужную в зависимости от расстояния до стены. Но это потом.
Если использовать Брезенхема для определения коллизий, то заодно можно получить и расстояние до пересечения. Не нужно будет считать корни и квадраты. Но с таблицами не уверен, что быстрее будет работать. Может Брезенхем тут и не пригодится.
10000 операций должно хватить на расчёт 32-х лучей по-любому. Думаю останется время и на остальные вещи.
Попробовал позднее зажигание сцены, это работает. Есть небольшие артефакты, но можно вывести за кадр 700-800 байт за счёт выбрасывания 4х верхних строк невидимых.
700 байт хватает на вывод 20 строк тайлов за один кадр. Размер окна 20х32 думаю вполне норм. Остальные 8 строк можно использовать под интерфейс.
Скролинг задаёт положение камеры между двумя таблицами имён (это по сути две фоновые картинки, которые имеют смешные края). А скрол водит камеру с одной картинки на другую.
Лучше выводить фон за 1 кадр, так как редактирование фона в несколько кадров будет заметно или нужно будет формировать кадр в невидимой таблице имён и после дорисовки нового кадра переводить на неё камеру, но это тоже может быть заметно. Поэтому лучше стараться за один кадр все сделать. Тем более 60 фпс это приятно.
Но все текстуры придётся использовать готовые для краёв стен, дверей, окон и тд. По месту подставлять нужные тайлы, попиксельное рисование слишком медленное (нужно грузить 16 байт вместо одного).
Попробовал сейчас сколько можно максимально записать байт в видео память в NTSC и PAL. В итоге получается, что в NTSC за время возврата луча можно загрузить 209 байт, в PAL - целых 265. Десяток +- байт еще можно накрутить, если упростить обработчик прерывания и убрать вызов функции.
Это значит, что в PAL уже можно вывести 2.5D сцену 16х16 тайлов за один кадр. Или 60 фпс, если успею посчитать 16 лучей за время кадра
В NTSC тоже скорее всего получится, если использовать позднее включение экрана. Там верхние 4 ряда тайлов все равно не используется, а это довольно много времени (около двух миллисекунд или 4000 тактов). Загрузка одно байта занимает 8 тактов, а это целых 500 байт (в идеале)!
Пока только бегло ознакомился, тут мне надо целенаправленно вникать, ибо тема серьёзная. Про оптимизацию рейтрейсинга я пока даже не думал :)
И пока не могу ничего по срокам говорить, и так щас в активной разработке несколько больших денди проектов. 2.5D только в списке планов. Но может и набросаю наивную демку за пару вечеров в рубрике 6 кадров )
А идея с полигональными врагами и 2.5D фонами хорошая, я больше думал про статичные фоны а-ля резиденты. Полигональные модели ещё и масштабировать можно.
Совмещение 2.5d и 3d вполне бьётся, так как модели я вывожу спрайтами. Для фонов места достаточно в видеопамяти.
Ещё есть вопрос плавной смены кадров. Тут я думаю можно использовать скролинг. Один кадр рисуем в первую таблицу имён, второй во вторую. Так можно будет разом вывести весь кадр, если он формировался несколько аппаратных кадров.
А в тему синусов и умножений. Тут только таблицы. Места должно хватить.
И ещё раз спасибо за статью, очень полезно и интересно.
Давно хочу свою ОС написать полноценную, но сначала для ардуины, а то там только иммитации. Полноценной рабочей станции не нашёл на гитхабе. Там интересно будет написать виртуальную машину или интерпретатор.
Потом её можно будет портировать на денди, если код правильно организовать.
Спасибо за рекомендации игр, надо ознакомиться с референсами.
А 2.5D окружение без доп видео надстройки действительно невозможно, особенно на весь экран.
Но если сделать стены без заливки, то может и получится сделать плавную камеру в нормальном разрешении. Надо считать тайлы и такты. И я прикидывал, что смогу заменить умножение таблицами, памяти хватает. Как-нибудь попробую.
В каком-то виде 2.5D движок обязательно буду реализовывать, без плавной камеры точно получится. Да и были такие игры на NES.
Видеокарту будем изобретать в одном из будущих проектов :) (есть очень необычная идея). Для денди пока попробую ограничиться базовыми возможностям и простым маппером.
И хорошо бы ещё заняться написанием хорошего кода реализации ММС3 маппера под дешёвые ПЛИС 5 вольтовые. Можно было бы делать дешёвые картриджи и с минимумом микросхем. Но с ПЛИС у меня маловато опыта.
Хорошая идея с разбиением расчёта крайних точек. Брезенхем более красивые края даёт, текущий алгоритм из-за округления рвёт некоторые линии. А по скорости надо экспериментировать. Спасибо за идею.
В моих экспериментах получалось редактировать около 22 тайлов видеопамяти в монохромном режиме 60 герц за один межкадровый промежуток, а сцена состоит из 80 тайлов. Это значит около 15 кадров в секунду.
Можно перейти на 50 герц режим и немного оптимизировать загрузку новых тайлов. Это уже будет ближе к 30 тайлам за кадр.
На рендер 10-20 полигонов уходит примерно те же самые 2-4 кадра, но тут тоже ещё есть простор для оптимизации математики.
Итого, я рассчитываю на 10-20 кадров на простых моделях до 20 полигонов.
А на счёт отдельного процессора в картридже я согласен, это не спортивно. И специально использую простой маппер, чтоб было интереснее программировать и проще потом сделать физический картридж.
Elite уже давно портирован на NES и довольно неплохо работает. Но я пошёл немного другим путем в плане организации памяти, поэтому возможности движков отличаются.
Мой движок позволяет выводить более сложные модельки, можно будет что-то более красивое попробовать вывести. Но на уровне Элит точно оно работать будет.
Вы правы. Но Sweet Home довольно сильно отличается от современных представлений о survival horror, поэтому я позволил себе такую формулировку. Такой заголовок выбран для привлечения внимания на ютубе.
Размерность целой и дробной части уже надо от конкретных задач выбирать, тут я согласен. В посте выбрал 8.8 как наиболее стандартный вариант. В конечных проектах с 3D возможно тоже буду играться с размерностью.
В ноябре надеюсь закончить прототип 3D-движка и попробовать повращать модельки. Просто выводить наборы полигонов уже получается, надо сделать матрицу трансформаторы и определение угла наклона полигона (там несложно, как выяснилось). Интересно сколько ФПС получится выжать. И какое количество полигонов даст адекватный ФПС с заливкой и без.
ПС: посмотрел ваши посты, очень круто. У вас сильно круче проекты ретроконсольные :)
Я точно так же делал в своих экспериментах с попиксельным рисованием. Генерировал тайлы с нужными включёнными пикселями находу и грузил в видеопамяти.
Уже даже придумал концепцию 3д игры простой) Может получится сделать освещение модели, но проволочная модель точно получится.
И спасибо за ссылку. Посмотрел как авторы Элит реализовали рисование линий. Я почти к тому же самому пришёл, когда выводил линии тайлами, но они организацию памяти немного подругому сделали. Хорошая тема для статьи.
Ufix24_8 - это обычный uint32_t, т.е. беззнаковая переменая на 4 байта. А стандартных типов на 3 байта нет, поэтому просто так не заменить.
Но можно реализовать свой трехбайтный тип и прописать для него всю математику. Это имеет смысл, так как экономит лишние копирования байтов. И 2 байта хватит на целую часть. Так что идея правильная.
Нет, Elitе на денди мне не попадалась. Но для неё скорее всего исходников нет открытых, а дизассемблировать и разбирать весь движок - это огромная работа. Все игры для денди построены на всяких хаках, поэтому там внутри скорее всего много жести.
Спасибо, надо будет посмотреть как этот порт выглядит. Мне он раньше не попадался.
Проблема с графикой в том, что на денди она вся состоит из тайлов. Отдельно редактировать каждый пикаель нельзя.
Чтоб выводить графику пикселями, нужно генерировать тайлы с расставленными в нужных местах пикселям. И загружать их в видео память. Но одновременно консоль может хранить только 256 уникальных тайлов. А для всего экрана нужно 1024 тайла.
Есть вариант переключать банки видеопамяти во время вывода каждого кадра 4 раза, но все равно с генерировать 1024 тайла это очень долго. Но если ограничить число точек на экране, то можно использовать и весь экран более-менее быстро.
Я делал набросок 2д движка пиксельного. Развернутым циклом получалось вывести на экран максимум 21 тайл за кадр в режиме 60 герц в монохромном режиме, а цветом 15 тайлов. Один тайл занимает 16 байт. Но это замена всех пикселей, отдельные пиксели редактировать быстрее.
Плавное 3д вращение сделать можно, но для очень простых скелетных фигур. Но более сложные модели я буду тожн пробовать выводить.
Тут еще вопрос как будет выглядеть поворот камеры, учитывая, что минимальное смещение камеры 1 тайл (8 пикселей).
Осталось написать рейтресинг и можно будет попробовать собрать демку. Интересно как оно будет выглядеть.
Еще нужно определиться с оптимальной геометрией локации. Угол обзора, площадь одного блока карты, дальность обзора, высота стен.
Пока буду ориентироваться на 16 тайлов как максимальную высоту стены. Угол обзора думаю взять 90 градусов, так будет детальнее сцена. При 32-х лучах на 90 градусов получаем 2.8 градуса на луч.
Еще можно сделать масштабирование текстур. Нарисовать 3-4 варианта и подставлять нужную в зависимости от расстояния до стены. Но это потом.
Если использовать Брезенхема для определения коллизий, то заодно можно получить и расстояние до пересечения. Не нужно будет считать корни и квадраты. Но с таблицами не уверен, что быстрее будет работать. Может Брезенхем тут и не пригодится.
10000 операций должно хватить на расчёт 32-х лучей по-любому. Думаю останется время и на остальные вещи.
Попробовал позднее зажигание сцены, это работает. Есть небольшие артефакты, но можно вывести за кадр 700-800 байт за счёт выбрасывания 4х верхних строк невидимых.
700 байт хватает на вывод 20 строк тайлов за один кадр. Размер окна 20х32 думаю вполне норм. Остальные 8 строк можно использовать под интерфейс.
Скролинг задаёт положение камеры между двумя таблицами имён (это по сути две фоновые картинки, которые имеют смешные края). А скрол водит камеру с одной картинки на другую.
Лучше выводить фон за 1 кадр, так как редактирование фона в несколько кадров будет заметно или нужно будет формировать кадр в невидимой таблице имён и после дорисовки нового кадра переводить на неё камеру, но это тоже может быть заметно. Поэтому лучше стараться за один кадр все сделать. Тем более 60 фпс это приятно.
Но все текстуры придётся использовать готовые для краёв стен, дверей, окон и тд. По месту подставлять нужные тайлы, попиксельное рисование слишком медленное (нужно грузить 16 байт вместо одного).
Попробовал сейчас сколько можно максимально записать байт в видео память в NTSC и PAL. В итоге получается, что в NTSC за время возврата луча можно загрузить 209 байт, в PAL - целых 265. Десяток +- байт еще можно накрутить, если упростить обработчик прерывания и убрать вызов функции.
Это значит, что в PAL уже можно вывести 2.5D сцену 16х16 тайлов за один кадр. Или 60 фпс, если успею посчитать 16 лучей за время кадра
В NTSC тоже скорее всего получится, если использовать позднее включение экрана. Там верхние 4 ряда тайлов все равно не используется, а это довольно много времени (около двух миллисекунд или 4000 тактов). Загрузка одно байта занимает 8 тактов, а это целых 500 байт (в идеале)!
Очень неожиданно, спасибо за наработки и идеи)
Пока только бегло ознакомился, тут мне надо целенаправленно вникать, ибо тема серьёзная. Про оптимизацию рейтрейсинга я пока даже не думал :)
И пока не могу ничего по срокам говорить, и так щас в активной разработке несколько больших денди проектов. 2.5D только в списке планов. Но может и набросаю наивную демку за пару вечеров в рубрике 6 кадров )
А идея с полигональными врагами и 2.5D фонами хорошая, я больше думал про статичные фоны а-ля резиденты. Полигональные модели ещё и масштабировать можно.
Совмещение 2.5d и 3d вполне бьётся, так как модели я вывожу спрайтами. Для фонов места достаточно в видеопамяти.
Ещё есть вопрос плавной смены кадров. Тут я думаю можно использовать скролинг. Один кадр рисуем в первую таблицу имён, второй во вторую. Так можно будет разом вывести весь кадр, если он формировался несколько аппаратных кадров.
А в тему синусов и умножений. Тут только таблицы. Места должно хватить.
И ещё раз спасибо за статью, очень полезно и интересно.
Я бы начал с клавиатуры)
Давно хочу свою ОС написать полноценную, но сначала для ардуины, а то там только иммитации. Полноценной рабочей станции не нашёл на гитхабе. Там интересно будет написать виртуальную машину или интерпретатор.
Потом её можно будет портировать на денди, если код правильно организовать.
А можно ссылку на описание реализации? Там ведь маппер простой, нет прерываний по счётчику строк, видимо просто такты посчитали.
Спасибо за наводку, я примерно представляю как это можно реализовать в моем случае.
Спасибо за рекомендации игр, надо ознакомиться с референсами.
А 2.5D окружение без доп видео надстройки действительно невозможно, особенно на весь экран.
Но если сделать стены без заливки, то может и получится сделать плавную камеру в нормальном разрешении. Надо считать тайлы и такты. И я прикидывал, что смогу заменить умножение таблицами, памяти хватает. Как-нибудь попробую.
В каком-то виде 2.5D движок обязательно буду реализовывать, без плавной камеры точно получится. Да и были такие игры на NES.
Видеокарту будем изобретать в одном из будущих проектов :) (есть очень необычная идея). Для денди пока попробую ограничиться базовыми возможностям и простым маппером.
И хорошо бы ещё заняться написанием хорошего кода реализации ММС3 маппера под дешёвые ПЛИС 5 вольтовые. Можно было бы делать дешёвые картриджи и с минимумом микросхем. Но с ПЛИС у меня маловато опыта.
Да, сс65 слабенький. Приходится очень аккуратно с ним работать.
Я пока стараюсь обойтись без доп процессоров, а то так и дум можно запустить :)
Да, вы угадали, так и делал :)
Хорошая идея с разбиением расчёта крайних точек. Брезенхем более красивые края даёт, текущий алгоритм из-за округления рвёт некоторые линии. А по скорости надо экспериментировать. Спасибо за идею.
В моих экспериментах получалось редактировать около 22 тайлов видеопамяти в монохромном режиме 60 герц за один межкадровый промежуток, а сцена состоит из 80 тайлов. Это значит около 15 кадров в секунду.
Можно перейти на 50 герц режим и немного оптимизировать загрузку новых тайлов. Это уже будет ближе к 30 тайлам за кадр.
На рендер 10-20 полигонов уходит примерно те же самые 2-4 кадра, но тут тоже ещё есть простор для оптимизации математики.
Итого, я рассчитываю на 10-20 кадров на простых моделях до 20 полигонов.
А на счёт отдельного процессора в картридже я согласен, это не спортивно. И специально использую простой маппер, чтоб было интереснее программировать и проще потом сделать физический картридж.
Я специально указал в тексте превью, что в первой части будет работа с 2D.
И приведённого в статье кода уже достаточно для вывода 3D-модели как на превью, пусть и статичной. Так что кликбейта почти нет :)
Elite уже давно портирован на NES и довольно неплохо работает. Но я пошёл немного другим путем в плане организации памяти, поэтому возможности движков отличаются.
Мой движок позволяет выводить более сложные модельки, можно будет что-то более красивое попробовать вывести. Но на уровне Элит точно оно работать будет.
Вы правы. Но Sweet Home довольно сильно отличается от современных представлений о survival horror, поэтому я позволил себе такую формулировку. Такой заголовок выбран для привлечения внимания на ютубе.
Размерность целой и дробной части уже надо от конкретных задач выбирать, тут я согласен. В посте выбрал 8.8 как наиболее стандартный вариант. В конечных проектах с 3D возможно тоже буду играться с размерностью.
В ноябре надеюсь закончить прототип 3D-движка и попробовать повращать модельки. Просто выводить наборы полигонов уже получается, надо сделать матрицу трансформаторы и определение угла наклона полигона (там несложно, как выяснилось). Интересно сколько ФПС получится выжать. И какое количество полигонов даст адекватный ФПС с заливкой и без.
ПС: посмотрел ваши посты, очень круто. У вас сильно круче проекты ретроконсольные :)
Я точно так же делал в своих экспериментах с попиксельным рисованием. Генерировал тайлы с нужными включёнными пикселями находу и грузил в видеопамяти.
Уже даже придумал концепцию 3д игры простой) Может получится сделать освещение модели, но проволочная модель точно получится.
И спасибо за ссылку. Посмотрел как авторы Элит реализовали рисование линий. Я почти к тому же самому пришёл, когда выводил линии тайлами, но они организацию памяти немного подругому сделали. Хорошая тема для статьи.
Ufix24_8 - это обычный uint32_t, т.е. беззнаковая переменая на 4 байта. А стандартных типов на 3 байта нет, поэтому просто так не заменить.
Но можно реализовать свой трехбайтный тип и прописать для него всю математику. Это имеет смысл, так как экономит лишние копирования байтов. И 2 байта хватит на целую часть. Так что идея правильная.
Нет, Elitе на денди мне не попадалась. Но для неё скорее всего исходников нет открытых, а дизассемблировать и разбирать весь движок - это огромная работа. Все игры для денди построены на всяких хаках, поэтому там внутри скорее всего много жести.
Спасибо, надо будет посмотреть как этот порт выглядит. Мне он раньше не попадался.
Проблема с графикой в том, что на денди она вся состоит из тайлов. Отдельно редактировать каждый пикаель нельзя.
Чтоб выводить графику пикселями, нужно генерировать тайлы с расставленными в нужных местах пикселям. И загружать их в видео память. Но одновременно консоль может хранить только 256 уникальных тайлов. А для всего экрана нужно 1024 тайла.
Есть вариант переключать банки видеопамяти во время вывода каждого кадра 4 раза, но все равно с генерировать 1024 тайла это очень долго. Но если ограничить число точек на экране, то можно использовать и весь экран более-менее быстро.
Я делал набросок 2д движка пиксельного. Развернутым циклом получалось вывести на экран максимум 21 тайл за кадр в режиме 60 герц в монохромном режиме, а цветом 15 тайлов. Один тайл занимает 16 байт. Но это замена всех пикселей, отдельные пиксели редактировать быстрее.
Плавное 3д вращение сделать можно, но для очень простых скелетных фигур. Но более сложные модели я буду тожн пробовать выводить.
Ниже пример работы этого движка в монохроме.