Да, знаю исторических блогеров, которые продают платный доступ к текстам.
Это может работать, если блогер набрал большую аудиторию на массовых ресурсах, а потому перевёл кор-аудиторию к себе на закрытые каналы.
А с нуля я не представляю как можно набрать аудиторию по узкой теме на текстовых статьях. А если они ещё и платные будут с самого начала, то шансов ноль.
Перехватчик нажатий вызывается каждый раз при нажатии клавиши? Не слишком это замедляет выполнение программ? Хотя, если это работа с текстом, то все равно, наверное.
Интересно, что я тоже последнее время думаю про клавиатуры для древние компов. Мне нужно сделать клавиатуру для ДВК 3 и для рк86-подобного компа.
Ещё мечтаю о БК и спектруме (любой вариации), но пока на это все жалко денег). А с MSX совсем грустно в этом плане.
На счёт "мёртв" не уверен, но интересных статей стало меньше (по крайней мере для меня).
Раньше была куча очень необычных авторских программных и железных проектов, типа дампера Кластера (первое, что приходит в голову).
А сейчас 90+% ленты - это обзоры фреймворков и новых версий софта + какие-то очень специфические бизнес кейсы. А хочется читать про самодельный комп на пневматике или про обсерваторию на балконе:)
Но я и сам виноват в упадке, слишком редко пишу статьи. Затянулся проект с 3д движком для денди, но его точно добью. Будет интересно.
PS: Прошу прощения у своих подписчиков за долгое отсутствие, все проекты в работе. Спасибо, что не отписываетесь)
Вчера перед сном размышлял о движке и архитектуре таблиц. И забавно, что придумал примерно тоже самое, что ты описал в этом комментарии (код нормально тоже не смотрел ещё).
Тоже пришёл к мысли, что тангенсы вообще не нужны. Сделать таблицу тангенс*младший байт координаты даже проще. Можно ещё можно два младших разряда координаты убрать и получим в 4 раза меньшую таблицу, что хорошая экономия.
Только лучи около 0 и 90 градусов нужно отдельно обрабатывать.
Про 128 лучей согласен, логично. И хорошая идея про ориентацию по таблице из фиксированной стартовой позиции, но тут придётся вручную на асме писать. Сс65 туповат, он каждый раз будет считывать указатели в регистры. Но это мелочи.
И я примерно придумал как быстрое формирование стен сделать с дробными тайлами по краям. Если брать шаг тайла в 2 пикселя, там не так много вариантов высоты стен.
И со статус баром проблем нет. Можно выводить его спрайтами или использовать параллакс.
С полигонами тоже скорее всего многое заменится таблицами, ибо сцена всего 64х64 пикселя. Но там все надо доделать пока без оптимизации.
Код буду изучать, работа большая проделана, спасибо. Попробую его портировать. Прикрепи его на странице на итч.ио, так удобнее будет.
Но свою версию тоже постараюсь добить все равно, как минимум как учебное пособие для следующей статьи. Может просто в итоге не буду закапываться в оптимизацию, но посмотрим.
Библиотеку дробей я изначально писал, так как у СС65 они вообще никак не реализованы, только целые типы. Поэтому пришлось писать библиотеку. Там у меня псевдо дроби по факту, ибо они с фиксированной точкой, арифметика целочисленная.
Значит у тебя сейчас лучевая шестеренка на 128 зубьев? А как же рывки? Я наоборот перешел на таблицы с 1024 значений на 360 градусов, шаг 0.35 градуса. Значения в таблицах можно было сделать однобайтными, но проще знак хранить в таблице, чем генерировать его через свитч. Но вычисления, связанные с тангенсом, в однобайтные числа как закладывать? Тангенс около 90 градусов может быть +- 160.
Итоговый рендер выглядит отлично, меня такой результат устроил бы вполне. И туда не так сложно добавить имитацию освещения и добавить косые тайлы. Осталось собрать все в кучу и добиваться приятного вращения камеры и хотя бы 30 фпс.
Я тоже планировал заменять таблицами места, где число умножается на тангенс. Расстояние тоже можно было бы скорее всего загнать в чистые таблицы (на основе косинусов или корней не особо важно, суть одна).
А можно скрин с рендером последней версии? Самому лень все собирать и возиться с ДосБоксом.
Теперь по вопросам из предыдущего поста (забавно использовать комментарии для подобной переписки, для случайных зрителей тема обсуждения выглядит очень странно скорее всего :) .
Или там вообще одна переменная с двумя тетрадами X и Y?
Нет, я использовал целые байты. Половинки байт не использую из-за медленного считывания, да и хватает мне оперативки пока.
Речь о самих скалерах? Т. е. мы получили высоту колонки (относительно максимума в 16 или в 24 — время одинаковое ушло), но теперь её надо заполнить в дополнительном буфере (как я понял, этим мы весь кадр занимаемся, пока не наступило гашение луча на обратном ходу) — и вот тут как раз время сильно зависит от того, 16 или 24 тайла надо актуализировать?
Увеличится время на заполнение буфера для последующего его вывода в видеопамять. Работа с массивами через переменные-индексы очень плохо работает. Смещения желательно хардкодить (зато смещения могут быть 16-битными, ибо шина адреса 16 бит).
…и 256 стека, итого 512, верно?
Как бы вообще дофига, если честно. А как она такая быстрая вообще? Там что, SRAM, а не DRAM? Изначально-то понятно, это всё проектировалось под ROM и дюжину регистров под «прыг, скок и шмяк», но сейчас ведь там (по крайней мере в области спрайтов) оперативка и ещё к тому же маппер?
Стек хранится в общем адресном пространстве, его можно хранить в любых адресах и даже выбрать его размер можно, если не хватает оперативки. Обычно его делают 256 байт, но видел и 128 байт. Он нужен чисто для вызова функций, чтоб не потерять значения регистров. Для другого его использовать особо смысла нет. Скорость чтения одинаковая.
Чуть быстрее работают первые 256 байт оперативной памяти (из-за удобных адресов). Все остальная оперативка работает на 1-2 такта медленнее в зависимости от команды.
И, кстати, маппер переключает только часть области или всё вот это вот? Потому что при прямых руках можно вообще лихо сделать процессор-Джекил и процессор-Хайд, которые превращаются друг в друга переключением всей памяти, включая стек вызовов и переменные, и ничего не знают друг о друге :)
Мой маппер переключает первые 16 килобайт ROM. Вполне можно подключать и другие микросхемы ПЗУ, но счетчик команд будет указывать на последний адрес, а переключении всей ПЗУ он попадает неизвестно куда. Это нужно будет учитывать. Что такое я хочу сделать, когда буду картридж с ОС делать. Будет ПЗУ с загрузчиком (считывание дискет, магнитофона и т.д.). Когда загрузчик отработал и сложил программу в отдельную ОЗУ (которая будет работать как ROM), процессор переключится на подготовленную ОЗУ вместо загрузчика-ПЗУ. Самое простое делать это через RESET-прерывание, но можно спаять и аппаратное пользовательское прерывание в картридже (по-умолчанию оно не используется, висит в воздухе).
А это можно подержать в руках или оно только хозяина слушается? А как потом происходит эмуляция, чем оно всё проверяется? А то любопытство просто жесть уже %) игры ещё нет даже в общих чертах, а уже затягивает похлеще большинства головоломок %)
Да, там легко все собирается. Я как раз планирую сделать проект быстрого старта. Статью напишу и выложу на гитхаб все, но его пока готовлю. Ссылку на гитхаб постараюсь пораньше дать.
Батник запускает эмулятор и скармливает ему свежий скомпилированный бинарик. И я все проверяю уже в эмуляторе (там есть монитор всей памяти, пошаговая отладка, но этим всем мало пользовался, не очень это все удобно + надо знать адреса всех переменных).
:: Запускать компиляцию из директории проекта такой командо:
:: start /b %cc65bat% <имя_файла_без_разширения>
:: %cc65bat% - имя системной переменной, котороая хранить путь к этому батнику (можно назвать как удобно)
@echo off
set name=%~1
:: Переводит в .asm
:: -Oi - опитмизатор
cc65 -Oi %name%.c --add-source
:: Из .asm компилирует объектный файл
ca65 reset.s
ca65 %name%.s
ca65 asm4c.s
:: Линкует файлы
ld65 -C nes.cfg -o %name%.nes reset.o %name%.o asm4c.o nes.lib -m %name%.map
:: -C указывает использовать конфиг файл
:: ld65 -C nes.cfg -o %name%.nes reset.o %name%.o nes.lib
del *.o
start D:\Programs\Emulator\fceux-2.6.4\fceux.exe %name%.nes
А сколько у нас, кстати, всего памяти и как именно её маппер организует (к вопросу выше)? А то там, по ходу дела, карта даже 64×64 клетки не факт, что влезет.
16 страниц по 16 килобайт. Но там еще 100500 мапперов. Но страницу больше 32 килобайт сделать не получится. В видеопамяти страницы по 8 килобайт. Но в моем маппере там ОЗУ вместо ПЗУ.
Код аутентично лежит в ROM или часть можно в SRAM держать? А то там явно нужно перед началом каста править некоторые адреса и константы прямо в самом коде.
Там общее адресное пространство (если не считать видеопамять) для программ и данных (фон Нейман). Я думаю, что так можно сделать. Не вижу ограничений, но надо пробовать. Я раньше думал об этом, но так и не попробовал. Как попробую, то отпишусь.
И про текущее состояние моего движка.
Эксперименты с Брезенхемом я прекратил, так как точные точки пересечения с ним не получить, если шагать по целым клеткам. + мне не нравится необходимость находить конечные точки луча.
В итоге я решил вернуть к более стандартному подходу. Координаты теперь будут 16-битные (8 бит на целую часть и 8 бит на дробную часть (положение внутри клетки). Ты к этому же параллельно пришел :).
Карту я оставил 16 на 16, но буду помнить, что каждая клетка делится на 256х256 подклеток. Это дает быстрые вычисления, не сильно хуже, чем раньше.
Луч теперь будет стрелять через нахождение первого пересечения с соседней клеткой (это всего 1-2 умножения и пара сложений), а следующие пересечения находятся обычным сложением.
Итого выстрел одно луча будет не сильно хуже моего Брезенхема (меньше всякой оперативной возьни), а то можно и сравняется (тоже есть перспективы по оптимизации). Но тут я точно получу нормальную картинку + точное позиционирование игрока на клетке.
Длину луча буду считать через таблицу косинусов и синусов (это еще одно умножение).
Немного не нравится, что приходится использовать тангенсы (ты тоже отметил, что функция неприятная в использовании). Но без них проблематично получить быстрые формулы.
До рендеров пока не дошел, движок еще не дописан, поэтому показать нечего. Сейчас доделываю таблицы и вношу правки в свою библиотеку дробей. Без дробей все-таки обойтись у меня не получилось, целочисленный Брезенхем я не победил, картинка от него мне не нравится.
Оценку по ФПС сейчас дать не могу, но кажется, что в 2 кадра я должен уложиться. А где 2 кадра, там и 1 кадр. 70 умножений должны успеть обработаться за 2 кадра. А заполнение видеобуфера можно будет сильно ускорить. Но пока надо просто заставить работать движок хоть как-то.
Спасибо за вашу библиотеку. Использую вашу библиотеку в своих играх, все работает отлично.
Статья тоже отличная, познавательно)
Не ожидал, что и в тетрисе 6502. Особенно забавно, что я тоже пишу игры под 6502 для денди) 6502 повсюду.
Это ведь ещё и эпл 2 и коммодор 64, жаль только у всех слишком разная обязка и весь софт пропитан хаками, портировать проблематично.
Тогда да, я думал вы написали обертку поверх стандартной.
Да, знаю исторических блогеров, которые продают платный доступ к текстам.
Это может работать, если блогер набрал большую аудиторию на массовых ресурсах, а потому перевёл кор-аудиторию к себе на закрытые каналы.
А с нуля я не представляю как можно набрать аудиторию по узкой теме на текстовых статьях. А если они ещё и платные будут с самого начала, то шансов ноль.
Перехватчик нажатий вызывается каждый раз при нажатии клавиши? Не слишком это замедляет выполнение программ? Хотя, если это работа с текстом, то все равно, наверное.
Интересно, что я тоже последнее время думаю про клавиатуры для древние компов. Мне нужно сделать клавиатуру для ДВК 3 и для рк86-подобного компа.
Ещё мечтаю о БК и спектруме (любой вариации), но пока на это все жалко денег). А с MSX совсем грустно в этом плане.
Поэтому я стараюсь лишний раз комментарии на хабре не писать. Вероятность критического урона слишком велика)
А свои статьи не забрасывайте, темы интересные)
До 22го было не сильно лучше, а так да, согласен. Бытовуха убивает творчество.
Спасибо, интересно)
Я тоже за тексты, начинал с текстового блога 13+ лет назад. Чтение по диагонали мастхэв, видео никогда не заменит статьи.
А решил перейти на ютуб, так как понял, что тексты больше никому не нужны. Медийный тупик.
На счёт "мёртв" не уверен, но интересных статей стало меньше (по крайней мере для меня).
Раньше была куча очень необычных авторских программных и железных проектов, типа дампера Кластера (первое, что приходит в голову).
А сейчас 90+% ленты - это обзоры фреймворков и новых версий софта + какие-то очень специфические бизнес кейсы. А хочется читать про самодельный комп на пневматике или про обсерваторию на балконе:)
Но я и сам виноват в упадке, слишком редко пишу статьи. Затянулся проект с 3д движком для денди, но его точно добью. Будет интересно.
PS: Прошу прощения у своих подписчиков за долгое отсутствие, все проекты в работе. Спасибо, что не отписываетесь)
А мне казалось, что прикладывание к статье видео-версии и видео-иллюстраций наоборот вызывает негатив у читателя.
Всегда с некоторым стеснением прикрепляю видео и жду осуждения.
Да. Надеюсь этим летом добить демку с плавной камерой. Но пришлось переписывать весь движок.
256 для фонов и 256 для спрайтов
Можно купить новодельную денди и посмотреть топологию осовремененую под микроскопом. Но там не чистый 6502.
Только сейчас прочитал комментарий.
Вчера перед сном размышлял о движке и архитектуре таблиц. И забавно, что придумал примерно тоже самое, что ты описал в этом комментарии (код нормально тоже не смотрел ещё).
Тоже пришёл к мысли, что тангенсы вообще не нужны. Сделать таблицу тангенс*младший байт координаты даже проще. Можно ещё можно два младших разряда координаты убрать и получим в 4 раза меньшую таблицу, что хорошая экономия.
Только лучи около 0 и 90 градусов нужно отдельно обрабатывать.
Про 128 лучей согласен, логично. И хорошая идея про ориентацию по таблице из фиксированной стартовой позиции, но тут придётся вручную на асме писать. Сс65 туповат, он каждый раз будет считывать указатели в регистры. Но это мелочи.
И я примерно придумал как быстрое формирование стен сделать с дробными тайлами по краям. Если брать шаг тайла в 2 пикселя, там не так много вариантов высоты стен.
И со статус баром проблем нет. Можно выводить его спрайтами или использовать параллакс.
С полигонами тоже скорее всего многое заменится таблицами, ибо сцена всего 64х64 пикселя. Но там все надо доделать пока без оптимизации.
Код буду изучать, работа большая проделана, спасибо. Попробую его портировать. Прикрепи его на странице на итч.ио, так удобнее будет.
Но свою версию тоже постараюсь добить все равно, как минимум как учебное пособие для следующей статьи. Может просто в итоге не буду закапываться в оптимизацию, но посмотрим.
Библиотеку дробей я изначально писал, так как у СС65 они вообще никак не реализованы, только целые типы. Поэтому пришлось писать библиотеку. Там у меня псевдо дроби по факту, ибо они с фиксированной точкой, арифметика целочисленная.
Значит у тебя сейчас лучевая шестеренка на 128 зубьев? А как же рывки? Я наоборот перешел на таблицы с 1024 значений на 360 градусов, шаг 0.35 градуса. Значения в таблицах можно было сделать однобайтными, но проще знак хранить в таблице, чем генерировать его через свитч. Но вычисления, связанные с тангенсом, в однобайтные числа как закладывать? Тангенс около 90 градусов может быть +- 160.
Итоговый рендер выглядит отлично, меня такой результат устроил бы вполне. И туда не так сложно добавить имитацию освещения и добавить косые тайлы. Осталось собрать все в кучу и добиваться приятного вращения камеры и хотя бы 30 фпс.
Я тоже планировал заменять таблицами места, где число умножается на тангенс. Расстояние тоже можно было бы скорее всего загнать в чистые таблицы (на основе косинусов или корней не особо важно, суть одна).
Этот вариант тоже рассматривал, я рассчитываю угол наклона полигона, чтоб определить его видимость, можно привязать к нему и освещённость.
Но частоту кадров всё-таки хотелось бы побольше) Тем более выяснилось, что я могу перерисовать всю сцену за один кадр.
А можно скрин с рендером последней версии? Самому лень все собирать и возиться с ДосБоксом.
Теперь по вопросам из предыдущего поста (забавно использовать комментарии для подобной переписки, для случайных зрителей тема обсуждения выглядит очень странно скорее всего :) .
Нет, я использовал целые байты. Половинки байт не использую из-за медленного считывания, да и хватает мне оперативки пока.
Увеличится время на заполнение буфера для последующего его вывода в видеопамять. Работа с массивами через переменные-индексы очень плохо работает. Смещения желательно хардкодить (зато смещения могут быть 16-битными, ибо шина адреса 16 бит).
Стек хранится в общем адресном пространстве, его можно хранить в любых адресах и даже выбрать его размер можно, если не хватает оперативки. Обычно его делают 256 байт, но видел и 128 байт. Он нужен чисто для вызова функций, чтоб не потерять значения регистров. Для другого его использовать особо смысла нет. Скорость чтения одинаковая.
Чуть быстрее работают первые 256 байт оперативной памяти (из-за удобных адресов). Все остальная оперативка работает на 1-2 такта медленнее в зависимости от команды.
Мой маппер переключает первые 16 килобайт ROM. Вполне можно подключать и другие микросхемы ПЗУ, но счетчик команд будет указывать на последний адрес, а переключении всей ПЗУ он попадает неизвестно куда. Это нужно будет учитывать. Что такое я хочу сделать, когда буду картридж с ОС делать. Будет ПЗУ с загрузчиком (считывание дискет, магнитофона и т.д.). Когда загрузчик отработал и сложил программу в отдельную ОЗУ (которая будет работать как ROM), процессор переключится на подготовленную ОЗУ вместо загрузчика-ПЗУ. Самое простое делать это через RESET-прерывание, но можно спаять и аппаратное пользовательское прерывание в картридже (по-умолчанию оно не используется, висит в воздухе).
Да, там легко все собирается. Я как раз планирую сделать проект быстрого старта. Статью напишу и выложу на гитхаб все, но его пока готовлю. Ссылку на гитхаб постараюсь пораньше дать.
Батник запускает эмулятор и скармливает ему свежий скомпилированный бинарик. И я все проверяю уже в эмуляторе (там есть монитор всей памяти, пошаговая отладка, но этим всем мало пользовался, не очень это все удобно + надо знать адреса всех переменных).
16 страниц по 16 килобайт. Но там еще 100500 мапперов. Но страницу больше 32 килобайт сделать не получится. В видеопамяти страницы по 8 килобайт. Но в моем маппере там ОЗУ вместо ПЗУ.
Там общее адресное пространство (если не считать видеопамять) для программ и данных (фон Нейман). Я думаю, что так можно сделать. Не вижу ограничений, но надо пробовать. Я раньше думал об этом, но так и не попробовал. Как попробую, то отпишусь.
Эксперименты с Брезенхемом я прекратил, так как точные точки пересечения с ним не получить, если шагать по целым клеткам. + мне не нравится необходимость находить конечные точки луча.
В итоге я решил вернуть к более стандартному подходу. Координаты теперь будут 16-битные (8 бит на целую часть и 8 бит на дробную часть (положение внутри клетки). Ты к этому же параллельно пришел :).
Карту я оставил 16 на 16, но буду помнить, что каждая клетка делится на 256х256 подклеток. Это дает быстрые вычисления, не сильно хуже, чем раньше.
Луч теперь будет стрелять через нахождение первого пересечения с соседней клеткой (это всего 1-2 умножения и пара сложений), а следующие пересечения находятся обычным сложением.
Итого выстрел одно луча будет не сильно хуже моего Брезенхема (меньше всякой оперативной возьни), а то можно и сравняется (тоже есть перспективы по оптимизации). Но тут я точно получу нормальную картинку + точное позиционирование игрока на клетке.
Длину луча буду считать через таблицу косинусов и синусов (это еще одно умножение).
Немного не нравится, что приходится использовать тангенсы (ты тоже отметил, что функция неприятная в использовании). Но без них проблематично получить быстрые формулы.
До рендеров пока не дошел, движок еще не дописан, поэтому показать нечего. Сейчас доделываю таблицы и вношу правки в свою библиотеку дробей. Без дробей все-таки обойтись у меня не получилось, целочисленный Брезенхем я не победил, картинка от него мне не нравится.
Оценку по ФПС сейчас дать не могу, но кажется, что в 2 кадра я должен уложиться. А где 2 кадра, там и 1 кадр. 70 умножений должны успеть обработаться за 2 кадра. А заполнение видеобуфера можно будет сильно ускорить. Но пока надо просто заставить работать движок хоть как-то.