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

[inozemcew]

Заинтересовала тема, решил подумать, как же можно малой кровью убрать клэшинг. Идея такая - экран состоит из нескольких экранных плоскостей (2,4,8 штук), которые находятся над друг над другом. Самая нижняя плоскость - обычный спектрумовский экран, на нем рисуется фон. Каждая следующая плоскость предназначена для рисования спрайтов. Это тоже обычный спековский экран, но с одним отличием. Если его точка имеет цвет INK, то она отображается цветом из атрибутов этой плоскости. Если же она имеет цвет PAPER, то она считается прозрачной, и сквозь нее "просвечивают" нижележащие слои. Вот, в принципе, и всё. Для управления всем этим хозяйством нужен один-едиственный порт, в котором задается номер плоскости, которая маппится в адресное пространство экрана ($4000-$5aff).

Как это все работает - очень просто. Рисуем фон на самой нижней плоскости, переключаемся на плоскости повыше, рисуем спрайты. Если модифицируем готовую игру, достаточно найти процедуру вывода спрайта, и вставить перед ней OUT (c),<номер плоскости>, а после нее вернуть плоскость 0.

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

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

[Advertiser]

[null_device]

экран состоит из нескольких экранных плоскостей (2,4,8 штук)

Чем-то мне это неуловимо напоминает дендиевские "слои"...

[Reobne]

inozemcew, Хорошая попытка, но вижу трудности. (Давно тут сидим)
Вот возьмём твою картинку с Рэмбо, и рассмотрим белые бочки на жёлтом полу.
Пол, как я понимаю, нарисован на нулевом слое(самом дальнем (самом нижнем)), а бочки, допустим на втором.
Но чтобы бочки были правильные, нам не только надо добавить белый цвет, но и чёрный (окантовка и рёбра).
Это значит, что нам нужно, либо править нулевой слой, либо вводить первый слой (между 0 и 2), с чёрным ИНК-ом.
А это уже не слабо раздует модифицируемую программу и по тактам и по байтам.
По тактам, конечно, важно не для бочек, а для спрайта героя и других подвижных объектов.

[null_device]

Теперь недостатки.

Главный "недостаток": для каждого слоя нужна взять ~6К под "страницу" видео-памяти. И как-то реализовать программно-аппаратный интерфейс (ведь теперь, 50 раз в секунду, на экране должно отображаться содержимое всех слоев).

[Spectramine]

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

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

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

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