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

[pulsar]

Так он итак "заранее мёртвый", потому что при экране 256x192 и при 256 цветах он займёт 48 кило..

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

[fan]

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

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

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

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

С железной точки зрения режим полностью аналогичен alco16c , только вместо двупиксельного байта у нас однопиксельный RRRGGGBB (отсюда и 128х192) . Железная реализация - одна микруха с мелочью . Образцы картинок по линку выше (получается очень здорово).

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

[Sinus]

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

[Lethargeek]

Для программирования самое удобное как сказали Vitamin и SAM style, т.е. по 2 бита на цвета + 2 бита общая яркость.

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

[pulsar]

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

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

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

[fan]

не исключено что вы правы, но можно все же такую палитру сделать?!

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

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

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

[Advertiser]

[pulsar]

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

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

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

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

[Lethargeek]

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

[GriV]

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

[fan]

для IGRBigrb?!

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

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

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