ZX-Poly™ platform

[Black_Cat]

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

не, этот вариант меня не устраивал. Палитра на знакоместо - это клешинг, атрибут на четвертушку тоже не намного лучше. Я описывал несколько видоизменённый свой вариант (1х8 или 1х4), в котором битовая плоскость I определяет одну из двух палитр на группу пикселов (как это обычно делается в Спеке). При этом цвета берутся не из соотвующих атрибутов, а из регистров пар палитр на которые эти атрибуты указывают, а бит I указывает на один из пары цветов в соответствующем регистре палитры (при этом нужно 16 8ми разрядных регистров палитры).

только 2x2

Меня как раз интересовали соображения на предмет почему группа пикселов такая, а не этакая. Есть тут какие-то предпочтения для кодера и чем они обусловлены?

[Lethargeek]

не, этот вариант меня не устраивал. Палитра на знакоместо - это клешинг, атрибут на четвертушку тоже не намного лучше.

И что "клэшинг" (правильно - спиллинг) всего двух (а скорее всего только INK) цветов из 16 (то есть 14 - независимы на всем экране) хуже, чем 8 цветов на точку для неполноценных переднего/заднего плана?!

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

Думаешь, консоли под переделанные игрушки не хватит 16 цветов (из двух палитр) в окне? Это (с поправкой на скорость) практически уровень Atari ST (а то и лучше) - многие эффекты с растровым прерыванием можно как раз атрибутами повторить.

Меня как раз интересовали соображения на предмет почему группа пикселов такая, а не этакая.

Из-за попиксельного расслоения в режиме 512x384x1.

[Black_Cat]

Из-за попиксельного расслоения в режиме 512x384x1.

имеется ввиду способ формирования изображения в режиме 5? А думаешь эти два режима (4+ и 5) должны быть как-то связаны? Вроде нет задачи конвертить что-то из 4+ в 5 (а значит нет задачи иметь идеологическую связь по форме атрибутных областей). Есть задача конвертить из стандартного режима в 4+ или 5 и тут могут быть некие предпочтения. Например был такой расширенный режим для Спека как атрибут на байт, дык он фактически является подмножеством режима с пикселями сформированными в группы 8х1 и это уже является определённым обоснованием (если под этот режим ещё и софт есть ), хоть и не с точки зрения кодера, а с т.з. наличия доп. софта.

я так понял, атрибуты там вообще не используются.

Имеешь ввиду атрибуты переделываемого софта? Используются, но не совсем напрямую, т.к. они для всего знакоместа, а у меня знакоместо разбито на группы пикселей имеющих свои отдельные атрибуты (т.е. детализация выше и соответственно вероятность спиллинга ниже, т.к. основная идея в том что-бы по возможности не испортить не имеющий спиллинга 4 режим, в противном случае вообще нет смысла цеплять сюда ещё и атрибуты, уж лучше пускай остаётся вообще без атрибутов но и без спиллинга). Разница между 4 и 5 режимами не в глубине цвета и разрешении, а именно в наличии или отсутствии спиллинга - это критерий.
Для того, что бы небыло путаницы ещё раз опишу схему формирования цвета:
В зависимости от размера группы пикселов четыре байта атрибутов делятся на группы бит адресов регистров палитры (Ар). Для группы из 8 пикселов - атрибут имеет 4 бита (Ар0-3) на каждый пиксел в строке знакоместа, для группы из 4 пикселов соответственно 2 бита (Ар0-1) на каждый пиксел в строке знакоместа. В соответствии с 4х (или 2х) битным адресом регистров палитры Ар выбирается один из 16 (или 4) регистр палитры Rр0-15 (Rр0-3). Из него считывется байт палитры имеющий структуру p0p1p2p3p0'p1'p2'p3'. Выбор полубайта р или р' осуществляется в соответствии со значением бита I. Цвета RGB формируются соответственно как R(G,B)p0p1p2p3 или R(G,B)p0'p1'p2'p3'. Разница в вариантах с группами по 4 или 8 пикселов на атрибут в количестве доступных для адресации регистров палитры на весь экран - соответственно 4 или 16. В результате получаем 8 цветов из палитры 128 на каждую группу пикселов, каждый пиксел своим цветом.

P.S. Это судя по всему окончательное решение задачи о возможности использования одних и тех же спрайтов с разной атрибутной раскраской в режиме 4.

[Lethargeek]

Вроде нет задачи конвертить что-то из 4+ в 5 (а значит нет задачи иметь идеологическую связь по форме атрибутных областей). Есть задача конвертить из стандартного режима в 4+ или 5 и тут могут быть некие предпочтения.

Мож кому-то захочется сконвертить И в 4+, И в 5? Чем больше у них общих мест, тем меньше работы.

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

Четвертушки - фактически то же самое.

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

Ну дык делаем во всех атрибутах атрибутные цвета равными палитровым цветам, вот тебе и обычный 16-цветный режим "без атрибутов".

Разница между 4 и 5 режимами не в глубине цвета и разрешении, а именно в наличии или отсутствии спиллинга - это критерий.

Гы, 512x384 vs 256x192 - и разница не в разрешении? Жжош!
И кстати в режиме 5 не спиллинг, а как раз старый добрый клэшинг.

Для того, что бы небыло путаницы ещё раз опишу схему формирования цвета:

Имхо делить пикселы на мелкие группы неудобно. Ну можно например забабахать 4 палитры, и каждые два бита (из 32) атрибутов определяют свою палитру для группы 2x2 пиксела. А толку? Для нормальной анимации придется цвета урезать,
то есть в 4 палитрах будет не 64 разных цвета, а меньше; переделывать игрушки тщательнее придется, стандартный режим отдельно лепить опять же... ну нах! А если атрибуты одинаковые во всех режимах, можно например в игрушках весь текстовый вывод не трогать, раскручивать только графическую часть (и то возможно не полностью). Ресурсов опять же меньше понадобится в пересчете на логику (та же палитра к примеру - лучше даже не две иметь, а зафиксировать атрибутные цвета как прямой код IGRB). Если у разных видеорежимов много "общих мест" при сильном внешнем различии - имхо это хорошо. Для переделок унифицированных атрибутов за глаза хватит, а что кто-нить чего-то сложное и оригинальное кодить будет - большие сомнения. Спектрумисты и так народ ленивый, а тут еще извращаться надо, чтоб картинка не глючила...

Ну да все равно никто ничего делать не будет.

[Alex_kapfa]

Добрый день. Я пересмотрел все посты этой темы, но нигде не нашел ссылки на эмулятор «ZX-Poly platform»
Пожалуйста, подскажите, откуда можно скачать описываемый здесь эмулятор. Быть может, я был не очень внимателен, и «просмотрел» нужную мне ссылку.

[James DiGreze]

Raydac, вынеси эти ссылки в первый пост темы, так будет проще искать

[ZXMAK]

а исходники эмулятора открыты?

[balu_dark]

а сайт у всех не открывается - или только у меня?

[AAA]

а сайт у всех не открывается - или только у меня?

http://www.igormaznitsa.com/zxpoly/zxpoly.html
этот открывается или ты про что ?

[balu_dark]

этот не открывается