Новый принцип устранения клешинга

[Lethargeek]

Можете схематично изобразить, как будет 48к атрибутов 1х1 транслироваться частями в адресное пространство z80.

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

Разница имеется. При установке цвета через порт, цвет устанавливается всегда ДО вывода пикселей. Если же мы имеем область атрибутов, как в спектруме, то мы можем задать цвет пикселей, как до, так и ПОСЛЕ их вывода на экран. И это "после" сильно усложняет ситуацию, т.к. очень трудно понять к каким именно пикселям должен относиться новый цвет, а какие нужно не трогать, чтобы избежать клэшинга.

Нету разницы. До вывода выбираем "атрибут индекс такой-то" и рисуем сколько нам надо пикселей. После перезаписью одной ячейки внешней видеопамяти заменяем цвет у этого атрибута. Все пиксели с этим атрибутным индексом перекрасятся.

Спековские атрибуты - очень специфичный случай. Хотя бы тем, что индекс принимает только 2 значения - INK и PAPER. У вас тоже самое, два значения?

НЕТ. Мы сейчас о цвете ПИКСЕЛЕЙ говорим. ОДИН ПИКСЕЛЬ Спека принимает только ОДНО значение. Специфична у Спека лишь привязка атрибутов к координатам (что для совместимости, для части атрибутов, может обеспечить видеокарта).

Смотрим на экран, считаем, загибая пальцы Если честно, долго пытался вспомнить игру, где меняется порядок вывода спрайтов, помню, что была, но названия так и не вспомнил.

Изометрических таких должно быть немало. А вообще иногда не то что порядок спрайтов меняется, а количество и состав объектов генерируется случайно.

Раскладывать на сколько есть, по возможности группируя одноцветные спрайты.

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

Ничего не делать, такое как раз идеально подходит для слоев.

см. выше

А вот тут засада однозначная, причем для любого метода. Из-за однобитности буфера информация о принадлежности пикселей объектам теряется и фиг определишь, где правильно покрашено, а где клэшинг. Переделывать под прямой вывод в экран, возможно с использованием двойной буферизации.

Не для любого. Буферу тоже можно выделить окно в памяти видеокарты, где храниться будут цветные пиксели, а при переброске буфера в экран Спектрума видеокарта перебросит свой цветной буфер в свой цветной экран. Группами по 8 пикселей синхронно с z80 по условию попадания адреса последнего чтения в окно буфера и адреса последней записи в окно экрана. Схему можно развивать дальше (говорил уже об объединении по байту-маске полноцветных пикселей из двух адресов-источников)

[Advertiser]

[inozemcew]

Для простоты адаптации и совместимости с 48К нужно что-то простое. Нет смысла придумывать новые видеорежимы итд.. итд.. никто под них писать не будет.

Однозначно поддерживаю. Нафиг не нужны все эти монстры со встроенным искусственным интеллектом. 4 слоя без всяких масок и прочего выпендрежа - для начала с головой. А дальше уже видно будет.

Например обычный экран с адреса #4000, а теневой с #0000.

Теневой тоже с #4000. И не один, а пара-тройка. Переключать значением в порт. Для "теневых" экранов PAPER прозрачный. Это собственно и предлагалось.

Что тут непонятного-то?

Непонятно, насколько это будет похоже на спектрум.

ОДИН ПИКСЕЛЬ Спека принимает только ОДНО значение.

Нет. Он таки принимает ДВА значения - 1 и 0, INK и PAPER. По этому индексу и выбирается из байта атрибута (который является такой себе мини-палитрой на два цвета) конкретное значение цвета.

До вывода выбираем "атрибут индекс такой-то" и рисуем сколько нам надо пикселей.

Т.е. как бы вместо отдельных слоев, для каждого пикселя храним номер слоя, в который он попал бы, если бы были слои. Правильно я вашу мысль понимаю?

Изометрических таких должно быть немало.

Вот с изометрическими движками, как-то знакомство не сложилось. Очень приветствуются ссылки на внутреннее устройство таких движков.