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

[Reobne]

Smalovsky, Извини, твоя тема называется "Новый принцип устранения клешинга". Мы обсуждаем поиски нового принципа устранения клешинга. Вроде всё сходится.

[Advertiser]

[inozemcew]

вместо дешифратора поставить микросхему памяти, в которую можно загрузить "палитру" управляющих сигналов

Можно. Можно даже просто взять 4-8 битовых планов и обычную палитру, и затем заполнив эту палитру специальным образом, получить псевдополупрозрачные слои. Именно так это делается на "Векторе". Плюс еще там 16-256 цветов на точку и т.д. и т.п. Однако, для устранения клэшинга это все лишнее. Пиксельная графика в Спеке принципиально монохромная, поэтому все эти "16 цветов на точку" без перерисовки графики просто не нужны. А перерисовывать графику, занятие таки не сильно простое. Поэтому я не хочу связываться со всякими палитрами и т.п., потому, что никто не будет

нарисовать там полноцветную картинку, а 4й слой использовать в режиме инверсии цвета или 1 цвет на знакоместо+прозрачность и прокручивать там какой-то текст не трогая никаких атрибутов.

как это показывает многолетний невеселый опыт.

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

Смотрите, тема называется "устранение клэшинга" причем очевидно подразумевается, что клэшинг устраняется в "старых" играх. И желательно с минимальными усилиями. Давайте, для примера, возьмем какую-нибудь из старых игрушек от MikroGen. Там спрайт выводится на экран по XOR и таким же образом стирается. Что нам нужно изменить, при наличии спрайтовых слоев? Достаточно перед выводом спрайта сделать OUT <номер слоя>. Теперь штатная процедура вывода прочитает нолики из области пикселей, сделает XOR со спрайтом, и вернет это дело обратно в экран, а потом запишет область атрибутов новый INK. Мы увидим спрайт поверх фона своим цветом, без клэшинга с атрибутами фона, причем, как побочный эффект, инверсии на пересечении пикселей не будет. Следующий спрайт рисуется в своем слое точно также родной процедурой. Затем, стирание спрайта. Включаем нужный слой. Штатная процедура еще раз делает XOR, стирая спрайт. Записывает на место атрибутов спрайта атрибуты фона, что теперь уже не имеет значения.
Все изменения, которые нам потребуются для устранения клэшинга - это вывести в порт номер слоя перед процедурой рисования спрайта. Т.е. модифицировать придется всего несколько байт.

Теперь ваш способ с трансляцией. Как он будет работать, и что нужно будет изменить в играх от того же MikroGen?

[Lethargeek]

Смотрите, тема называется "устранение клэшинга" причем очевидно подразумевается, что клэшинг устраняется в "старых" играх. И желательно с минимальными усилиями. Давайте, для примера, возьмем какую-нибудь из старых игрушек от MikroGen. Там спрайт выводится на экран по XOR и таким же образом стирается.

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

Что нам нужно изменить, при наличии спрайтовых слоев? Достаточно перед выводом спрайта сделать OUT <номер слоя>. Теперь штатная процедура вывода прочитает нолики из области пикселей, сделает XOR со спрайтом, и вернет это дело обратно в экран, а потом запишет область атрибутов новый INK. Мы увидим спрайт поверх фона своим цветом, без клэшинга с атрибутами фона,

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

Теперь ваш способ с трансляцией. Как он будет работать, и что нужно будет изменить в играх от того же MikroGen?

Вообще зависит от ситуации, а навскидку - добавить в процедуру лишнюю запись: прочитать экран, записать байт спрайта, поксорить, записать ксорку (при повторной записи в тот же адрес автоматически переключится набор из двух активных цветов, вторая "запись" - два прозрачных цвета, при стирании меняется очередность). В памяти Спектрума получится оригинальная ксорка, но увидим то, что получилось во внешней памяти.

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

[Reobne]

inozemcew, Вот тема по выбору портов.
Колебаться по выбору количества слоёв не конструктивно. Предлагаю взять восемь. Если будет мало - потом ещё добавить. Если много - убавить.
По поводу чтения процессором данных слоя (а не только записи в окно). Предлагаю, чтобы он читал-таки. А то как он несколько спрайтов на одном слое правильно отобразит?

Далее предлагаю сделать хоть того-же LodeRuner-а на эмуляторе, и увидеть наконец, как оно будет.

