Я бы дополнил картинками из en-wiki, становится понятно почему в одном случае получается цилиндр с двумя одноцветными поверхностями, в другом — только с одной.
Я тоже люблю D2 и D3, из клонов помимо Sacred и Torchlight советую обратить внимание на Kult: Heretic Kingdoms.
Игра глючная, может не завестись под современной виндой, но очень атмосферная и лаконичная, проходится за выходные, но с большим интересом :)
Вспоминается цитата представителя Стрелки на конференции NextPlace: «Каждого человека мы назначаем директором. Это простой способ сделать людей счастливыми.»
Действительно, если есть возможность — почему бы и нет?
Там сразу несколько реализаций. Первые две (_360, _384) используют double и деление, _Binary — только деление, _Adv и _Adv1 — чистые, _Adv2 — снова деление.
Adv и Adv1 можно дооптимизировать по точности, коду и скорости разом, но если вас они устраивают — особой нужды в этом нет :)
Из интересных технических решений осталось использование в качестве альтернативной цветовой модели давно забытых Web-safe colors и градиентов на их основе, они пришлись ко двору :)
Описанный вами случай подходит и под HSL при L = Lmax/2, S = Smax.
Действительно, при S = 255, V = 255 удобно.
По поводу кода:
Странно, что у вас вместо byte используется unsigned char.
Вместо sector % 2 можно использовать (sector & 1), вместо hue % 255 — byte (hue).
По поводу «переделать несложно»:
На самом деле при этом возникают неприятные эффекты. V — это то значение на которое идёт домножение primary и secondary. Как только оно не 255 — появляется дополнительное деление/умножение в secondary. Более того, если вы начнёте уменьшать S — третья компонента цвета будет расти пропорционально (255-S)*V/255, и это же слагаемое появится и в secondary, а то что там было придётся домножать на S/255. В общем, при любом минимальном понижении S и V такое высокое разрешение по тону станет ненужным. А под конкретную задачу — реализация удачная, не спорю :)
Не берусь сходу дописать код для HSV, но там могут случиться небольшие потери значений при делении.
Так как электротехник из меня слабый — схем нет, я ничего не монтирую. Проводами соединена Arduino, радиомодуль nRF24L01+, метр ленты на WS2811 и питание.
Фото будет, даже видео, но вряд ли на хабре — светодиодный жонглёрский реквизит тема очень узкая, мне кажется фаер-шоу и похожие искусства вряд ли будут интересны хабровчанам.
У HSL есть та же проблема, что и у HSV но в два раза сильнее: в HSL три стороны куба проецируются на конус, а три — на круг, образуя его основание, а у HSL — два конуса. Фактически, у вас две зоны (в окрестностях L = 0 и L = Lmax), где будет много слабо отличающихся друг от друга значений.
С математическими традициями у меня проблема — и тройка в дипломе, и с FFT уже месяц разбираюсь, чтобы понять. Но попробую учесть Ваш совет.
__attribute__ ((__packed__)) для RGB_t прописан для совместимости вот с этим кодом — ассемблерной вставкой для time-critical вывода значений на светодиодную ленту (см. также).
Arduino упомянут как самый популярный девайс на хабре, использующий AVR.
Собственно, я не уверен что тот же код будет актуальным для контроллеров на ARM — вряд ли там есть необходимость экономить память, циклы процессора, отказываться от float-point и делений (из того же блога — про скорость деления на AVR).
Игра глючная, может не завестись под современной виндой, но очень атмосферная и лаконичная, проходится за выходные, но с большим интересом :)
Действительно, если есть возможность — почему бы и нет?
Но это WS2811, она плотнее (60 LED на метр вместо 32) и управляется иначе, библиотекой FastSPI LED или кодом из этой заметки (он значительно короче).
Adv и Adv1 можно дооптимизировать по точности, коду и скорости разом, но если вас они устраивают — особой нужды в этом нет :)
Действительно, при S = 255, V = 255 удобно.
По поводу кода:
Странно, что у вас вместо byte используется unsigned char.
Вместо sector % 2 можно использовать (sector & 1), вместо hue % 255 — byte (hue).
По поводу «переделать несложно»:
На самом деле при этом возникают неприятные эффекты. V — это то значение на которое идёт домножение primary и secondary. Как только оно не 255 — появляется дополнительное деление/умножение в secondary. Более того, если вы начнёте уменьшать S — третья компонента цвета будет расти пропорционально (255-S)*V/255, и это же слагаемое появится и в secondary, а то что там было придётся домножать на S/255. В общем, при любом минимальном понижении S и V такое высокое разрешение по тону станет ненужным. А под конкретную задачу — реализация удачная, не спорю :)
Не берусь сходу дописать код для HSV, но там могут случиться небольшие потери значений при делении.
Фото будет, даже видео, но вряд ли на хабре — светодиодный жонглёрский реквизит тема очень узкая, мне кажется фаер-шоу и похожие искусства вряд ли будут интересны хабровчанам.
С математическими традициями у меня проблема — и тройка в дипломе, и с FFT уже месяц разбираюсь, чтобы понять. Но попробую учесть Ваш совет.
__attribute__ ((__packed__)) для RGB_t прописан для совместимости вот с этим кодом — ассемблерной вставкой для time-critical вывода значений на светодиодную ленту (см. также).
Arduino упомянут как самый популярный девайс на хабре, использующий AVR.
Собственно, я не уверен что тот же код будет актуальным для контроллеров на ARM — вряд ли там есть необходимость экономить память, циклы процессора, отказываться от float-point и делений (из того же блога — про скорость деления на AVR).