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

[Lethargeek]

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

[Бука]

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

В комоде был режим 40*25 знакомест с 2я цветами на 8*8 или 20*25 знакомест с 3+1общий на 4*8 знакоместо, плюс спрайты.

В амерском проапгрейженном Спеке Timex 2068 были штатно два экрана, 512*192моно и мультиколор хардварный (легко кстати потом на нашей рассыпухе делали, см Балтик например).

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

Но конечно это уже совсем другой Спек, и другая ULA...

[inozemcew]

Ессно сам клэшинг никуда бы не делся (в каждом из экранов) но вот четыре цвета на знакоместо это прикольно.

Поддерживаю. И клэшинг доставал бы намного меньше.

При этом игры могли выглядеть бы покрасивше.

А вот если к этому добавить палитру, хотя бы на 64 цвета, то было бы еще красивее.

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

[Smalovsky]

Тогда соглашайтесь на моральные и этические принципы...

[inozemcew]

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

Не, вы немного не так поняли вопрос. В игре цвет спрайта хранится в виде кода атрибута, который после вывода спрайта записывается в область атрибутов. Про регистры видеокарты старые игры не имеют ни малейшего понятия. Как цвет из(или вместо) области атрибутов должен попадать в видеокарту?

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

- - - Updated - - -

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

ИМХО реально, надо было 1кб RAM от ZX81 не выбрасывать, а задействовать, как теневую память атрибутов. Получилось бы 2 бита на пиксель в двух планах, атрибут на знакоместо, и при желании сэкономить память, возможность использовать режим 1bpp простой манипуляцией атрибутами.

[AzAtom]

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

Во первых, при стандартной организации памяти, понадобится в разы бОльшая скорость чтения из памяти, что ру5 и подобные просто не осилят. Нужно их читать параллельно, как на векторе. С другой стороны, смотрел видео про комп, который отображал цвет интересным образом.
Итак, эти несколько плоскостей видеопамяти имеют один адрес, а записываются данные из порта. Т.е., устанавливаете в порт цвет с кодом $02, и пишете в видеопамять однобитную картинку, а при чтении со всех плоскостей там оказывается код цвета $02, который идёт на видеовыход. Это позволяет задавать цвет для каждых 8 горизонтальных точек, но избавиться от вертикального клешинга атрибута, и при показе не нужно читать ещё и байт атрибута. Единственный минус этого способа, просто так не считать обратно цветную картинку, чтобы запомнить фон под спрайтом, придётся вводить дополнительное чтение из порта.

[Advertiser]

[s_kosorev]

Т.е., устанавливаете в порт цвет с кодом $02, и пишете в видеопамять однобитную картинку, а при чтении со всех плоскостей там оказывается код цвета $02, который идёт на видеовыход.

EGA называется

[Hacker VBI]

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

[AzAtom]

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

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

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

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

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

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

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

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

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

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

[inozemcew]

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

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

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

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

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

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

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

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