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

[coffee]

It's coming soon!

[coffee]

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

Часть 1.
Итак, как обещал попытаюсь написать по возможности объективную рецензию на многолетний труд нашего ТС. Приготовьтесь, букв будет много. Сразу оговорюсь что я получил от него не весь материал, а только один раздел и то не полный (как написал мне ТС). Остальное попытаюсь домыслить. Моя задача осложняется тем что я связан обещанием хранить в секрете подробности его концепции, хотя честно говоря (спойлер!) я там никаких интересных подробностей не нашел. На всякий придется умолчать почти обо всем, а вам просто доверится моему мнению (имея в виду что другие разрабы, кто так же ознакомлен с данным трудом не дадут мне соврать).

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

Особенности

- Может использоваться в модели 48k(*);

2.4 Простейший вариант Swap можно использовать в клонах. В фирменных машинах, думаю, тоже можно использовать. Вопрос в том, что в фирменнлй машине нельзя будет использовать палитру.

А в преамбуле присланной мне работы говорится о

возможности расширения графических характеристик бытового компьютера ZX-Spectrum

Т.е. автор дает понять, что он собирается использовать свой новый видеорежим на стандартном ZX-Spectrum и его клонах (возможно после какой-то доработки?). Кроме того, в работе есть момент с упоминанием Ulaplus:

Совместная работа с Ulaplus ещё больше расширяет возможности видеорежима... на экране могут присутствовать одновременно 64 цвета из палитры в 256 цветов

Таким образом я делаю вывод, что автор считает, что видеорежим может быть реализован на системах, построенных на базе Ulaplus. Мое мнение - это фантастика. Все очевидно, незачем объяснять почему, просто цитирую что пишут сами создатели ULAPlus:
"- Does it remove attribute clash?
- No."
Для реализации антиклешинга на стандартном ZX-Spectrum и его клонах придется заменить практически все, даже память динамическая не подойдет, надо менять на статику.
Не хочу обижать, но автор явно не силен в разработке "железа" (читая тред это ясно), а оно для решения задач антиклешинга требуется серьезное, намного сложнее самого спектрума. Отсюда мой вывод по первой части: аппаратная компонента проекта скорее всего на нуле и без сторонней помощи вряд ли когда будет реализована. Но может он все соберет на эмуляторе? Продолжим...

- 2. Программная часть. Первая мысль, когда прочитал о принципе формирования изображения, посмотрел картинки: вроде неплохо, но что-то все слишком просто и дополнительной памяти мало требуется, что-то не так. Но отвлекшись на мелочи - автор очень подробно и внешне убедительно пишет про выбор цвета для фона, спрайта, все эти операции And, Or, Xor и честно сказать я не сразу понял главное - метод ТС "не взлетит" совсем. Здесь полная катастрофа... Он работает только когда спрайт находится в границах знакомест 8х8 как по горизонтали, так и по вертикали. Любое смещение на 1-7 пикселей в любом направлении вызовет цветовые артефакты, т.е. часть объекта будет окрашена цветами фона и наоборот часть фона - цветами объекта. Визуально тот же клешинг, но в виде окантовки объекта будет на экране. Если бы автор потрудился разобрать листинг отрисовки спрайтов хоть в одной игре, то ему давно бы стало ясно, что не работает его метода. Но он явно не вникал в подобные мелочи, просто нарисовал свои красивые картинки и убедил себя, что все ОК.
Я могу еще много писать, что совсем не проработана версия с теневым экраном (потребуется 2 комплекта буферов), что для многих игр переписать код отрисовки спрайта будет очень затруднительно в виду того что все регистры и стек участвуют в работе и делать что-то дополнительно на слое маске и слое цветов.атрибутов просто не на чем - ресурсы проца заняты. Про то что просядет производительность автор сам понял. Про то что придется переписать не одну процедуру отрисовки спрайта, а все последующие процедуры, затрагивающие картинку в экране или в теневом буфере - будет для него сюрприз. Много что еще можно написать, но зачем добивать и так неживой проект?
Но если вы меня спросите - есть ли хоть что-то полезное/верное в подходе автора к проблеме? Ответ - да. Он додумался (как в прочем и другие до и после него) до слоя маски. Без нее антиклешинг не пойдет. Но от верной мысли в правильном направлении до конечной реализации в железе или в эмуляторе - дистанция огромного размера. Там как говорится дьявол в деталях...Я первую версию антиклешинга (где Валли "парил" над игрой) сделал всего за неделю, над второй бился наверно пару месяцев (правда попутно решая и др.задачи). А у автора ведь по сути нет ничего, кроме идеи слоя маски и ложной идеи атрибутов цвета спрайта. Он за 5 лет прошел всего один шаг. Raydac на самом деле прав:

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

