Ідея, яку я мав на увазі, полягає в тому, щоб генерувати якомога більше кольорів (в межах) кольорів для необхідної кількості кольорів. Додаткові клопоти, якщо мені потрібна додаткова пара кольорів пізніше для тієї ж діаграми (може бути додано пару зайвих смужок), вони повинні вписуватися в ту саму схему, зберігаючи існуючі кольори однаковими.
Ідея, яку я придумав, - трохи хитромудра. Уявіть коло кольорів (можливо, кожен має різний відтінок з однаковою насиченістю і яскравістю, хоча ви можете визначити будь-яке коло через будь-який кольоровий простір). Замість того, щоб задавати кут у градусах для цього кола, встановіть діапазон від нуля до 255. У двійковому періоді це 00000000 до 11111111. Додайте його до 8 біт 255, і він переповнюється назад до нуля, так що він, природно, діє як "кругове значення" (в технічному плані додавання і віднімання - це модуль 256).
Хитрість полягає в тому, що ви вибираєте нульовий колір, кольоровий і т. Д., Щоб перевернути ці числа. Для цього в C я б використовував ...
value = ((value & 0x0F) << 4) | ((value & 0xF0) >> 4);
value = ((value & 0x33) << 2) | ((value & 0xCC) >> 2);
value = ((value & 0x55) << 1) | ((value & 0xAA) >> 1);
Отже послідовність 0, 1, 2, 3, 4 перетворюється на 0, 128, 64, 192, 32.
Справа в тому, що у вас є 256 чітких кольорів, а найдавніші з них дуже широко розташовані між собою, пізніші - менш рознесені та заповнення прогалин (64 - це напівшляхи між 0 і 128, 32 - на півдорозі від 0 до 64 тощо).
Будь-яка бітова ширина для певного «кута» спрацює, якщо ви адаптуєте біт-реверс, і звичайно, ви можете запустити кілька циклів одночасно для різних параметрів кольору (можливо, відтінок крутиться швидко, але насиченість крутиться повільніше).
Це залишає лише питання про те, як ви позначаєте свої "кути" на конкретні RGB-номери чи що завгодно, на що я не експерт - о, і питання, чи підтримує ActionScript біт-фіддінг.