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

[inozemcew]

о четыре одноцветных дырявых слоя мне "с головой"

Давайте возьмем 250 слоев с масками, это меньше чем 3 мегабайта памяти.. Я не вижу тут никакой принципиально-неразрешимой трагедии.

эти пиксели всё равно находятся где-то в памяти.

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

переброской снятого заранее куска фона

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

Они тупо затирают кусок экрана сохранённым в буфере куском фона

И получаем монохромное изображение под затертым спрайтом. Или вы собираетесь угадывать, откуда процедура взяла байт для сохранения в буфере, а потом для чего прочитала байт из буфера и соответствующим образом перетаскивать параллельно пиксельные атрибуты в памяти видеокарты(а-ля Спек256)?

Я ж могу переносить и перекрашивать попиксельно любые восьмипиксельные полоски (так же, как на Спеке, и даже проще).

Это замечательно. Но нам надо перекрасить их "так как там было" до того, как там нарисовали курсор мыши. На Спеке для этого делают буфер на 16 байт (для курсора 8х16) и сохраняют "как было" в нём. Теперь по-вашему методу, 16 байт как в Спеке уже не хватит - каждый пиксель кроме состояния 0/1 несет еще и информацию о цвете. Как ее получать из видеокарты, где хранить и как потом записать обратно?

Это обещать несложно, а сделать сложно (уж сложнее мелкой правки графпроцедур)

Да что там сложного-то? Можно даже аппаратно сделать, чтобы последний записанный слой автоматически становился самым верхним. Это будет полностью имитировать последовательное наложение объектов. Хотя, на самом деле такое и не нужно. Достаточно одного байта для хранения номера текущего слоя. В начале цикла обнуляем его, а в процессе отрисовки объектов инкрементируем. Всё. Объекты будут укладываться в слои точно в порядке отрисовки, как вы и хотели.

[Advertiser]

[Lethargeek]

Давайте возьмем 250 слоев с масками, это меньше чем 3 мегабайта памяти..

а давайте вспомним, что пиксельклок PAL кадра ~ 7мгц
спросим, на какую частоту памяти в современных самоделках стоит рассчитывать
и прикинем, сколько за 1/50 секунды можно прочитать слоёв для отображения
(а еще ведь, кроме отображения, требуются такты в них рисовать)

Я не вижу тут никакой принципиально-неразрешимой трагедии.

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

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

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

Это замечательно. Но нам надо перекрасить их "так как там было" до того, как там нарисовали курсор мыши. На Спеке для этого делают буфер на 16 байт (для курсора 8х16) и сохраняют "как было" в нём. Теперь по-вашему методу, 16 байт как в Спеке уже не хватит - каждый пиксель кроме состояния 0/1 несет еще и информацию о цвете. Как ее получать из видеокарты, где хранить и как потом записать обратно?

а до конца дочитывать не судьба?

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

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

И получаем монохромное изображение под затертым спрайтом. Или вы собираетесь угадывать, откуда процедура взяла байт для сохранения в буфере, а потом для чего прочитала байт из буфера и соответствующим образом перетаскивать параллельно пиксельные атрибуты в памяти видеокарты(а-ля Спек256)?

ЧТО угадывать? Адреса всех операций видны на шине. Если Спектрум переносит байт из буфера на экран, карта может сделать то же самое у себя для соответствующей группы из восьми пикселей.

Да что там сложного-то? Можно даже аппаратно сделать, чтобы последний записанный слой автоматически становился самым верхним. Это будет полностью имитировать последовательное наложение объектов. Хотя, на самом деле такое и не нужно. Достаточно одного байта для хранения номера текущего слоя. В начале цикла обнуляем его, а в процессе отрисовки объектов инкрементируем.

И тут - опа! - вдруг закончились чистые слои (а нечистые нельзя наверх перетаскивать). Кстати, как узнать, что объект со слоя был убран полностью? а не остался, скажем, трупом или обломками (есть игра, в которой нужно буквально карабкаться по кучам тел убитых врагов)

[ZX_NOVOSIB]

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

что за игра?

[Lethargeek]

ZX_NOVOSIB, угадай (подсказка: ******* *** *******) тащемта игра довольно известная

[goodboy]

подсказка: ******* *** *******

N.. the W...

[NEO SPECTRUMAN]

Давайте возьмем 250 слоев с масками

может уже проще взять spec256

или запилить что нибудь с похожим принципом работы

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

[ZX_NOVOSIB]

угадай (подсказка: ******* *** *******) тащемта игра довольно известная

N.. the W...

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

[inozemcew]

а давайте вспомним, что пиксельклок PAL кадра ~ 7мгц
спросим, на какую частоту памяти в современных самоделках стоит рассчитывать