Может еще через 5-10 лет…

- 3. хоть у нас и не чемпионат мира по фигурному катанию, но рискну поставить ТС оценку за артистизм: 6.0.
Почему? Треду 5 лет, он в топе с 850+ т. просмотров. Какой интерес и популярность! В какой-то степени он способствовал запуску успешного проекта ULAX (ребята в этом же треде начали раскручиваться). Ну и что, что он сам не имел в запасе ничего стоящего? Сколько людей заинтересовал интересной идеей. Да, автор не силен ни в проектировании железа, ни в программировании как на Z80 так видимо и на PC (иначе почему бы протестировать идею на эмуляторах?). Но интерес к теме он угадал и умело развил его. Надеюсь и дальше тред не затухнет. Есть над чем работать.

Часть 2 (с проектом ТС никак не связанная, это видение АК, основанное на моем скромном опыте).
Возможно я многих расстроил в связи с фиаско проекта ТС, они может ждали, когда он выйдет в паблик. А вдруг старый спектрум заиграет по-новому? Не судьба. В качестве некоторой компенсации "помогу" интересующимся и обрисую возможный алгоритм реализации антиклешинга на FPGA/эмуляторе на примере игры Three Weeks In Paradise. Сразу оговорюсь что сам я сделал не так, ибо мне надо было уместиться в намного более скромных ресурсах: оригинальный Z80 и CPLD (на порядок слабее чем FPGA, к тому же без встроенной памяти). Но тем не менее алгоритм вполне рабочий. Но само собой потребует серьезной работы для реализации. Итак, поехали… Упомянутая игра использует теневой однобитовый буфер на 4kB, содержащий 2/3 экрана – (панель инструментов не копируется), находящийся прямо за атрибутами по адресу 0x5B00, см. картинку в аттаче. По ходу игры, подпрограммы визуализации персонажей и объектов отрабатывают одна за другой, создавая нужную картинку в этом буфере. К слову сказать, он линейный и при копировании в основной экран спектрума выполняется перестановка строк. Как я уже сказал, буфер однобитовый и на нем отрисован задний фон и по очереди накладываются объекты. За цвет отвечает стандартная зона атрибутов. Отсюда собственно весь клешинг и проистекает. Мы хотим, чтобы Валли был красивым, многоцветным или хотя бы желто/черным, но не смешивался с фоном, но цвета задает слой атрибутов и Валли делается "хамелеоном" или "маляром". В качестве решения можно добавить однобитовый слой маски, на котором фиксируется персонаж - его абрис и слой/слои цвета персонажа (минимум один для желто/черного Валли, несколько для многоцвета). Допустим мы позволяем игре визуализировать все объекты как раньше, но дополнительно размещаем Валли на слое маски и на специальных цветовых слое/слоях. Как это сделать пока умолчим. Что делает теперь видеоконтроллер при сканировании? Во-первых, на каждом знакоместе он как всегда считывает байт пикселей и байт атрибутов. Во-вторых, дополнительно считывает байт маски. Допустим наличие фрагмента тела Валли в знакоместе представлено в виде 1, а его отсутствие 0. Тогда при нулях, мы ничего больше не считываем, а отображаем только пикселы и атрибуты как в обычном режиме спектрума. Но при наличии хотя бы одной 1 в байте маски, мы считываем дополнительно байты с цветовых слоев Валли. Логику коммутации и сборки выходного потока на ЦАП я описывать не буду, она очевидна для тех кто делал свой клон и вообще для специалистов. Таким образом на одно знакоместо мы имеем до 4 (или больше, если спрайт многоцветный) байт на считывание, плюс надо конечно обслуживать процессор (у меня он в приоритете ибо даже на 14 МГц должен работать с 0 W.S.). Таким образом стандартная динамическая память не успеет обслужить запросы. В случае с дабл-сканом (VGA, HDMI) темп выдачи данных еще в 2 раза быстрее (14 вместо 7 МГц). Короче желательна статическая память с циклом не хуже 70нс. Но если у вас экранная память сидит внутри FPGA, то вы вообще в шоколаде, там и скорость хороша, и разрядность любая, да и вообще все можно разделить на разные блоки и работать параллельно. Да, кстати этих экранов нужно пару комплектов - пока заполняется данными один, на отображение работает второй. Переключение производится в момент копирования теневого экрана в нормальный.
С видеоконтроллером вроде разобрались. Теперь перейдем к заполнению слоев нужными данными. Это довольно сложный и трудоемкий процесс, который можно осуществлять разными способами. Начиная с чисто софтовых (силами Z80), до продвинутых, с аппаратной поддержкой, когда аппаратные и/или программные ресурсы FPGA сами запускают дополнительные операции с памятью, внося куда надо нужные данные. Не буду расжевывать смысл этого, кто готов к подобному, тот сам догадается. А что нужно вносить, рассмотрим на примере слоя маски. Процедура отрисовки Валли (адреса 0xE269-0xE34D - листинг дизасма можно вытащить из SNA-файла игры) на первом этапе работает с фоном и маской. Три байта маски загружаются в регистры Z80 и циклически сдвигаются на 0-7 бита (сдвиг задается младшими 3 битами X-координаты, что по адресу 0xF6B4). В итоге они занимают уже 4 байта. В оригинальной процедуре они делают побайтовую операцию AND с фоном (фон предварительно сохраняется для последующего восстановления). Вот перед этим моментом надо успеть сохранить сдвинутую маску в нашем слое маски. Чем хороши эмулятор и FPGA со встроенным "Z80" - так это тем, что все регистры доступны и срисовать их куда надо много легче чем из живого Z80, можно сделать даже не ломая оригинальную процедуру. Далее процедура отрисовки спрайта аналогичным образом загружает и сдвигает пиксели спрайта. Здесь дело попроще, можно просто перенастроить вывод с теневого экрана на свой. Если у вас Валли многоцветный, то работки будет побольше. Надо иметь в виду, что блок спрайтов с Валли (начинается на 0xE71C и далее 18 картинок/фаз движения по 192 байта каждая, 24х32 пикселя, формат: сначала 3 байта маски, потом 3байта пикселей) подвергается операции зеркалирования (процедура по адресу 0xE0FE), когда Валли меняет направление движения. Если Валли у вас монохромный, то вам это безразлично - игра сама зеркалит маски и пиксели всех спрайтов. Но если Валли у вас мноцветный, то опять придется подумать, как все это реализовать.
Но это еще не конец. Надо перебрать все процедуры после отрисовки Валли до момента копирования теневого экрана в основной. И отследить кто может "испортить" нашего Валли. А это всякие столбы, трава по пояс, которые ближе к нам и должны перекрывать Валли. Т.е. мы должны отслеживать их отрисовку и в случае совпадения положения экране - корректировать слой маски - обнулять байты в этом месте. Тогда видеоконтроллер покажет в этом месте фон, где действительно нарисованы трава или столб. Эти объекты хороши тем что они расположены строго по знакоместам и можно не заморачиваясь просто обнулять целый байт маски. Но еще есть мелкие предметы (всякие котелки, тапки и проч.), которые отрисовываются как спрайты со своей маской, а они любой формы и к примеру в дырочку под ручкой котелка должен просвечивать Валли. А это значит нужна более сложная операция при отрисовке: сначала считываем данные слоя маски, потом обнуляем те биты что закрываются котелком (перемножаем маски) и пишем байт назад в слой маски.
Звучит это все громоздко и сложно для неподготовленного человека, но общем довольно стандартно. Ребята из ULAX даже поставили обесклешку на поток. Думаю, что у них реализация отличается от вышеприведенной (да и у меня она отличается).

