Оптимальная раскладка RGB в байте 256 color?

[Black_Cat]

Тут в Железе щас изобретают новый видеорежим, дык чтоб не изобрести чёт неудобоваримое есть вопрос - как удобней расположить биты разрядов цветов, чтоб это было максимально удобно для вычислений в программах?
При вычислении палитры значения R=r2+r1+r0 и G=g2+g1+g0 - 3х битные, а B=b2+b1+(b2&b1) - 2х битное, т.е. b0=b2&b1.
Стоит ли делать раскладку совместимой с 16 color режимом, или есть что-то более оптимальное для вычислений палитры?

Обсуждение режима 256 color так же здесь: http://www.zx.pk.ru/showthread.php?p=120930#post120930
и здесь: http://www.zx.pk.ru/showthread.php?t=4767&page=7

[Advertiser]

[Vitamin]

По 2 бита на составляющую и 2 бита на общую яркость. Имхо

[Black_Cat]

По 2 бита на составляющую и 2 бита на общую яркость.

не, цвета все раздельные, без общей яркости, палитру они уже придумали. Вопрос как расположить биты RGB в байте, чтоб было удобно вычислять значения в программах.. т.е. вопрос чисто про удобство для программирования. Например если сохранять совместимость с 16 color режимом, то раскладку можно сделать такую:
g2 r2 g1 r1 b2 g0 r0 b1, а b0=b2&b1.
D7 - - - - - - - - - - - D0
..но будет ли удобно её считать? Можно изобразить что-то типа:
b2b1g2g1g0r2r1r0
Основной резон за 16 color раскладку - это автоматический переход 16 color <-> 256 color, т.е. одну и ту же картинку можно будет смотреть в обоих режимах, либо в большем разрешении, но с 16 color, либо в меньшем разрешении, но с 256 color. Т.е. грубо говоря - щёлкнув тумблером можно будет переходить из одного режима в другой, не меняя ничего в коде и при этом палитры будут приблизительно похожи. Хотя конечно если сделать общую яркость, то они будут ещё больше похожи... эт уже вопрос наверно к художникам больше - про раздельную или общую яркость.
Или мож есть ещё какие резоны..?

[SAM style]

Расклад цветов оригинальных атрибутов убог. Слизаные с него расклады 4bpp ATM и AlCo убоги для программирования. Если ещё и в 256 цветах будет такая же хрень - я увольняюсь из этого мира! (имхо, бест для 4bpp - IGRBigrb).

[Black_Cat]

Не, тогда 8 уровней серого не получишь.

Тогда уж так (ненулевой критерий):
r0=((r2 or r1) and rb0) or (rb0 and not(r2 or r1 or b2 or b1))
b0=((b2 or b1) and rb0) or (rb0 and not(r2 or r1 or b2 or b1))

Правое в скобках нужно для учета ситуации, когда все старшие биты R=B=0. Кстати немножко наврал, для некоторых "чистых" цветов самый темный оттенок получится слегка "грязноватым", хотя вряд ли будет сильно заметно (2DDp: для gr0 - заметнее, просто ярче).

Глядя на эти формулы, меня мучает вопрос а как это будет в программировании? как с вычислением этих цветов будет?

[Lethargeek]

Это формула не для программирования, а для рассыпухи
Хотя например конвертер 512 --> 256 довольно простой получится, даже на Спеке. Только картинки имхо лучше конвертить сразу на песюке Ну а в игрушках все равно спрайты заранее нарисованы.

[Black_Cat]

Ну а в игрушках все равно спрайты заранее нарисованы.

т.е. расчёт цветов в процессе выполнении программ не используют? и не имеет значения как сгруппированы биты в байте цвета? Предложенную тобой раскладку байта g2:r2:b2:g1:r1:b1:g0:rb0 можно разделить на три группы битов либо по цвету, либо по равным весам, но SAM style если я его правильно понял судя по всему имел ввиду что работать с полубайтами удобнее. Может есть вариант как-то перегруппировать биты, что позволит ускорить вычисление цветов? Например в одном полубайте r2:b2:r1:b1 , в другом rb0:g2:g1:g0.. Есть мысли по этому поводу?

[James DiGreze]

Для программирования самое удобное как сказали Vitamin и SAM style, т.е. по 2 бита на цвета + 2 бита общая яркость. Причем, если сделать в раскладке, предложенной SAM style, можно организовать 2 режима: 16с по 2точки на байт, или 256с с одной точкой на байт, при этом сохранится общая гамма в обоих режимах.
При этом к примеру формула для зеленого градиента out_g = (g1^2 + g0^1) * (i1^2 + i0^1), т.е. фактический цвет будет 4-х битным
А при программировании цветов работать с 2-х байтными табличками, например по and mask + or color.

[pulsar]

Тут в Железе щас изобретают новый видеорежим, дык чтоб не изобрести чёт неудобоваримое есть вопрос - как удобней расположить биты разрядов цветов, чтоб это было максимально удобно для вычислений в программах?

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

состряпайте для такой раскладки палитру, чтобы художники могли подумать на сей счет, если у них нет неприодолимых притензий то советую железячникам не изобретать очередного извращения и делать только так (я, похоже, 4й кодер, который об этом высказался)!

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

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

Расклад цветов оригинальных атрибутов убог.

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

[key-jee]

давайте не будем воять заранее мертвый режим.

Так он итак "заранее мёртвый", потому что при экране 256x192 и при 256 цветах он займёт 48 кило.. их тупо Push'ами заливать уже больше 5 фреймов выйдет.. Для "эффекта" очистки экрана это совсем немало.. Просто показать готовый скрин в 2 раза дольше.. А о чём то более сложном и вовсе можно забыть