[Hacker VBI]

Reobne, это что, ещё и эмулятор переделывать???

[Reobne]

Hacker VBI, Да, это-же проще, чем сразу в железе. По моему.

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

Просто надо закончить первый вариант спецификации.

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

А пока это проект - призрак без ног.
Нужны номера портов, и точно что они делают.

[Hacker VBI]

Reobne, всё, гачи

[inozemcew]

Только спрайты ксоркой - дырявое убожество и без клэшинга. Смысла нет специально под такие игры оптимизировать, из них приличных, дай-то Клайв, если наберётся полсотни.

Ну, во-первых, про полсотни - это вы явно погорячились. Игр со спрайтами без маски знаачительно больше, чем вы насчитали, включая даже "икону" Спектрума Dizzy . Во-вторых, безмасочный цветной спрайт без клэшинга смотрится таки лучше, чем с маской и клэшингом или монохромом. Можно, например, сравнить того же Dizzy в версиях для С64, где спрайт без маски, и Спека, где есть маска и клэшинг.

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

Как же сделать работу со спрайтовыми масками максимально простой? Вспомним, как обычно делается вывод маскированного спрайта. Берется байт из экранной памяти, на него с помощью AND накладывается маска, затем с помощью OR накладывается спрайт и байт отправляется обратно в экран. Это самый типичный вариант работы с маскированными спрайтами, на него и будем ориентироваться.

Для каждого бита каждого спрайтового слоя добавим еще один бит маски. Теперь слои будут не однобитные, а двухбитные. Один бит, как и раньше, хранит пиксель спрайта, а второй используется для хранения маски. Биты маски непосредственно не доступны, а заносятся из регистра маски, для которого придется выделить отдельный порт.

Как все это будет работать? К сожалению, изменений в программы придется вносить больше. Перед выводом спрайта включаем в экранной области нужный слой. Затем переходим к процедуре вывода спрайта, читаем байт из экрана, выводим байт маски в порт, и продолжаем дальше по родному алгоритму - на считанный байт с помощью AND накладывается маска, затем с помощью OR накладывается спрайт и байт отправляется обратно в экран. При этом маска из порта маски переписывается в маску слоя, а сам регистр маски заполняется единицами.

Вот примерно так это должно работать. Для наглядности накидал небольшую схемку.


Итого, изменения в программу понадобится внести такие изменения: перед выводом спрайта нужно выставить в порт номер слоя, в который он выводится, и в процессе вывода спрайта, байт маски дополнительно выбрасывать в порт маски. ИМХО, не так, чтобы сильно сложно.

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

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

- - - Updated - - -

Колебаться по выбору количества слоёв не конструктивно. Предлагаю взять восемь. Если будет мало - потом ещё добавить. Если много - убавить.

Согласен, 8 - оптимальное количество.

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

Конечно данные слоя доступны для чтения. С точки зрения процессора, слой - он как страница памяти в 128м спеке, только переключаются слои в адресах $4000-$5aff. То что слои как-то по особому читаются параллельно видеоконтроллером и как-то накладываются в зависимости от битов и приоритетов, процессор это не колышет. Он видит слой, как обычный спековский экран. То, что вдруг при переключении слоя из экранной памяти вдруг исчезло изображение фона, процессор волновать не должно. Пусть рисует спрайты на чистом экране, теми же процедурами, которыми он рисовал их раньше поверх фона. При аппаратном наложении слоев все будет отображаться правильно.

[Lethargeek]

Игр со спрайтами без маски знаачительно больше, чем вы насчитали,

я считал не все подряд, а приличные (их % намного меньше для ранних игр)

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

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

Что делать с атрибутами, которые изменяет процедура вывода спрайта?

свой атрибут на каждый пиксель (необязательный)

[Бука]

ИМХО самый простейший способ решить проблему клэшинга был бы (тогда, в 80е) сделать аппаратное наложение двух экранов, у одного из которых один из цветов прозрачный.

Фон рисуется в одном экране, объекты в другом. Красивые динамические игры можно было бы на даже бейсике клепать.

Ессно сам клэшинг никуда бы не делся (в каждом из экранов) но вот четыре цвета на знакоместо это прикольно.

По затратам памяти лишь чуть больше честного четырехцветного (13.5 кб против 12кб). а смотрелось бы в разы лучше того же коммодора.