Оптимальная раскладка 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

[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 раза дольше.. А о чём то более сложном и вовсе можно забыть

[pulsar]

Так он итак "заранее мёртвый", потому что при экране 256x192 и при 256 цветах он займёт 48 кило..
маленькая поправочка 128х192 (т.е. не долго думая можно предположить, что проектируемый режим будет оптимальней 16 color'ного - теже 24 кило (если все правильно понял), но без извращений с полубайтами). а режим пускай ваяют, вон 16 color на точку начали же минимально юзать... хотя это все...

[fan]

Сабж ересь и оскарбление для разума :D

Ничего в раскладке байта менять не нужно , всё и так оптимально - RRR GGG BB . Захотел поменять цвет - прибавил/сдвинул/закинул в экран .

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


Так он итак "заранее мёртвый", потому что при экране 256x192 и при 256 цветах он займёт 48 кило.. их тупо Push'ами заливать уже больше 5 фреймов выйдет..
С железной точки зрения режим полностью аналогичен alco16c , только вместо двупиксельного байта у нас однопиксельный RRRGGGBB (отсюда и 128х192) . Железная реализация - одна микруха с мелочью . Образцы картинок по линку выше (получается очень здорово).

З.Ы. Ни alco16 ни ATM не виноваты в своей дебильной раскладке байта , так просто меньше железных отходов получается . Ну и конечно ради "совместимости" радости ATM были повторены без оглядки на кошмарность оного .

[Sinus]

мне кажется что программируемая поллитра решит все проблемы, и всем станет пофиг расположение байтов :)

[Lethargeek]

Для программирования самое удобное как сказали Vitamin и SAM style, т.е. по 2 бита на цвета + 2 бита общая яркость.
И самое бестолковое (будут либо повторяющиеся цвета, либо сильно неравномерный шаг по яркости, если пытаться избежать повторений)

[pulsar]

Сабж ересь и оскарбление для разума :D


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

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

[fan]

не исключено что вы правы, но можно все же такую палитру сделать?!
Всмысле IGRBigrb для alco16c ? Да говарю же можно , всё элементарно делается .

Если речь о fan256c (RRRGGGBB) , то лапы прочь ! :D

З.Ы. Накрутчик палитры для любого режима -
http://zx.pk.ru/showthread.php?t=4767&page=14 с поста 136 (на следующей странице упрощённая схемка и принцип программирования)

[pulsar]

Всмысле IGRBigrb для alco16c ? Да говарю же можно , всё элементарно делается .

Если речь о fan256c (RRRGGGBB) , то лапы прочь ! :D


я вот о чем - как будет выглядеть:

http://upload.wikimedia.org/wikipedia/en/9/93/256colour.png
для IGRBigrb?! а то говорят повторы будут... а как на самом деле будет выглядит кто нибудь знает? может поделитесь знанием?

[Lethargeek]

Конечно будут, например g1*i2 = g2*i1 (возможны различия по нумерации "с нуля" или "с единицы", но итог один). А если делать у "яркости цвета" и "общей яркости" разный шаг - получится та еще путаница.

[GriV]

ВМЕШИВАЮСЬ: Давайте поменьше эмоций и поболее конструктива.

[fan]

для IGRBigrb?!
Так ты не о расклаке битов в байта а о палитре ? В каком режиме ?
Судя по I в IGRBigrb , речь о alco16 . Значит вопрос совсем не правельный . Ибо на выходе только четыре бита IGRB .

Если речь о fan256c (RRRGGGBB) , то....... Загрызу ! :D

Для извратов с палитрой есть накрутчик паллитры (есть вопросы задавайте). Его совершенно пофигу к чему подключать , хоть к alco16c (4бит), хоть к fan256c (8бит) , можно и к простому спеку с атрибутами (как не странн то же 4бит). При этом будут либо 16 либо 256 цветов из палитры в 16 с гаком мильёнов цветов .

[Shwartz]

мне кажется что программируемая поллитра решит все проблемы, и всем станет пофиг расположение байтов :)

Согласен, например я, если бы использовал эту чудо-графику, то хотел бы задавать цвета в форме LLHHHHHH (как HSL, только без saturation). И чтобы HHHHHH = 0 и 63 задавали бы серые оттенки. Или как варианты LLLHHHHH, LLSSHHHH и т.д.

[Black_Cat]