Понятное дело, что 250 это не 4 и не 8, мультиплексировать на ходу такое не нужно. Тут нужен внутренний Z-буфер и пересчет видимого пикселя только во время записи. Опять же ничего нереального. Единственное что нереально, это то, что нам действительно понадобятся аж 250 слоев.

И тут - опа! - вдруг закончились чистые слои

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

а я не вижу смысла в жирном девайсе для решения одной лишь частной задачи

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

сохранять текущую подложку перед выводом каждого объекта просто невыгодно,

Это как раз неважно. Масса существующих игр делает именно так.

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

Очень сомнительно, что такое вообще возможно. Во-первых буфер один, а спрайт может выводиться в любое место экрана. Надо как-то устанавливать соответствие внутрях видеокарты между буфером и положением спрайта. Я не представляю, как это можно сделать из-за того, что во-вторых, нет одной единственной операции "перенести байт из экрана в буфер". Есть 100500 способов перемещения байтов, как в одиночку, так и попарно. И все они не атомарны. Между чтением из экрана и записью в буфер может произойти куча всего, включая прерывания. Как вы будете отлавливать это на шине? Чего-то мне кажется, что если бы все было так просто, авторы Спек256 не заморачивались бы с альтернативным процессором.

[Reobne]

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

Чтобы уследить за регистрами Z80, через которые всё в основном переносится(за исключением переноса по LDI)... Так вот, чтобы уследить за регистрами Z80... , хм, надо почти полностью эмулировать Z80!

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

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

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

В общем марока.

[Lethargeek]

Понятное дело, что 250 это не 4 и не 8, мультиплексировать на ходу такое не нужно. Тут нужен внутренний Z-буфер и пересчет видимого пикселя только во время записи. Опять же ничего нереального. Единственное что нереально, это то, что нам действительно понадобятся аж 250 слоев.

да-да, снова нужно то, нужно сё, нужно что-нибудь еще...
интерес не в теоретической возможности, а в оправданности
и по сравнению с однослойной схемой получилось, что многослойная:
1) требует больших аппаратных ресурсов
2) требует больших трудозатрат при модернизации старых игр
3) принципиально выдаёт картинку худшего качества (хоть с 250 слоями)
4) неудобна для приделывания к ней полезных расширений типа блиттера
и к тому же:

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

5) ...на самом деле толком не устраняет клэшинг!

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

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

(нужно сделать новым заголовком тредика, ящетаю))

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

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

Это как раз неважно. Масса существующих игр делает именно так.

"Масса" - эта скока? Парочку примеров хотя бы? Именно чтоб процедура вывода спрайта каждый раз сохраняла кусок фона под этим спрайтом со всем там нарисованным до того, а потом перед новым кадром медленно и печально восстанавливала фон в обратном порядке? Вот ни разу не встречалось такого, в то время как наткнуться на "формирование кадра в буфере с нуля" можно часто. Наши хакеры, бывало, даже делали ускоренные версии таких игр для 128k (например, такой Thanatos я ковырял) - разворачивая цикл переброски буфера на страницу.

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

Буфера! Если буфер есть, то спрайты туда рисуют. А уж буфер после переносится на экран.

Надо как-то устанавливать соответствие внутрях видеокарты между буфером и положением спрайта.

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

Я не представляю, как это можно сделать из-за того, что во-вторых, нет одной единственной операции "перенести байт из экрана в буфер". Есть 100500 способов перемещения байтов, как в одиночку, так и попарно. И все они не атомарны. Между чтением из экрана и записью в буфер может произойти куча всего, включая прерывания. Как вы будете отлавливать это на шине?

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

Чего-то мне кажется, что если бы все было так просто, авторы Спек256 не заморачивались бы с альтернативным процессором.

Так у них была задача раскрасить игры вовсе без вмешательства в старый код и без претензий на физическую реализацию.

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

Чтобы уследить за регистрами Z80, через которые всё в основном переносится(за исключением переноса по LDI)... Так вот, чтобы уследить за регистрами Z80... , хм, надо почти полностью эмулировать Z80!

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

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

"б-же мой, да насрать" мне на прерывания! Ну, разве (чисто теоретически) кроме случаев, когда после чтения буфера прерванным кодом прерывание зачем-то тоже читает буфер. Можешь выдумать вменяемый сценарий, зачем так делать? Переброска (в over 95% игр-то уж точно) либо полностью в обычном коде, либо полностью же - в обработчике прерывания. Хотя можно и за прерываниями следить, вход-возврат на шине прекрасно видно, и выполнять какой-нибудь аналог команды EXX для нескольких регистров видеокарты (или даже в обработчике добавить код её вызова).