Ну естественно, вещественными лучше не пользоваться, они ж там программные. Не пойму, правда, какая связь sincos и заливки. Как пример, вот на что способен был ARM2 8мгц в двухмерных игрушках без какой-либо аппаратной помощи:
www.youtube.com/watch?v=t4hfPKWM4Mk

Doom в уменьшенном примерно до gba-шного размера окошке сносно шевелился на 386DX40. По моему опыту, уже самые первые армы примерно в 2+ раза эффективней по тактам были. Так что в «ужасном качестве» я склонен виноватить кривые ручки (программистов Дума, компилятора, или разработчиков железа геймбоя). В архимедовских демах, вон, даже воксельный ландшафт бодро бегал:
www.youtube.com/watch?v=bLdpCIfOqmw (с 17:50)

можем наглядно увидеть, что пиксельные видеорежимы 16-мегагерцовым ARM-ом GBA заливаются довольно медленно и их реальное применение в играх очень сильно ограничено

Что-то здесь не то. Такой арм, навскидку, должен в кадре успевать залить такой маленький экранчик несколько раз. А тут либо компилятор сосёт, либо дикие задержки доступа к видеопамяти. Во всяком случае, причина явно не в 16 мегагерцах.

ты же начал там «не более 20» (то есть 20 — «вниз»)
надо нам работать над интонацией)))

Я не вижу ничего плохого добавить PC XT с гергулесом, CGA или даже EGA в то же самое компо. Поэтому я написал 20 бит. Да, машина посильнее спектрума, но не настолько, чтобы сразу складывать руки. Вот 80268 меня уже беспокоит, и это как раз тот случай, где шина адреса та же что и в 8086.

XT были и на 6мгц 286, и на 8мгц турбо-8086 — потому и должны учитываться все вместе заодно с AT 286. Ну да, базовый пц дохловат, но никому же не приходит в голову отделить поделки на 8080 до 2мгц от спектрумов и прочего на z80. Другое дело, если классы полностью сводить вместе из-за недостатка работ. Но не так, чтобы при всё-таки раздельных компо конфигурации кочевали туда-сюда по желанию левой пятки организатора.

В этом случае, к примеру, TI-99/4a, который медленнее Спектрума и у которого (в TMS9900) шина адреса 16-разрядная, окажется в не oldskool (если я правильно понял мысль).
Тогда уж логичнее было бы брать по адресуемому напрямую (без банков и пр.) пространству. Если оно не больше 64к, то oldskool

ну я написал же «только процессорной», а она у 99 такая же, как у спектрума

Этот аргумент можно попытаться облагородить, сказав что-то вроде «любые 8-битные платформы или 16-битные платформы с не более чем 20-битами адресной шины».

Но ЗАЧЕМ? Что изменит данное дополнение? Если ничего не изменяет, то оно ЛИШНЕЕ. И без него прекрасно быкашка уходит в корзину к спектрумам и комодам, а ранний пц — к амигам (так ему и надо)) и атари-ст (к которым довольно близок).

Просто так уж получается, что всего одна характеристика хорошо коррелирует с общими возможностями платформ.

итого три класса:
до 16 (или 20) бит (zx, c64, bk, ti-99 итд)
до 32 бит (ранние пц, амиги, st, даже архимеды)
от 32 бит (более поздние пц, амиги итд)
(вот последний класс надо ограничить сверху либо годом, либо условием скалярности cpu)

Кроме того, есть некоторое число 16-битных платформ, которым в компо с настоящими зрелыми 16-битными платформами ловить нечего (типа БК или Intellivision или даже PC на 8086 с CGA или EGA). Обрезать 16-битные платформы по дате будет, мне кажется, невозможно: БК-0010 выпускались с 1983 года (но для них никто демо не пишет), PCшки на 80286 выпускались с 1984 года, EGA — это октябрь 1984, Atari 520ST — это апрель 1985, Atari 1040ST — это март 1986, Amiga 500 — это январь 1987, VGA — это апрель 1987. БК-0011, для которого собственно все и пишут демы в наше время, вышел только в конце 1989. Придётся писать список, и приписывать в конце к списку «если что-то не попало в этот список, пишите в редакцию, мы подумаем».

