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

[drbars]

Для простоты адаптации и совместимости с 48К нужно что-то простое. Нет смысла придумывать новые видеорежимы итд.. итд.. никто под них писать не будет.
Самый простой способ сделать спрайт без клешинга - создать дополнительную теневую видео-область в которую легко читать/писать. А потом обычный экран рисовать вместе с теневым вот и результат Простота переделки игр - должна быть в смене адреса вывода спрайта ГГ и врагов. Например обычный экран с адреса #4000, а теневой с #0000. Грабли конечно будут при адаптации, но это самый простой способ.

[inozemcew]

Для простоты адаптации и совместимости с 48К нужно что-то простое. Нет смысла придумывать новые видеорежимы итд.. итд.. никто под них писать не будет.

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

Например обычный экран с адреса #4000, а теневой с #0000.

Теневой тоже с #4000. И не один, а пара-тройка. Переключать значением в порт. Для "теневых" экранов PAPER прозрачный. Это собственно и предлагалось.

Что тут непонятного-то?

Непонятно, насколько это будет похоже на спектрум.

ОДИН ПИКСЕЛЬ Спека принимает только ОДНО значение.

Нет. Он таки принимает ДВА значения - 1 и 0, INK и PAPER. По этому индексу и выбирается из байта атрибута (который является такой себе мини-палитрой на два цвета) конкретное значение цвета.

До вывода выбираем "атрибут индекс такой-то" и рисуем сколько нам надо пикселей.

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

Изометрических таких должно быть немало.

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

[Lethargeek]

Простота переделки игр - должна быть в смене адреса вывода спрайта ГГ и врагов. Например обычный экран с адреса #4000, а теневой с #0000. Грабли конечно будут при адаптации, но это самый простой способ.

ну ё-моё... самое простое - это перезадавать только цвет! а ты зачем-то хочешь еще и адрес...

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

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

Нет. Он таки принимает ДВА значения - 1 и 0, INK и PAPER. По этому индексу и выбирается из байта атрибута (который является такой себе мини-палитрой на два цвета) конкретное значение цвета.

Ладно, может принимать ОДНО из двух возможных значений (ink и paper это просто условность). А два значения - это частный случай 2^n значений для n=1.

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

Нет, неправильно. Наложение объектов (точно так же, как и на Спектруме) определяться будет порядком их отрисовки, а не тем номером.

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

А зачем? И так ведь понятно, что там накладывать объекты нужно по удалённости. А удалённость изменяется при движении.

[inozemcew]

то это монстр

Ну, со стороны реализации в железе - не два проводка перерезать, конечно, но и другие варианты ничуть не проще. А со стороны программирования все просто и логично. Нет каких-то предварительных шаманств с режимами и регистрами, которые нужно сначала запрограммировать, нет сложного внутреннего состояния которое нужно учитывать. Все вполне в идеологии спектрума, ИМХО.

может принимать ОДНО из двух возможных значений

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

Наложение объектов (точно так же, как и на Спектруме) определяться будет порядком их отрисовки, а не тем номером.

Да, точно. В этом различие.
Тогда позвольте уточнить, а как вы собираетесь сопоставлять индекс с оконечательным цветом пикселя? Я так понял, для каждого индекса будет один глобальный цвет (т.е. для всего экрана сразу). Или же для каждого индекса будет отдельная область атрибутов, которая будет переключаться по установке индекса в порту?

И так ведь понятно, что там накладывать объекты нужно по удалённости.

Если перерисовывать всё - никаких проблем нет. Рисуем самые дальние объекты в самый нижний слой, если попадается объект другого цвета, например спрайт игрока, просто переключаемся в слой выше и рисуем дальше тем же алгоритмом.
Хуже, если в игре была частичная перерисовка. Тут надо уже смотреть конкретный игровой движок.

[Lethargeek]

Ну, со стороны реализации в железе - не два проводка перерезать, конечно, но и другие варианты ничуть не проще.

Я к тому, что монструозность - это также соотношение сложности железа к его возможностям.
Например, N цветов вместо 2^N при том же размере памяти уже как-то не особенно вдохновляет.

А со стороны программирования все просто и логично. Нет каких-то предварительных шаманств с режимами и регистрами, которые нужно сначала запрограммировать, нет сложного внутреннего состояния которое нужно учитывать.

Просто и логично выбирать в простейшем случае только цвет, а не шаманить с распределением цветов и спрайтов в слои.

Все вполне в идеологии спектрума, ИМХО.

Многослойность не в идеологии Спектрума.

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

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

Тогда позвольте уточнить, а как вы собираетесь сопоставлять индекс с оконечательным цветом пикселя? Я так понял, для каждого индекса будет один глобальный цвет (т.е. для всего экрана сразу). Или же для каждого индекса будет отдельная область атрибутов, которая будет переключаться по установке индекса в порту?

Индекс это просто число. Как прошивку карты запрограммируем, так она и будет сопоставлять. Глобальный цвет - самое простое решение, притом совместимое со старым zx-экраном при определённом режиме записи (то есть, два каких-то атрибутных кода писать как индексы, вычисляемые исходя из адреса пикселя; и даже если эти все особые индексы не использовать нигде, кроме их "законных" знакомест, всё равно еще незанятых ~30 тысяч)

Если перерисовывать всё - никаких проблем нет. Рисуем самые дальние объекты в самый нижний слой, если попадается объект другого цвета, например спрайт игрока, просто переключаемся в слой выше и рисуем дальше тем же алгоритмом.

