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

[AzAtom]

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

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

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

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

Можно даже просто взять 4-8 битовых планов и обычную палитру, и затем заполнив эту палитру специальным образом, получить псевдополупрозрачные слои. Именно так это делается на "Векторе". Плюс еще там 16-256 цветов на точку и т.д. и т.п.

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

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

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

Не совсем модифицировать. Точнее, вставить. Для этого нужно подвинуть некий код, в нём придётся поковыряться на предмет перемещаемости. Думаю, это не так и просто будет адаптировать игру к такому выводу на экран. Правда, если спрайт выводится xor'ом, то можно будет команды чтения заменить на команду вывода в порт, тогда да, будет не так сложно. Или сначала запоминается фон, то тоже его можно заменить на запись в порт.

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

[Advertiser]

[inozemcew]

красивые картинки. сам рисуешь?

Ага, балуюсь помаленьку. Есть еще немного вариаций на тему "что было бы, если бы битпланов было бы 2" , только не знаю куда стоит выкладывать.

Это позволяет задавать цвет для каждых 8 горизонтальных точек, но избавиться от вертикального клешинга атрибута,

Если бы такой способ задания атрибута знакоместа был бы в спектруме изначально - никаких проблем. Но увы, весь софт написан под экран с атрибутами в $5800-$5aff, так что метаться поздно.

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

Уже говорилось - регистр маски. Причем только для игр в которых спрайты с масками. Остальные остаются, как есть. Впрочем, на с64 и MSX hi-res спрайты тоже без маски. Можно сравнить.

Для этого нужно подвинуть некий код,

Двигать ничего не нужно. Заменить вызов старой процедуры вызовом новой из которой потом сделать JP в старую - не требует перемещения никакого кода.

[AzAtom]

Двигать ничего не нужно. Заменить вызов старой процедуры вызовом новой из которой потом сделать JP в старую - не требует перемещения никакого кода.

Тогда можно цвет и через порт задавать, не делая несколько плоскостей, как выше написал. Разве что, можно сделать одну плоскость на фон и одну на все спрайты с прозрачным цветом. Будет задаваться цвет и прежней процедурой выводиться однобитная картинка, получая нужный цвет.