а не появлялось мысли назначать битность платформы по (только процессорной) шине адреса?

Совершенно символично то, что именно эта работа, в которую вложено, наверное, самое минимально возможное количество усилий, заняла третье место.

возмущён! предлагаю отменить голосования нахер, а победителя выявлять по затраченной на рисование картинки работе (в джоулях)

недолюбливаю соника, слишком быстрый при слишком ограниченном поле зрения;
но трип-репорт прочесть было интересно!

а разогнавшись, вылететь с экрана секунд на несколько — это и в оригинале такое было?

«релиз без бинарного релиза» для меня звучит примерно как «вода без водорода»

хотя нет, глянул пдфку, таки кода оказалось 16k (что как-то многовато)

так ведь в ответах в первой цифре не только код, вот я и решил уточнить

вторая цифра — это вместе с графикой в формате конфы, или прямо в ромах графику заменил?

так в итоге, сколько там оригинального кода и сколько адаптационного?

Зебру треплют не шакалы, а ликаоны.

и так неплохо получилось))

Что, вот прям ни разу такого не было, что начинали глючить старые демки после добавления новых фич, если что-нибудь по таймингам не сошлось? Надо быть ну очень уж осторожным. С блиттером вообще об этом можно не думать. Как однопоточность против многопоточности.

А зачем мне фон читать при выводе спрайтов (если нет каких-нибудь эффектов полупрозрачности)? Фон я буду восстанавливать одним махом в начале цикла отрисовки нового кадра. Кэш тогда сработает эффективно.

Память блиттеру действительно желательна побыстрее, но вот размер не обязательно нужен больше. Можно ведь и распаковывать на лету (а скорость распаковки непостоянна, что для блиттера значения не имеет). Да и просто собирать из кусочков, особо спрайты, часть которых в разных фазах анимации совпадает.

По решениям имею твёрдое мнение, что сперва удобство, потом изящество. В современной обстановке, само собой, и при проектировании нового (втиснуться в старое железо — особый случай).

Обоснуй.
Если речь о таком развитии, как у «быстрой видеокарты метеора», то конечно ))

Нет, вообще. Чхать на тайминги развёртки и разрешение, на локальные заторы на шине данных. Не поломаешь совместимость с прошлыми фичами. Узлы разных стадий работы с блоком можно заменять и дорабатывать независимо. Добавлять новые форматы блоков, дисплей-листа. Вся система в целом «свободнее»

Чтение бэкграунда обязательно.

При наложении — необязательно, если гранулярность доступа равна пикселю. При восстановлении — фон может оказаться сплошным/градиентом/закэшированным «тайлом» или текстурой. Схему кэша, кстати, тоже проще пилить отдельно и без особенной оглядки на старый софт. Впрочем, это отдалённая перспектива.

Блиттер. Вторая стадия болезни. Изобретатель уже осознает, что сил Z80 на новый режим не хватит. Предлагается концепт «видеокарты» на бюджетной FPGA с максимальным количеством SRAM (потому что работать с дешевой и большой SDRAM автор не умеет). «Видеокарта» должна аппаратно двигать тонны пикселей по командам Z80. На этом мысль автора обычно тоже обрывается.

Kek. На этом обычно обрывается (если вообще не проходит мимо) мысль религиозно верующих во спрайты. Основное преимущество блиттера как раз в том, что развивать его намного удобнее. И еще, если уж для спрайтера всё свалено в одну кучу, то и список операций для блиттера также можно сократить до двух пунктов «чтение и запись видеопамяти» (кстати, первые два вида чтений необязательны).

Дальше будет больше матчасти и меньше богословия, я надеюсь. Железяка интересна, хоть и неспектрум :p

СХОРОНИЛ