P.S. Наверняка некоторые напишут, ну и что нового ты тут написал, все это известно, смотри тот тред или этот. Отвечу в шутку: я кроме данного треда (да и то не полностью) ничего не читал (иногда читать выходит дольше чем сделать самому). А всерьез: мой метод работает, а ваш? Знаю, что работает ULAX и ZX-Poly. Остальным критикам предложу сначала сделать самим и показать, как работает.
P.P.S. Стирать в сообщении ничего не буду. Ничего секретного я не написал, но если это кому-то поможет войти в тему, то задача будет выполнена.

[reddie]

Да уж, теме пять лет, а результата ноль. Изложу свое видение ситуации, у меня оно слегка иное.
Сперва конкретный ответ: на исходном Спектруме никогда не будет антиклешинга, это заложено аппаратно. Чтобы его убрать, нужен паяльник (изменения схемы).

Для реализации антиклешинга на стандартном ZX-Spectrum и его клонах придется заменить практически все, даже память динамическая не подойдет, надо менять на статику.

Неа. Есть варианты даже со слабой динамикой типа РУ5-РУ7, самый очевидный - нарастить битность. То бишь память идет бутербродом, как делали в наших клонах 128-го,
только читается (видеоданные) одновременно, а не попеременно. Два байта - уже хорошо, если очень извратиться, можно хоть четыре слоя поставить.
Только практического смысла в этом мало, проще реально использовать статику с хорошим быстродействием. Там времянки до 20нс и ниже есть. Либо "бутер" из двух статик.
Таким макаром можно до 16млн цветов дойти, только смысл от них на нашем слабом Z80...

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

Насколько понял, предлагался кастрированный вариант антиклешинга. То есть он как бы остается, просто впечатывается спрайт по маске.
Соответственно, убирается клешинг на стыке спрайта и фона, но не на самом фоне/спрайте. Вариант, но лишь половинчатый.

Насчет реализации маски можно поступить куда проще, но я свое время, размышляя над улучшением графики Спектрума, хотел сделать иначе.
Тут пущусь в легкий флуд, но для понимания нюансов идеи необходимо описать мой вариант графического режима.
В изначальном варианте я подумывал сделать двухрядное чтение видеопамяти, что уже дает разом 2 байта на такт.
Попутно принимаем турбо-режим как стандарт для расширенной графики, причем разогнаны и проц, и память. Это уже вчетверо больший объем чтения, чем сейчас.
Стандартный Спектрум читает видео через такт, байт данных + байт атрибутов. На восемь точек получается 2 байта, или 2 бита на один пиксель.
Подходим к самому важному: можно отойти, наконец, от схемы "пиксели отдельно, атрибуты отдельно" и кодировать каждый пиксель своим набором бит.
Соответственно, стандартный комп может выдавать до 4х цветов на пиксель с минимальными переделками схемы, но цвета будут жестко заданы, это стандартные RGB+черный.
Именно такой видеорежим реализован, например, в БК-0010. Там же не просто от балды решили сделать только 4 цвета, да еще синий+зеленый+красный.
Все исходило из возможностей железа, тех самых двух бит на пиксель (развертка БК в целом совпадает со Спектрумовской, частоты чтения видеопамяти те же).
Если же мы наращиваем битность (2 ряда микрух) - уже имеем 4 бита на пиксел, 16 цветов. Турбо-вариант памяти - 8 бит, 256 цветов. Каждый пиксел 256 цветов, Карл.
Однако тут возникает другая проблема. Путем несложной математики получаем размер экрана 256х192=48 килобайт на экран (при 256/пиксел) либо 24 к (16/пиксел).
Для немощного Z80 это слишком накладно, извращения со страницами памяти тут помогут лишь частично. В БК ровно та же проблема: экран размером 32 килобайта,
потому что там разрешение 256х256 при 4х цветах на точку. Для слабых процов и, что тоже важно, 16-битной шины адреса это приговор.
Да, можно разбить даже экран в 48 кило по страницам. Выходит вполне удобно, по 16 кило, или треть экрана в страницу. Но усложняется работа с графикой на стыке третей.
Впрочем, для несложных графических построений такое решение бы вполне устроило. Для выплюнуть картинку и любоваться ею - вообще отличный вариант.

Теперь вернемся к маскам. Если кодировать каждый пиксел своим цветом, резко вырастет потребление памяти как экраном, так и спрайтами, в разы вырастет.
Но речь сейчас именно о реализации маски и, по возможности, быстрой реализации. Ну, быстрого вывода с маской. Тут можно сделать довольно просто.
Под маску выделяется отдельный цвет из возможного набора (16/256 в нашем случае, да хоть 16 млн, не суть важно). То есть, теряя один цвет, мы получаем маску.
Как это реализовать железно? Довольно просто, применяя логику XOR. Даже на рассыпухе получится не очень громоздко, буквально три-четыре корпуса.
При таком способе не нужно отдельно хранить маску, она уже содержится в спрайте, как некий аналог альфа-канала в текстурах "нормальных" компьютеров.
Главное же преимущество такого подхода - процедуре вывода не нужно париться с маской. Она просто кидает данные, а железо отсекает их по маске.
То есть мы просто выводим спрайт, как массив данных, путем пересылки. Байты маски игнорируются и не записываются в память.

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

А вдруг старый спектрум заиграет по-новому? Не судьба.

[Raydac]

ZX-Poly основан на том же принципе, но ограничен 16ю стандартными цветами

у ZX-Poly со Spec256 разница всеж, у последнего идет обычная программа и в параллель 8 виртуальных процессоров на каждом шаге выполняют программу со своей памятью и версией проги и выводится именно их результат компонуясь в индекс 256цветной палитры, но после шага все они синхронизируются по процу который выполняет обычный неизмененный SNA файл, при таком можно безболезненно даже залезть и покрасить исполняемый код, но на реале работать не будет никогда, а у ZX-Poly 4 проца не связанных между собой и там надо быть сильно аккуратнее в раскраске,но из всех раскрасок у единственного вроде как есть в довесок к раскраске режим без раскраски но позволяющий просто изменением фонта сделать 512 на 384 в утилитах

[Lethargeek]

на исходном Спектруме никогда не будет антиклешинга, это заложено аппаратно. Чтобы его убрать, нужен паяльник (изменения схемы).

на исходном Спектруме никогда не будет дисковода, это заложено аппаратно. Чтобы его убрать, нужен паяльник (изменения схемы)

хотя, погодите-ка...

[reddie]

Если это был намек на то, что новые режимы могут быть присобачены через ZX_Bus - почему бы и нет.
Но родным Спектрумовским железом это уже не будет. Давайте сразу тогда GTX 1060 присобачим. Ненуачо.
Beta Disk шел отдельно, в наших клонах он врос в плату. Возможно, это минус и привязка к TR-DOS. Но назад пути уже нет.

[Advertiser]

[Dexus]

Если через ZX_Bus такое и будет, то видеовыход будет именно с нее, потому как в видеоконтроллер через это расширение ну никак не влезть. А коли так, то туда можно и RPI всондалить, с HDMI выходом, и OpenGL графикой (аля универсальный VDAC3). Клешинг останется на старом видеоконтроллере.

[Lethargeek]

Но родным Спектрумовским железом это уже не будет

так и бетадиск не "родное", раз не от Синклера

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

как и кемпстон, который тоже у многих "врос"

[reddie]

Началось... OpenGL, HDMI, прочие навороты. Напоминает идеи, витавшие тут на форуме, реализации каких-то доработок (уже не помню, о чем шла речь) на внешнем контроллере STM32 или типа того. Вам самим-то не смешно? Лепить устройство для компа с процессором в десятки-сотни слабее этого устройства. Давайте тогда сразу перейдем на Ардуино и ассемблер его процессора, в чем проблемы-то? Я скажу, в чем. Мы закостенелые ретрограды, не желающие учиться новому. Мы лучше посидим, покодим под Z80, а недостающие фичи, так и быть, реализуем более мощным железом. Вот только смысл такого подхода? Древний проц, являющийся самым слабым местом, будет тянуть всю систему на дно.

В моем видении, все дополнительные фичи могут считаться родными, если реализованы на элементной базе соответствующей эпохи. Применительно к Спектруму - никаких FPGA и STM, только православная рассыпуха, только хардкор. А то получаются у нас присобаченные через задницу контроллеры HDD, СF, МР3-плееры и все остальное. Вот только Z80 им уже не нужен, он остался как шильдик, что это типа Спектрум, а не что-то более крутое.

[Raydac]

Древний проц, являющийся самым слабым местом, будет тянуть всю систему на дно.

один будет, а несколько не будут