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

[Reobne]

я извиняюсь, что у вас значит "хаос-ксор" ?

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

Но чаще всего выглядит это хаотично, и такую дребедень также можно устранить. Но только если это дребедень, а не так и было задумано.

В идеале мог-бы быть инструмент, который позволил бы хакеру_адаптации, даже не знать ассемблера. Он должен включать в себя эмулятор. Запускаем в этом эмуляторе игру. Потом, когда на экране какой-то клешинг, ставим на паузу. Тыкаем на экране в пиксель, который должен-бы быть не таким, по нашему мнению. Программа_адаптптель предлагает несколько вариантов устранения. Выбираем подходящий, или вздыхаем что не получилось. Тестируем. Сохраняем. И готово - новая версия игры!

[NEO SPECTRUMAN]

но уберётся этот (см. рис. позиция 2)

а за рисование атрибутов фона поверх спрайта ГГ у меня всегда было желание расстреливать
(особенно доставляет когда это inc 0 paper 0)
мне намного больше нравится квадратный ореол вокруг

[Lethargeek]

Для атрибутов 1х1 нужна область в 48кб. Куда это впихуется, чтобы было "как на Спеке.", те отображенным в адресное пространство Z80?

"КАК на Спеке" - это не "в адресном пространстве Z80", а в адресном пространстве видеокарты
для совместимости со старым софтом только часть атрибутов для z80 нужно отображать

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

ну и атрибутный точно так же, какая разница? одним битом от неатрибутного отличается

Т.е. надо понимать, что речь у вас идет не об атрибутах в спектрумовском смысле (т.е. два цвета, которые выбираются в зависимости от значения бита пикселя), а об индексированном цвете и палитре? Иначе эта ваша фраза просто не имеет смысла.

"атрибуты в спектрумовском смысле" - частный случай индексированного цвета

Нет, код который меняет приоритет спрайтов, уже есть в игре. Приделать автоинкремент номера слоя при выводе спрайтов, ничуть не сложнее фиксированного вывода номера.

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

Зачем нам может понабиться такое, и в чем тут трудность?

так вообще-то игры часто работают - рисуют в буфер долго, медленно и печально, а потом всё (относительно) быстро перебрасывают в экран
а в чём трудность - см. вопросы выше

[Totem]

Здесь тоже создают "чудовище" со слоями? устраняют клешинг в старых играх?
поясните, используется ли в играх, просто отключение ROM? И использование RAM0? 16К коту под хвост.
Игра игре рознь! Платформер на одном экране и аля "черный ворон" или "вера", где присутствует перерисовка всего игрового кадра со скролом "мира", грубо говоря нужно "залить фон" одним тайлом, или вырезать кусок, лучше и проще чем блиттер тут нет для 8 бит.

[goodboy]

пока вы фантазировали я уже устранил клешинг

[NEO SPECTRUMAN]

пока вы фантазировали я уже устранил клешинг

с клешингом было лучше

[Advertiser]

[inozemcew]

для совместимости со старым софтом только часть атрибутов для z80 нужно отображать

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

ну и атрибутный точно так же, какая разница?

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

"атрибуты в спектрумовском смысле" - частный случай индексированного цвета

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

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

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

что делать, если спрайтов вдруг оказывается больше, чем аппаратных слоёв?

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

а что делать, если в кадре обновляются не все спрайты, или вовсе разные в разных кадрах?

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

игры часто работают - рисуют в буфер долго, медленно и печально, а потом всё (относительно) быстро перебрасывают в экран

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

[bigral]

Здесь тоже создают "чудовище" со слоями? устраняют клешинг в старых играх?
поясните, используется ли в играх, просто отключение ROM? И использование RAM0? 16К коту под хвост.
Игра игре рознь! Платформер на одном экране и аля "черный ворон" или "вера", где присутствует перерисовка всего игрового кадра со скролом "мира", грубо говоря нужно "залить фон" одним тайлом, или вырезать кусок, лучше и проще чем блиттер тут нет для 8 бит.

Из темы в тему переползает "таже самая концепция" которая сводится к "сделать из спектрума sprinter/tsconf". Но эта идея давно реализованна и имеет минимальный интерес наряду с другими "прибамбасами" типа GS, 16c и т.д. Так вот минусы таких доработок:
1. несовместимость с zx стандартами (только <1% софта их поддерживает);
2. абсурдная "гипертрофированность" железа (требуются частоты и\или интеграция в несколько раз больше чем у zx, что уже сравнимо с amiga, segamd, snes; для сравнения у zx-a 99% софта не требует частот более 14Mhz от того железа на котором оно работает);

А теперь про идею "чудовище" которую "создают":
1. требует минимального хака софта, сравнимого с хаками типа "изменение кнопок управления", "озвучка ay музыкой", "руссификация", "добавление cheat-ов", "взлом защиты от копирования" (т.е. того же самого что 99% софта уже успешно прошло);
2. использует то же поколение электронных компонентов что и zx (т.е. НЕ выглядит как "инородное тело");

[Titus]

2. абсурдная "гипертрофированность" железа (требуются частоты и\или интеграция в несколько раз больше чем у zx, что уже сравнимо с amiga, segamd, snes; для сравнения у zx-a 99% софта не требует частот более 14Mhz от того железа на котором оно работает);

Такая гипертрофированность вполне оправдана при одном условии, имхо, если в код игры не надо будет вмешиваться (или практически не надо), и где перерисовки, т.е. раскраски, потребует лишь графика. Словом, направление примерно как у ZX-Poly.

[Lethargeek]

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

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

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

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

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

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

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

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

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

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

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

см. выше

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

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