З.Ы. Накрутчик палитры для любого режима -
http://zx.pk.ru/showthread.php?t=4767&page=14 с поста 136 (на следующей странице упрощённая схемка и принцип программирования)Чтоб было более понятно тем, кто не хочет вникать в схемотехнику, переведу на русский ужасное словосочетание придуманное fan'ом - "Накрутчик палитры", это - "Конвертор палитры".
Он позволяет:
- подгружать и ставить в соответствие байту цветовой составляющей любую палитру в пределах 24bit цветов;
- благодаря подгружаемости палитры можно так-же задавать произвольную раскладку битов цвета в байте;
- благодаря тому, что цветовому байту ставится в соответствие аж 24bit цветов, можно в широких пределах сдвигать палитру.

Сейчас в таком девайсе есть одно "но" - это доступность его повсеместного применения.. Поэтому пока суд да дело, наверно неплохо бы придумать более-менее приемлемую раскладку битов в качестве базовой, для тех, кто пока хочет сделать систему в минимальной конфигурации - т.е. регистр и R-2R ЦАП. Поэтому всёж хотелось бы услышать идеи по расстановке бит в предложенных fan'ом и Lethargeek'ом палитрах:

Lethargeek: g2:r2:b2:g1:r1:b1:g0:rb0, где бит rb0 хитрым образом задаёт младшие биты r0 и b0:
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))
Сама по себе палитра очень универсальная и равномерная, нужно только придумать как лучше скомпоновать в ней биты, чтоб удобней было считать. Например так:
r2:b2:r1:b1:rb0:g2:g1:g0

fan: r2:r1:r0:g2:g1:g0:b20:b10, где биты b20:b10 так-же хитрым образом задают младший бит b0:
b0=b10&b20
Палитра более простая, но менее универсальная и равномерная чем предложенная Lethargeek'ом.

[GriV]

Выше тут Ки-Джи задавал вопрос о целесообразности разработки - заполнять PUSH'ами без циклов 5 прерываниый, что говорить про классические способы (минимум в 2 раза дольше). Ещё вопрос о длительности её - какие страницы памяти и каким образом она должна заполнять? Кстати, я не очень в теме, она уже есть в железе???

[Black_Cat]

тут Ки-Джи задавал вопрос о целесообразности разработки - заполнять PUSH'ами без циклов 5 прерываниый, что говорить про классические способы (минимум в 2 раза дольше).он ошибся, разрешение обсуждается не 256х192, а 128х192, поэтому будет точно так как и в 16 color режиме
Ещё вопрос о длительности её - какие страницы памяти и каким образом она должна заполнять?все тайминги и экраны стандартные для 16 color режима
она уже есть в железе???
пока нет, но это ненадолго, т.к. для одной палитры устройство легко реализуемо.. (как спаять ковокс)

[fan]

Выше тут Ки-Джи задавал вопрос
Дык ответил же http://zx.pk.ru/showpost.php?p=121048&postcount=12

Кстати, я не очень в теме, она уже есть в железе???
Для классического пентагона128 с уже реализованным alco16 режим делается одним регистром + мелочёвка .
Для Pentagon1024sl2.2 практически то же самое но нужно будет перезалить прошивку матрицы . Сейчас этим процессом DDp занимается .

Для прочих клонов не всё так просто , т.к. нет манускриптов по прикручиванию режима alco16 (поверх которого делается fan256). Пока я сочинил манускипт для Scorpion ZS 1024 turbo+ , но чёто добровольцев испытать не густо . Пока только ewgeny7 хотел его прикрутить . Подождём выходных , посмотрим чё будит .

Вобщем кто заинтересован в alco16 (и fan256) на своём колоне , то обращайтесь в этот разел http://zx.pk.ru/showthread.php?t=7119 . Но далеко не все клоны пригодны для этого процесса и далеко не совсеми клонами я буду возиться .

[Black_Cat]

мож правда кому нагляднее GGGRRBB(rb), хотя GRBGRBG(rb) удобнее, если например надо быстро яркость оценивать.во-во-во.. с этого места, и с примерами максимально быстрого кода пожалуйста.. при каккой раскладке можно сочинить наиболее быструю процедурку..
..господа программеры-демописатели примените свои навыки к пользе дела - выдайте варианты наиболее оптимального кодинга!!

[lintech]

Подкину дровишек в костёр :)
http://www.stevechamberlin.com/cpu/2008/07/04/video-palette-setup/

Вариант HHHHIIII хорош ! :) Нужно развивать&воплощать мысль дальше !
Жую мозгом мысль о HHHHHIII, ибо хорошо, красиво и правильно :)