Важная информация

User Tag List

Страница 1 из 3 123 ПоследняяПоследняя
Показано с 1 по 10 из 27

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

  1. #1
    Banned Аватар для Black_Cat
    Регистрация
    15.06.2006
    Адрес
    S.Pb
    Сообщений
    5,646
    Благодарностей: 231
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

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

    Тут в Железе щас изобретают новый видеорежим, дык чтоб не изобрести чёт неудобоваримое есть вопрос - как удобней расположить биты разрядов цветов, чтоб это было максимально удобно для вычислений в программах?
    При вычислении палитры значения 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
    Последний раз редактировалось Black_Cat; 20.02.2008 в 17:39.

  2. #1
    С любовью к вам, Yandex.Direct
    Размещение рекламы на форуме способствует его дальнейшему развитию

  3. #2
    Vitamin C++ Аватар для Vitamin
    Регистрация
    14.01.2005
    Адрес
    Таганрог, Россия
    Сообщений
    4,031
    Благодарностей: 1426
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  4. #3
    Banned Аватар для Black_Cat
    Регистрация
    15.06.2006
    Адрес
    S.Pb
    Сообщений
    5,646
    Благодарностей: 231
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Vitamin Посмотреть сообщение
    По 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. Т.е. грубо говоря - щёлкнув тумблером можно будет переходить из одного режима в другой, не меняя ничего в коде и при этом палитры будут приблизительно похожи. Хотя конечно если сделать общую яркость, то они будут ещё больше похожи... эт уже вопрос наверно к художникам больше - про раздельную или общую яркость.
    Или мож есть ещё какие резоны..?
    Последний раз редактировалось Black_Cat; 20.02.2008 в 17:20.

  5. #4
    CraZZZy CodEr Аватар для SAM style
    Регистрация
    28.02.2005
    Адрес
    Великий Новгород
    Сообщений
    1,548
    Благодарностей: 738
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  6. #5
    Banned Аватар для Black_Cat
    Регистрация
    15.06.2006
    Адрес
    S.Pb
    Сообщений
    5,646
    Благодарностей: 231
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Lethargeek Посмотреть сообщение
    Не, тогда 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 - заметнее, просто ярче).
    Глядя на эти формулы, меня мучает вопрос а как это будет в программировании? как с вычислением этих цветов будет?

  7. #6
    Guru Аватар для Lethargeek
    Регистрация
    07.09.2005
    Адрес
    Воронеж
    Сообщений
    2,045
    Благодарностей: 197
    Записей в дневнике
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  8. #7
    Banned Аватар для Black_Cat
    Регистрация
    15.06.2006
    Адрес
    S.Pb
    Сообщений
    5,646
    Благодарностей: 231
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  9. #8
    Master
    Регистрация
    17.05.2005
    Адрес
    г. Абакан
    Сообщений
    694
    Благодарностей: 53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Для программирования самое удобное как сказали 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.

  10. #9
    Master Аватар для pulsar
    Регистрация
    26.01.2005
    Адрес
    чайковский
    Сообщений
    679
    Благодарностей: 97
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Exclamation

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

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

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

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

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

  11. #10
    Master Аватар для key-jee
    Регистрация
    16.01.2005
    Адрес
    Пермь
    Сообщений
    514
    Благодарностей: 16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Exclamation

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

Страница 1 из 3 123 ПоследняяПоследняя

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. Color Lines
    от rasmer в разделе Игры
    Ответов: 18
    Последнее: 04.01.2013, 11:22
  2. Какое питание на Байте
    от Ден в разделе Для начинающих
    Ответов: 8
    Последнее: 22.07.2010, 20:52
  3. Flash Color
    от drbars в разделе Unsorted
    Ответов: 2
    Последнее: 10.06.2007, 18:29
  4. Flash Color
    от moroz1999 в разделе Unsorted
    Ответов: 14
    Последнее: 05.12.2006, 13:12
  5. ищу демо color+
    от johnny в разделе Демо
    Ответов: 3
    Последнее: 20.04.2005, 19:04

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •