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

[Titus]

3) Отрисовка фона по знакоместам [RamboIII - бочки на полу] Нужно вводить дополнительную информацию.

А какая проблема с фоном по знакоместам?

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

Решается ZXInno_0.1

Ссылка есть?

[Reobne]

Ссылка есть?

ZXInno_0.1

А какая проблема с фоном по знакоместам?

Про бочки на полу там же на картинке, и сразу далее мы обсуждаем.
Готовая(запечёная) графика, сразу с клешингом.

[Titus]

Про бочки на полу там же на картинке, и сразу далее мы обсуждаем.
Готовая(запечёная) графика, сразу с клешингом.

Мне кажется, для всего, кроме XOR'а замечательно подойдет подход типа ZX-Poly.

[Lethargeek]

Не требует. Вряд ли единицы мегабайт RAM можно считать большим аппаратным ресурсом.

...на колу мочало, начиная сначала
а повышенная частота памяти, чтобы в кадре их успеть прочитать - это не больший аппаратный ресурс?
или неведомая схема "внутреннего z-буфера" - это не больший аппаратный ресурс?

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

Только для нескольких удобных для схемы случаев. Причём в их удобстве надо убедиться, копаясь в логике.

Что значит худшего качества?

Цветов меньше, фон и спрайты только двухцветные.

Картинка, в рамках поставленной задачи,

Кем, как именно? Если как:

Задача - устранить клэшинг в существующих программах с минимальными усилиями и без перерисовки графики.

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

может быть одна - как в Спектруме, только без клэшинга.

Без клэшинга - уже значит не "как на Спектруме". Если речь об обязательной двухцветности объектов - то с какой стати?

Польза от расширений, софт для которых будет написан "потом" - имхо, сомнительна.

Не "потом", а польза блиттера несомненна и в деле ускорения старых игр.

Ну уже упоминавшийся RamboIII, да остальные игрухи от Andrew Deakin - Athena, RenegadeIII, Adams Family etc. тоже сделаны на этом принципе.

Это мы еще посмотрим, насколько точно.

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

Нет, невыгодно. "Таким образом" получаем процессорное время в КАЖДОМ игровом кадре на КАЖДЫЙ спрайт = SaveBack + PutSprite + RestoreBack. Если же "чистый" фон заранее единожды создан в буфере, получается только PutSprite + RestoreBack (с незаметной ОДНОКРАТНОЙ задержкой только при переходе в новый экран). Что экономичнее для процессора?

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

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

А разворачивать фон из тайл-мапа, даже по размеру объекта - процессор просто не успевает.

И с чего бы вдруг процу-то не успевать? При не совсем уж мелких объектах расход времени на поиск нужных тайлов будет меньше времени SaveBack. Расход памяти также будет скорее меньше - не нужны буфера для фона под каждым спрайтом.

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

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

Вы упорно не замечаете простой вопрос: "как стереть спрайт не перерисовывая всё?"

Ответ был таков же, как и вопрос, но кое-кто, похоже, его не понял

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

Сферическая процедура в вакууме. На практике может оказаться совсем не так. Ну да ладно, можно и такой пример обсудить.

Теперь у нас есть экранные слои. Что надо поменять в данном алгоритме? Всего две вещи. Перед процедурой устанавливаем активным слой 1. Дальше, таже самая процедура читает нули из экрана (потому, что стандартное изображение находится в 0м слое, а в 1м слое кроме изображения курсора мыши у нас никогда ничего не бывает) , как и раньше, сохраняет эти нули, думая, что это фон, в тот же самый буфер, и рисует спрайт стрелки, точно так же, как и раньше, даже не подозревая, что он попадет не на фоновое изображение, а в пустой слой №1. Всё, устанавливаем активным 0й слой и возвращаемся в основную программу

...даже не подозревая, что прерывание нагадило в слой №1 с непредсказуемыми последствиями или вместо нужных данных прочло нули

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

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

А я вообще не буду адаптировать алгоритм и старый код совсем никак не буду менять))) Адаптировать следует конфигурацию (не путать с прошивкой) видеодевайса к этому коду. Достаточно сообщить видеокарте основные ключевые точки графпроцедур, типо: здесь читается полоска фона, здесь маска спрайта, а здесь обратная запись байта фона с кусочком спрайта. Фактически сообщаем смысл сигналов системной шины при выполнении процессором команды с этого адреса. Реализовать возможно по-разному, например, как массив кодов внутренних (немногочисленных и простых) команд видеокарты, осуществляющих аналогичные операции над полосками полноцветных пикселей и внутренним аналогом атрибутов. Основную часть массива заполнить "нопами", а команды загрузить перед игрой спецпроцедурой-конфигуратором (можно даже до загрузки самой игры).
Вот на что ресурсы ПЛИС потратить имеет смысл, вместо имитации пачки Спектрумов!

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

Мне кажется, для всего, кроме XOR'а замечательно подойдет подход типа ZX-Poly.

Атрибутные эффекты?.. но это мелочь, основные недостатки zx-poly и подобных решений - нерациональность и неудобство расширения-улучшения.

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

Скрытый текст

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

[свернуть]

[Totem]

Зачем? ну зачем переделывать старые добрые игры на ZX, их не хватает в цвете на других платформах? откуда они портированы, Вы по сути делаете 4 шага назад и 0 вперед.

[Titus]

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

Где именно? В бесконечных диалогах с Иноземцевым трудно выцепить суть) Нужно отдельное описание)

[Lethargeek]

Где именно?

ну, ё-моё...

Скрытый текст

только что

чуть выше

Скрытый текст

перед "--- добавлено ---"

[свернуть]

[свернуть]

[Raydac]

zx-poly и подобных решений - нерациональность и неудобство расширения-улучшения.

забачно, zx-poly и "ему подобные решения" единственные кто сохраняет обратную совместимость и дает программеру возможность самостоятельно делать решения (в отличии от решений видеокарт где мы дадим мегажелезо и протокол, а делать всё будет видяха гдет внутри) и при этом упрекается в неудобстве расширения-улучшения ну дак спектрум вообще то это платформа которая вообще не предназначена к расширению-улучшению еще на старте, это её фича, что там всё расширение не благодаря, а вопреки

[Lethargeek]

забачно, zx-poly и "ему подобные решения" единственные кто сохраняет обратную совместимость

И в чем же (якобы) "несовместимость" других решений?

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

Какой-то бессмысленный набор слов. Что такого "несамостоятельного" в управлении девайсом по протоколу? Чем оно принципиально отлично от управления процессором Z80 через протокол его машинного языка (вместо, скажем, непосредственного контроля над его четырёхбитным АЛУ)))

и при этом упрекается в неудобстве расширения-улучшения ну дак спектрум вообще то это платформа которая вообще не предназначена к расширению-улучшению еще на старте, это её фича, что там всё расширение не благодаря, а вопреки

А разъём Expansion фирменного Спектрума, стало быть, назвали так шутки ради?

[NEO SPECTRUMAN]

А разъём Expansion фирменного Спектрума

для поключения переферии
принтер, джойстик...

врятли он для видеокарт задумывался...