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

[AlexG]

Любое изменение программы - условно равносильно написанию новой программы.
Поясню мысль: чтобы вставить что-то куда-то - надо найти свободное место.
значит в то место где нужно вставить OUT надо будет вставить CALL на свободное место где будет исходный кусок программы (как минимум 3 байта) + OUT + RET.
Есть другой вариант: дизасм всё и вся, и сборка обратно.
Кто эти будет заниматься ?
Чисто аппаратными средствами (без изменения программы) не добиться результата...
Посему "новый вариант устранения клешинга" - это фикция.
Реально борьба с клешингом - это создание физически другого компьютера и написание нового софта. Другого способа нет и не будет.
Кому "нужен" такой "новый вариант устранения клешинга" ?

[Advertiser]

[null_device]

AlexG, насколько я понял, целью и было:

создание физически другого компьютера и написание нового софта.

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

[Reobne]

AlexG,

Любое изменение программы - условно равносильно написанию новой программы

Весьма условно.

[inozemcew]

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

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

Основное, что мне в этом методе "не нравится" - он не обеспечивает "честного" режима цвет-на точку в пределах знакоместа.

А разве это требовалось? Суть задачи - убрать клэшинг с максимально возможной совместимостью с существующим софтом.

Любое изменение программы - условно равносильно написанию новой программы.

Вы ошибаетесь. Изменения, которые потребуется внести, ничуть не сложнее, скажем, переделки записи сохранения на ленту под ТР-ДОС.

- - - Добавлено - - -

И, вот тут мы подошли к вопросу, относительно атрибута знакоместа - яркость... как быть с ним?

А что за проблема с ним?

[null_device]

А что за проблема с ним?

На каждом слое мы имеем в области цветовых атрибутов бит яркости и мерцания. Для стандартного экрана спектрума они задаются для всего знакоместа. Как они будут интерпритироваться в вашей реализации?

Никто никуда ничего дополнительно не пересылает.

Как минимум, нужно вместо записи в одну область памяти, "щелкать" портом - переключая слои и пересылать туда данные. При этом, надо выводить ОДНОВРЕМЕННО (либо, квазипараллельно - не суть) состояние всех слоев в виде точки растра на экране (существенную часть времени, процессор спектрума, занят именно этим). Техническая реализация, подразумевает, что отрисовка всех слоева будет укладываться по тактам в процедуру вывода стандартного экрана.

[inozemcew]

На каждом слое мы имеем в области цветовых атрибутов бит яркости и мерцания. Для стандартного экрана спектрума они задаются для всего знакоместа. Как они будут интерпритироваться в вашей реализации?

С точки зрения цветности все очень просто. Смотрите, вместо того, чтобы рисовать фон, героя, снаряды, врагов на одном экране, мы рисуем фон на одном экране, героя на втором, пули на третьем и монстров на четвертом. Заметьте, объем прорисовки точно такой же, как и для одного экрана. Теперь видеокарта накладывает эти экраны один на другой, причем цвет PAPER для верхних экранов считаем прозрачным. Если мы, например в верхней плоскости имееем INK точку ярко-красного цвета - ее и выводим. Если же эта точка установлена в 0 (PAPER) - идем в слой ниже и смотрим его. Если там темно-синий INK - выводим, нет - спускаемся дальше, и так до последнего слоя, который уже обычный спековский экран.Вот и весь алгоритм работы видеоконтроллера, никаких шейдеров, процессоров и тд и тп.

При этом, надо выводить ОДНОВРЕМЕННО (либо, квазипараллельно - не суть) состояние всех слоев в виде точки растра на экране (существенную часть времени, процессор спектрума, занят именно этим).

Нет. Ничего не выводится квазипаралельно. Слои нужны только, чтобы для каждого спрайта можно было задать приоритет и выбрать, в соответствии с этим приоритетом, атрибут для его пикселей установленых в 1. Больше ничего не меняется. Никаких "точка своим цветом" и т.п., только устранение клэшинга с минимальными усилиями.

[null_device]

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

Попробуйте отрисовать подряд восемь стандартных экранов спектрума. А потом - представаить, как это будет реализовано в железе.

С точки зрения цветности все очень просто.

Тоесть, для отображения всей палитры надо уже 16 слоев. Как-то многовато...

[AlexG]

Почитайте тему
http://zx-pk.ru/threads/21462-bystra...2013-quot.html

и хватить "лохматить бабушку" (с)

[Raydac]

Почитайте тему
http://zx-pk.ru/threads/21462-bystra...2013-quot.html
и хватить "лохматить бабушку" (с)

у этой "видеокарты" спектрум затеряется в fpga в качестве ненужного довеска, а тут тема насчет клешинга у спектрума всеж

- - - Добавлено - - -

Напрашивается квадробуферизация.

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

[AlexG]

В той теме
"Видеокарта "Meteor Graphics" позволяет путем небольших изменений в коде игры устранить клешинг атрибутов главного героя (ГГ)
"
Это разве не новое железо с небольшими изменениями в коде ?
Перечитайте первое сообщение и с десяток последних темы ТС.
Как говорится "найди десять отличий" от Видеокарта "Meteor Graphics"

А выглядит это так: ТС хочет запантетовать то что "придумал" zst.
Ещё скажите что я не прав...