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

[Lethargeek]

принтер, джойстик...

и зачем им полный доступ к системной шине?

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

то есть видеосигналы на разъёме - это для принтера

[Advertiser]

[Bedazzle]

то есть видеосигналы на разъёме - это для принтера

для 3д принтера чтобы реальные модельки печатал с клешингом

[inozemcew]

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

7 МБайт/с для восьми слоев, которых по-уши хватит, чтобы расклэшить практически все - это много?

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

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

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

Только для нескольких удобных для схемы случаев.

Для остальных вариантов удобных случаев еще меньше.

Если речь об обязательной двухцветности объектов - то с какой стати?

Потому, что с перерисовкой графики уже соовсем другая песня. Добавляются такие непростые вопросы "где хранить?", "как загружать?", "как выводить?". И да, есть ZX-Poly/Spec256 и это направление, имхо лучший вариант в таком случае.

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

Как раз сомнительно, что старые игры нужно ускорять, но это дело хозяйское..

Если же "чистый" фон заранее единожды создан в буфере, получается только PutSprite + RestoreBack

Нужен отдельный буфер для хранения фона. Даже для 2/3 экрана - это 10% от имеющейся памяти.

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

С чего бы это меньше? Фон обычно хранится не сплошняком, а как список тайлов с координатами их вывода. Так просто компактнее. "Дерево, x=2, y=5", "Кустик, x=10, y=12", "Лестница, x=8, y=3, длина=10". Правда думаете, что процедить такой список совсем просто?

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

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

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

С чего бы это? Найти начало и конец обработчика прерывания и выставить там нужный слой - задача совсем не сложная.

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

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

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

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

[Reobne]

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

Это правильно. Но это только уровень общения игры, её доработки и карты. Игра остаётся фактически не тронутой и ничего не знает о карте. Конкретная доработка, в загрузчике, обучает карту работе с конкретной игрой. Карта-же способна смотреть все события на шинах и интерпретировать. Это почти ZX-prop, не хватает ещё способности в нужный момент выдать нужные данные на шину данных вместо данных из ОЗУ, и как код_операции и как данные.

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

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

Идея Lethargeek-а.
Восстановление фона через ту-же процедуру, что и рисует фон... это занятно, но ИМХО слишком специфично, либо требует серьёзной переделки большинства игр. А поскольку это специфично, это более отпугивает от начала работы. Хакеру-же нужно преодолеть некоторый порог уверенности в успехе. Побоится, что вот он вроде посмотрит, всё тайлами смотрится, всё вроде получается переделать, он проделает работу, а возле финального боса какой нибудь спецэффект не получится переделать, и он войдёт в эстетический диссонанс с проделанной переделкой, и впечатление смажется.

[Lethargeek]

7 МБайт/с для восьми слоев,

во-1 для двухбитнопиксельных (это если с маской) слоёв - вдвое больше

которых по-уши хватит, чтобы расклэшить практически все - это много?

во-2 не хватит: сходу контрпример из классики - Cybernoid, в котором по экрану мало что летают тучи мелких объектов (притом часть - с непостоянными атрибутами), так еще и бонусы падают на землю и там накапливаются

Так. Отставить. Цифра 250 была приведена чисто показать, что фантастические требования к памяти - это не соответствует действительности. Необходимости в таком количестве слоев просто нет,

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

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

"Похоже вы сами не совсем понимаете, как это можно сделать.." (с)

Кстати, а вам сколько ресурсов понадобится, чтобы реализовать соответствие "буфер - экран" и отслеживать шину?

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

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

какой "мелкой"? на дворе 2016 год!

Для остальных вариантов удобных случаев еще меньше.

"остальные" с киберноидом лучше справятся

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

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

"как загружать?", "как выводить?"

молча, блин! (вот каков вопрос, таков и ответ!) ...что конкретно кажется "непростым"?

И да, есть ZX-Poly/Spec256 и это направление, имхо лучший вариант в таком случае.

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

Нужен отдельный буфер для хранения фона. Даже для 2/3 экрана - это 10% от имеющейся памяти.

минус память, которая нужна была бы на куски фона, так что меньше (и порою весьма существенно)

С чего бы это меньше? Фон обычно хранится не сплошняком, а как список тайлов с координатами их вывода. Так просто компактнее. "Дерево, x=2, y=5", "Кустик, x=10, y=12", "Лестница, x=8, y=3, длина=10". Правда думаете, что процедить такой список совсем просто?

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

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

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