И как узнать, не копаясь в логике работы движка, когда начинается отрисовка этих "самых дальних" объектов? А если каждый раз другого цвета новый объект? Причем их кол-во заранее неизвестно. Что-то может подобрать персонаж, потом выкинуть; после взрыва что-то разлетается на куски, которые потом мигают пару секунд...

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

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

[inozemcew]

Например, N цветов вместо 2^N при том же размере памяти уже как-то не особенно вдохновляет.

Если задача стоит отобразить N цветов, то 2^N, при том же размере, конечно лучше. Но задача у нас другая - устранить клэшинг не трогая графику и с минимальным вмешательством в код. Тут количество цветов - параметр второстепенный. Более того, задействованная память не пропадает понапрасну, как вам кажется, а используется для хранения изображения под спрайтами. Вы, кстати, тоже собираетесь хранить изображение под спрайтами в памяти видеокарты? Это разве не будет напрасным расходованием видеопамяти?

Многослойность не в идеологии Спектрума.

Как раз 3/4 игр для спека и построены на идеологии многослойности. Просто аппаратные ограничения не позволяют раскрасить слои изображения без клэшинга.

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

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

И как узнать, не копаясь в логике работы движка, когда начинается отрисовка этих "самых дальних" объектов?

Очевидно, в начале цикла отрисовки. По другому на стандартном экране сделать невозможно.

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

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

[Reobne]

Очевидно, в начале цикла отрисовки. По другому на стандартном экране сделать невозможно.

Немного прицеплюсь к слову "невозможно".
Теоретически возможно, формируя инфу типа Z-буфера.

И как узнать, не копаясь в логике работы движка, когда начинается отрисовка этих "самых дальних" объектов?

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

[Lethargeek]

Если задача стоит отобразить N цветов, то 2^N, при том же размере, конечно лучше. Но задача у нас другая - устранить клэшинг не трогая графику и с минимальным вмешательством в код. Тут количество цветов - параметр второстепенный.

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

Более того, задействованная память не пропадает понапрасну, как вам кажется, а используется для хранения изображения под спрайтами. Вы, кстати, тоже собираетесь хранить изображение под спрайтами в памяти видеокарты? Это разве не будет напрасным расходованием видеопамяти?

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

Как раз 3/4 игр для спека и построены на идеологии многослойности. Просто аппаратные ограничения не позволяют раскрасить слои изображения без клэшинга.

100% игр для Спека рисуют графику в однослойный буфер или в экран. И даже на логическом уровне у большинства двухмерных фон обычно (полу)пустой, и на переднем плане мало объектов, а изометрические игры - не для слоёв.

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

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

Очевидно, в начале цикла отрисовки. По другому на стандартном экране сделать невозможно.

А как узнать, когда начало этого цикла))) Может, всё же лучше не заморачиваться и выбрать схему, не заставляющую лишнего "узнавать"? Вот в однослойной схеме надо только выбрать/вычислить новый цвет рисуемого объекта, очевидно в самых типичных случаях это можно сделать просто по его адресу. И дальше процедур непосредственно обновления экрана - не нужно лезть.

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

Это неоправданный оптимизм. Просто может выглядеть только внешне.
И "смотреть" вообще никогда не надо, если можно этого избежать.

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

Просто отлаживать надо.

Просто не надо лишних ненужных "надо"

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

С графикой, конечно, проще всего. Но дело в том, что многослойность как раз потребует совершенно лишних разборов логики.

[inozemcew]

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

Двадцать лет назад, может быть. Сейчас - точно второстепенный.

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

Увы, видео в спеке имеет схему "бит-на-пиксель". Без перерисовки графики это не изменить.

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

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

100% игр для Спека рисуют графику в однослойный буфер или в экран.

Но делают они это послойно. Рисуется фон, поверх него спрайты, один за другим - слой за слоем. От того, что стандартный экран позволяет только слеплять слои до кучи, сам принцип послойного вывода от этого никуда не девается.

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

Кстати, можете сказать, как вы собираетесь в этой схеме реализовать такую элементарную вещь, как курсор мыши?

а изометрические игры - не для слоёв.

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

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

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

- - - Updated - - -

Теоретически возможно, формируя инфу типа Z-буфера.

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

[Lethargeek]

Двадцать лет назад, может быть. Сейчас - точно второстепенный.

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

Увы, видео в спеке имеет схему "бит-на-пиксель". Без перерисовки графики это не изменить.

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

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

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

Но делают они это послойно. Рисуется фон, поверх него спрайты, один за другим - слой за слоем. От того, что стандартный экран позволяет только слеплять слои до кучи, сам принцип послойного вывода от этого никуда не девается.

Еще раз. Это не послойный вывод, а ПООБЪЕКТНЫЙ (в общем случае - с неизвестным заранее числом и цветом этих объектов)

Кстати, можете сказать, как вы собираетесь в этой схеме реализовать такую элементарную вещь, как курсор мыши?

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

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

Мне почему-то кажется, что не надо делать лишней дурной работы

На самом деле, динамическое перераспределение слоев в процессе построения кадра - это совершенно несложно.

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

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

А зачем им что-то знать о "цвете объектов" (и самих объектах)? Они тупо затирают кусок экрана сохранённым в буфере куском фона. Даже если фон многоцветный, а не двухцветный, в памяти видеокарты можно хоть на каждый бит из памяти Спектрума выделить по полноцветному пикселю (если для совсем уж ленивых).