Люди устали от нейрохрючева и откровенного копирайта, а за определенной живой персоной следить куда интереснее - вот и весь секрет почему самостоятельные авторы популярнее условного seleditor.
Интересный пример: помимо Хабра я публикуюсь на дтф. Там сейчас идет борьба с тем самым нейрохрючевом и, как бы забавно не было, на игровом сайте мои статьи про ретро гаджеты часто выходят в топ-3 за сутки, хотя по меркам дтф это ближе к оффтопу. Люди не всегда понимают о чем речь, но им нравится формат повествования и то, что как автор я существую за пределами статьи и могу щитпостить, тем самым генерируя локальные мемы.
Спасибо за теплые слова! Сейчас дописываю загрузчик программ так, чтобы .text у нас был в SRAM, а ресурсы можно было подтягивать с помощью API BIOS'а.
Плюс надо дописать нормальную поддержку CXX, т.к у меня до сих пор нет инициализации статических переменных, а там может и контейнеры допишу по типу фиксированных пулов.
Всё не так просто. Чем больше рисуемые спрайты и чем больше их общее число - тем сильнее будет падать производительность. Мне лично больше нравится подход с фреймбуфером т.к памяти хватает с головой :)
Если что, в RAM будет только код игры, в ROM будут ресурсы и благодаря XIP мы сможем без проблем их адресовать с помощью виртуальной файловой системы или другого механизма дескрипторов.
Можно немного схитрить и сделать виртуальный фреймбуфер с разрешением x2 ниже (120x120, само собой картинка будет апскейлится обычным Nearest-фильтром, зато фреймбуфер будет занимать всего 28КБ), тогда блиттинг будет всё таким же дешевым и памяти расходоваться будет меньше. При этом сама логика DMA будет сложнее: необходимо будет выделить отдельную память под один настоящий сканлайн, где мы будем по прерыванию от DMA по факту передачи сканлайна "растягивать" виртуальную строку фреймбуфера в настоящую. Примерно вот так:
Можно оптимизировать ещё дальше и сделать обработку прерывания ещё немного быстрее.
Также у контроллера есть аппаратная поддержка палитровой графики и 8-битного пиксельформата, если для игры хватает 256 цветов (как на SEGA) - то можно использовать и его, тогда фреймбуфер будет весить 57КБ.
Если же подойти к реализации вывода графики с учётом опыта предков, то в целом можно формировать сканлайны и на лету - тогда по памяти вывод графики будет "бесплатным", однако DMA использовать не выйдет. Но это всё равно очень хороший способ для, например, Atmega328P :)
Напишу свои наблюдения.
Люди устали от нейрохрючева и откровенного копирайта, а за определенной живой персоной следить куда интереснее - вот и весь секрет почему самостоятельные авторы популярнее условного seleditor.
Интересный пример: помимо Хабра я публикуюсь на дтф. Там сейчас идет борьба с тем самым нейрохрючевом и, как бы забавно не было, на игровом сайте мои статьи про ретро гаджеты часто выходят в топ-3 за сутки, хотя по меркам дтф это ближе к оффтопу. Люди не всегда понимают о чем речь, но им нравится формат повествования и то, что как автор я существую за пределами статьи и могу щитпостить, тем самым генерируя локальные мемы.
так что самое главное - коннект с аудиторией.
У меня зрение -4, так что у меня есть аппаратное сглаживание :)
Спасибо за теплые слова. В нативе все равно получилось бы шустрее плюс можно написать Stopwatch и оптимизировать конкретные участки кода!
Спасибо за теплые слова! Сейчас дописываю загрузчик программ так, чтобы .text у нас был в SRAM, а ресурсы можно было подтягивать с помощью API BIOS'а.
Плюс надо дописать нормальную поддержку CXX, т.к у меня до сих пор нет инициализации статических переменных, а там может и контейнеры допишу по типу фиксированных пулов.
Не с той ноги встал, прошу прощения
Пока думаю об этом, но в целом возможно
Да я и не сносил, просто поныл
Дельту чуть позже добавлю, как и фиксед апдейт
Ну как я и думал, статья слишком примитивная для Хабра. И зачем я вообще сюда что то продолжаю писать и публиковать
Как считаю нужным, так и пишу. Не нравится - есть чс)
Называйте фирмварью, как вам удобно.
Всё не так просто. Чем больше рисуемые спрайты и чем больше их общее число - тем сильнее будет падать производительность. Мне лично больше нравится подход с фреймбуфером т.к памяти хватает с головой :)
Если что, в RAM будет только код игры, в ROM будут ресурсы и благодаря XIP мы сможем без проблем их адресовать с помощью виртуальной файловой системы или другого механизма дескрипторов.
Если очень-очень условно, то PPU так и работает.
Мурмулятор классный проект, но это ведь не значит что нет смысла придумывать что-то еще? :)
Пока не думал об этом. Но я хочу поковырять аппаратный клон GBA, слышал там эмулятор
Да, это факт. Но для NES/GB всё не так сложно: можно сделать и аппаратный эмулятор с чтением PPU/ROM прямо с картриджа
Аппаратный эмулятор это как Мурмулятор?
Для этого нужно реализовывать релокации, а это тема чуть более сложная.
Можно немного схитрить и сделать виртуальный фреймбуфер с разрешением x2 ниже (120x120, само собой картинка будет апскейлится обычным Nearest-фильтром, зато фреймбуфер будет занимать всего 28КБ), тогда блиттинг будет всё таким же дешевым и памяти расходоваться будет меньше. При этом сама логика DMA будет сложнее: необходимо будет выделить отдельную память под один настоящий сканлайн, где мы будем по прерыванию от DMA по факту передачи сканлайна "растягивать" виртуальную строку фреймбуфера в настоящую. Примерно вот так:
Можно оптимизировать ещё дальше и сделать обработку прерывания ещё немного быстрее.
Также у контроллера есть аппаратная поддержка палитровой графики и 8-битного пиксельформата, если для игры хватает 256 цветов (как на SEGA) - то можно использовать и его, тогда фреймбуфер будет весить 57КБ.
Если же подойти к реализации вывода графики с учётом опыта предков, то в целом можно формировать сканлайны и на лету - тогда по памяти вывод графики будет "бесплатным", однако DMA использовать не выйдет. Но это всё равно очень хороший способ для, например, Atmega328P :)
С таким функционалом - нет. Но андроид кнопочные телефоны можно хакнуть