С чего бы это? Найти начало и конец обработчика прерывания и выставить там нужный слой - задача совсем не сложная.

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

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

и не надо, хватит и цвета пикселя, получаемого видеодевайсом при отрисовке (безразлично - в буфер или в экран)

В любом случае потребуется более глобальная переделка.

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

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

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

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

Это почти ZX-prop,

На самом деле лучше, чем "ZX-prop" (ZX-poly?) именно потому, что видеокарта не обязана выполнять точные аналоги оригинальных "однобитнопиксельных" команд (что позволит, в частности, бороться с глюками ксорок).

не хватает ещё способности в нужный момент выдать нужные данные на шину данных вместо данных из ОЗУ, и как код_операции и как данные.

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

Слои Иноземцева, это хорошо. Это понятно программисту и хакеру. Это требует нетрудного хакерского внедрения в программу.

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

Восстановление фона через ту-же процедуру, что и рисует фон... это занятно, но ИМХО слишком специфично, либо требует серьёзной переделки большинства игр.

Ты о чём, какой еще "переделки"? Старый код необязательно трогать же. Только сообщить видеокарте, где подменить несколько команд пересылки и обработки пикселей (таковых команд в типичных играх совсем немного)

[NEO SPECTRUMAN]

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

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

да и для такого подхода как spec256 не обязательно лепить 16 спектрумов вместе...

[Lethargeek]

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

явно не по адресу обращение (с "моим" способом в старом коде не пришлось бы править ни байта)

да и для такого подхода как spec256 не обязательно лепить 16 спектрумов вместе...

предлагали где-то слепить вместе только регистры, но по размеру это вышло бы не намного меньше, чем 16 целых z80

[Reobne]

Ты о чём, какой еще "переделки"? Старый код необязательно трогать же. Только сообщить видеокарте, где подменить несколько команд пересылки и обработки пикселей (таковых команд в типичных играх совсем немного)

Прости, вообще не понимаю. Разжуй пожалуйста на примере. Вот допустим у нас некий Lode Runer. В пиксельном плане персонажи рисуются и стираются по XOR. В атрибутном плане цвет персонажа красит знакоместа в режиме "моляр", восстанавливается из 768 байтного буфера.
ВОПРОС. Как будет работать переделка, того типа как ты описываешь?

Вот моё недоумение. Старый код не трогаем, кода восстановления фона под спрайтами не было изначально, так откуда он возьмётся и восстановит нам фон?

[NEO SPECTRUMAN]

предлагали где-то слепить вместе только регистры, но по размеру это вышло бы не намного меньше, чем 16 целых z80

все таки в конечном итоге конструкция будет по проще чем >16 спеков стуленных вместе

[Lethargeek]

Прости, вообще не понимаю. Разжуй пожалуйста на примере. Вот допустим у нас некий Lode Runer. В пиксельном плане персонажи рисуются и стираются по XOR. В атрибутном плане цвет персонажа красит знакоместа в режиме "моляр", восстанавливается из 768 байтного буфера.
ВОПРОС. Как будет работать переделка, того типа как ты описываешь?

Вот моё недоумение. Старый код не трогаем, кода восстановления фона под спрайтами не было изначально, так откуда он возьмётся и восстановит нам фон?

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

1) Просто побитно ксорить многобитные пиксели, результат примерно будет похож на spec256 или zx-poly (смотря по кодированию цвета, индекс или непосредственно RGB). То есть на чёрном фоне - правильные цвета, при накладках - разноцветное месиво. Зато проще всего вспомогательный код в памяти видеокарты, и сами команды этого кода - аналоги спектрумовских чтения, записи и ксорки.

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

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

3) Условная замена пикселя вместо ксора. В том же лодераннере в процедуре обновления человечка сначала старый спрайт стирается ксоркой, а потом сразу же выводится новый спрайт, и так поочерёдно все человечки. То есть, если бы не ксором печатать их, а нормальным наложением сверху, да еще разными цветами, то в конце могли получить картинку, когда от самого первого человечка видно только несколько пикселей. Вот их-то в следующем игровом кадре и нужно чистить, не трогая остальные, - по условию попадания индекса в определённый диапазон. Таким образом можно выделить на каждый спрайт десяток-другой цветов и накладывать хоть сотни поочерёдно.

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

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

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

все таки в конечном итоге конструкция будет по проще чем >16 спеков стуленных вместе

Полагаю, ненамного. Так избавимся только от повтора блока ветвлений и частично флагов, а все регистры, пересылки, логика и арифметика повторяются.