Не прошло и ста лет, как я обнаружил, что исходники демо выложены на GitHub:
github.com/restorer/zxspectrum-lo-fi-motion-2020
Большое спасибо автору! Надеюсь это поможет другим невнимательным читателям вроде меня!

Вот с чего я окончательно прифигел — так это с того, что на 2:01:00 Джон Ромеро играет в Marsmare: Alienation: youtu.be/tGlK9wnPvJw
:D

Демосцена на картинке выглядит ещё хуже, чем Covid19. А Dihalt-2021 как из морга :))

Чет я протупил. Проблема с hypr.ru все-таки на стороне retroscene.org должна решаться. Вроде решил.

Понял в чем проблема. На hypr.ru самоподписанный сертификат. И ресурсы оттуда реджектятся.
Я просто перед этим разрешил этот сертификат, поэтому ничего и не заметил.

Обновил в личном кабинете, стало ок.

Аватар потерялся.

зафиксирую ссылку на предоставленные игры, а то найти её почти нереально :)

Marsmare: Alienation — огонь! Прошёл и отзыв написал.

быстрее бы декабрь, холодно :)

Потрясающее комьюнити. Отличные знания.

Добавил в лист.

Господа, пройдемте и проголосуем за работы!

«интереснее» в том что от стандартных корок, которые не тянули, зато имели свои инструменты вроде ЯВУ и трансляторов ассемблера, пришлось перейти к собственной архитектуре которая обеспечивала приличную пропускную, но потребовала написать и трансляторы и компилятор и отладчики. Это все очень интересно, любительство оно такое в чем то беспощадное и требовательное, азартное :)

Суть же телодвижений с спрайт-тайтлами, ну в какой то момент показалось что имея аппаратное наложение слоев друг на друга, можно наслаждаться отрисовкой в квази-фрейм буфере (можно так группировать тайтлы/спрайты что в области графического представления, в области спрайтов — будете работать с массивом небольшой размерности, скажем 256х128 или 256х256. И это казалось что ли убер экономией видеопамяти, казалось конечно… Ну аппаратное наложение слоев конечно сильно экономило время и такты, но вот отрисовка в области спрайтов какой либо анимации… все равно вылилось в полноценный фрейм-буфер, который из блочного ОЗУ ПЛИС само собой переполз в SDRAM.

свежак
2020 Kazan Dacha Meeting (3.11-6.11)
photos.app.goo.gl/DwxHmyi3Vx4AB3pGA

Я познал Makefile. Ну ладно, ок, не совсем еще познал. Как минимум, талмуд стоило бы прочитать.

В общем, все части демы, сколько бы их не было, собираются и пакуются одним сценарием. Чтобы добавить сборку еще одной части, просто добавляю её имя в перечисление. Ну и там контроль наличия файлов, чтобы каждый раз не пересобирались.

gist.github.com/akanyuk/7d98ffeeac1316b42d10917f208b85e2

Да, я прочёл. Ближе всего идея тумана похожа на нюковский запилятор, но применённый не к графике, а напрямую к коду.

Хех, «интереснее» — это в смысле преодоления собственноручно созданных себе трудностей? И зачем на полноценную корку вешать функции очень примитивного блиттера, какой в чистом виде получился бы быстрее и проще?

Что касается аппаратных тайлоспрайтов, это же древнее решение для древних же проблем, которые давно отпали сами собой (то есть тормознутости и малых объёмов видеопамяти). Никаких разумных причин применять это решение сейчас при создании нового псевдоретро железа не вижу. Смысл есть только в ускорении относительно старого готового железа новой прошивкой (дендиконфа)

Да все отлично описали! Особенно пункт б) автоскролинг реализованный на счетчике адреса чтения данных спрайта со смещением — классика, там по сути делать ничего не надо, пиши смещение и весь экран горизонтально или вертикально скролируется. Но :) хотелось чего то очень продвинутого и универсального, без заморочек, настолько быстрого что бы можно было писать в ЯВУ, даже без оптимизации — и в итоге для нас это оказался clear render для frame buffer. Рискну предположить почему так, потому что читать про преодолевание трудностей это одно — здорово, очень интересно, испытываешь кураж прошедшего головоломное приключение человека и гордишься им. Однако читая ты не можешь оставить без анализа те трудности которые пришлось преодолевать другому и заранее закладываешь себе дорожку без них. С одной стороны — красивый хак, с другой — универсальность и избежание хака. Ну это так мысли в слух, возможно я не прав :)

Ясно. Классические аркадно-консольные архитектуры решали все такие проблемы методично ровно по линии меньшего сопротивления:
а) обновлять VRAM можно только во время VBlank
б) слой(и) фона аппаратно скроллируется «с проворотом» так что скроллерам надо лишь раз на 8 пикселей прокрутки обновлять одну полоску тайлов фона(ов)
в) спрайты это отдельный фон из независимых объектов (отчего были всегда лимиты на количество спрайтов отображаемых в одной строке)
г) цвета палетризированы в два этапа — в плитке фона или спрайте есть селектор одной из нескольких разных палитр отчего информация о цвете еще сжимается.
Таково как бы классическое противостояние между Tile/Sprite Engine и Framebuffer render.

Таки нашел, глубоко в историю ушло :) Если мне опять же память не изменяет то тут 6809, и конечно с одним единственным танком он справляется. Танк состоит из 4 спрайтов. Все в одном слое, видео с наложением слоев не нашел, только фото монитора. Видно что на один такой примитив да успевает отрабатываться.

Демо вращение гусениц в 4 спрайтах