list.add(42, «Forty two») подразумевает что у вас в списке уже есть как минимум 41 элемент
Верно. При этом все элементы, которые с индексом большим, чем 41 смещаются. Массив не подходит, т.к. надо будет переместить все элементы, что в общем случае выливается в O(n).
Структура на основе дерева работает за O(log(n)). Гарантировано. Алгоритмы перебалансировки не такие страшные. AVL и красно-черное дерево как раз про это. Они поддерживают дерево (почти) сбалансированым, с определенными гарантиями, в том числе и по скорости.
SkipList тоже работает за O(log(n)), но это в среднем. Может и дольше. Как мне кажется, в среднем он может быть медленнее дерева, но это не точно, надо мерять.
Не успел утром ответить Вам на комментарий ниже, отвечу здесь.
Мне было важно 3 вещи:
Вставлять/удалять элементы в середину: list.add(42, "Forty two")
Доставать по индексу: list.get(42) -> "Forty two"
Находить индекс по элементу: list.indexOf("Forty two") -> 42
На SkipList + любая таблица можно сделать. Но не совсем так, как Вы написали в этом камменте. В качестве хранилища обычный двусвязный список не подойдет. Найдя узел из него нельзя получить его индекс. А если вместо двусвязного списка использовать SkipList, то можно посчитать количество элементов до конца списка и на основании этого вычислить индекс.
В целом, не удивительно, что такой подход сработает. Ведь SkipList и дерево очень похожи по возможностям, хоть и сильно отличаются в реализации. SkipList даже проще, т.к. предоставляет из коробки возможность узнавать количество элементов до конца.
Другое дело, что SkipList по памяти хуже чем дерево, т.к. каждый узел требует дополнительный массив или даже два. И скорее всего по производительности тоже будет хуже. Было бы интересно протестировать.
Deque это общее название двухсторонней очереди. Можно сделать на двусвязном списке (тогда нет возможности быстро доставать элементы по индексу и соответственно бинарного поиска) или на циклической очереди (тогда нет возможности быстро вставлять/удалять в середину).
Есть ещё возможность использоать SkipList, там получше с этим.
Но основная особенность в том, что у меня элементы не отсортированы. Это видно даже на примере с [“q”, “w”, “e”, “r”, “t”, “y”, “u”].
Кстати, спасибо за карту. Не сразу понял, что на позиции можно кликать и это ссылки на игру с соответствующим состоянием. Очень прикольно.
По карте видно, что есть 3 позиции, в которой Север может сделать не правильный ход (и проиграть при правильной стратегии Юга). А может и не делать и не проигрывать. Т.е. эти плохие ходы для Севера бессмыслены, что я и хотел сказать в первом комментарии. Стратегия не проигрывать есть, а стратегии выигрывать нет.
В одном сценарии из 3х цепочка до проигрыша довольно длинная, а в двух других проигрыша Севера наступает через 6 ходов (суммарно для двух игроков). Скорее всего глубина просчета немного меньше.
Когда Вы тестировали, то первый игрок выигрывал скорее всего из-за того, что у него были более короткие цепочки ходов до проигрыша и алгоритм их опознавал раньше. Вот и все :)
Да, не проиграть первому игроку, наверно, можно. Второму — точно можно. Насчет гарантировано выиграть — не уверен.
Смотрите, у Вас на графике есть положение, крайнее справа, S1421:
2 1
1 4
Ход левой нижней лункой, N2105:
2 1
0 5
Из этого положения у Вас на графике 2 варианта: S1502 и S1520:
0 2 | 2 0
1 5 | 1 5
Или я что-то не понимаю или у Вас ошибка. Оба варианта невозможны из состояния N2105.
Единственный вариант не проиграть это ходить в S0530:
Ок, возможно не баг, а фича. Я не знаю, на сколько ходов вперед просчитывает алгоритм. Возможно, он действительно не досчитывает до того момента, когда проигрыш становится очевидным.
Я думаю, что Вам это проще проверить: увеличить глубину поиска, кешировать гарантировано проигрышные стратегии, возможно, есть смысл как-то отдельно обрабатывать циклы. И запустить просчитать все подольше. Выигрышная стратегия если и есть, то только у второго игрока. Но, скорее всего нет, т.к. скорее всего алгоритм бы ее нашел и использовал бы.
Вообще, работа прикольная, для поиграть — вполне устраивает. Притензия была только к наличию выигрышной стратегии. На самом деле я бы вообще не открыл игру, если бы не челлендж с поиском стратегии. Одно дело найти что-то хитрое, что сложно уложить в голове и совсем другое дело взять противника измором, надеясь, что он где-то провтыкает. Особенно при игре с ботом :)
Анализ проводить не буду, для этого придется более глубоко разобраться в теме.
Но я попробовал нажимать стрелку вперед. В одной игре раз 5 прошел цикл (не совсем цикл, ходы немного отличались, но в итоге в игре несколько раз были одинаковые состояния, например [0440]). Надоело. А один раз я проиграл, но тогда первые 3 хода я сделал сам, чтобы не ждать.
Так что, все-таки, похоже на баг в алгоритме. Хотя с ним играть даже интереснее. Но это если играть, а не пытаться найти выигрышную стратегию, которой нет.
Поправьте, пожалуйста, в тексте, чтобы не вводить людей в заблуждение.
Ирония заключается в том, что если первый игрок всё делает правильно — он выигрывает.
Так ли это? Второй игрок может загнать игру в цикл и таким образом не проиграть. Мне удалось 2 раза выиграть, но это, похоже, баг алгоритма. Алгоритм иногда делает разные ходы из одинаковых состояний. Можно пользоваться кнопкой назад и повторять ход и получать разные результаты. Или не получать, я не разобрался от чего это зависит. Немного странно, учитывая то, что автор писал про сложность (отсутствие) рандомизации.
Буду обозначать ход игрока буквами L и R — брать шарики из левой лунки или правой соответственно. Состояние игры буду обозначать четырьмя цифрами [ЛевыйВерх, ПравыйВерх, ЛевыйНиз, ПравыйНиз].
Перовые ходы из состояния [2222] должны быть такие:
L[3014] L[0116] R[0332 или 3032].
Если мы попали в состояние [0332], то нужно делать такие ходы, опять же обязательно:
R[0440*] L[3122] L[4013] L[1115] R[0332 или 3032].
В результате попадаем в одно из тех двух состояний, которые были после третьего хода.
Второй игрок может всегда сводить игру к состоянию [0322] и никогда не проигрывать.
* Иногда на этом ходу можно получить состояние [2141] вместо [0440]. Один раз я выиграл из этого состояния. Потом несколько раз в него попадал, но довести до победы не удавалось.
Состояние [3032] более сложное, там гораздо больше вариантов. Один раз удалось победить через эту комбинацию, но стратегию не нашел. Да это и не важно. Второй игрок не обязан допускать такое состояние.
Резюмируя: выигрышной стратегии у первого игрока, похоже, нет. Но если все время ходить правильно и не делать ошибок, то ошибки может делать алгоритм и тогда у него можно победить. Поправьте меня, если я ошибаюсь.
Обновил скрипт.
Добавил Ваше пожелание со сворачиванием окон, а заодно немного переделал механизм назначения главного окна. Теперь какое-то из окон всегда назначено главным, если надо переназначить, то это нужно делать явно.
Так же есть идея переделать механизм переназначения главного окна. Чтоб сначала нажимать комбинацию сброса, а потом комбинацию окна. Тогда при переназначении не будет прыжков: попасть в старое окно, нажать сброс главного окна, перейти в нужное окно и только потом назначить его главным.
На самом деле, я и не надеялся, что кто-то вот прям сразу все себе настроит и прям сразу привыкнет. Для того, чтобы подсесть на хоткеи требуется время. А спрыгнуть еще сложнее. :)
Идея со сворачиванием тоже интересная, спасибо. Залью в репозиторий при возможности.
Давно не видел правый Winkey в ноутбуках. Понял, что почти не пользуюсь правыми Alt и Ctrl, но переключение языка на них в KDE повесить не смог. Может мало копал.
Да и сомнения есть, стараюсь не настраивать то, что нельзя будет настроить на рабочем макбуке.
Супер, отличная программа!
Легко настраивается, основную задачу выполняет хорошо.
К сожалению, нельзя настроить на отдельный шорткат Firefox в Private Browsing. И нет возможности создать кастомные шорткаты для привязки именно к окнам, а не к приложениям.
В любом случае, с ней намного лучше, чем без нее. Спасибо :)
Тут же идея в том, что на один шорткат навешены и запуск и получение фокуса. Плюс навигация по разным окнам одного приложения.
Давно не пользовался gnome, возможно там много подобавляли, я не знаю.
Можно ли в gnome повесить на разные шорткаты окно обычного Firefox и окно Firefox в Private Browsing? Ведь технически это одно и то же приложение. И желательно так, чтоб не перенастраиать это после перезагрузки или закрытия одного из окон.
Или другой сценарий. Я обновляю, например, файлы конфигурации в нескольких микросервисах. Каждый микросервис открыт в отдельном окне Idea. Мне нужно сделать несколько однотипных изменений в файлах во всех микросервисах. Я привязываю все нужные окна Idea к разным шорткатам (выбираю клавиши рядом, у меня это Alt+1...Alt+0). А дальше вношу однотипные правки во все проекты. Т.е. сначала меняю file1 во всех проектах, затем меняю file2 и т.д. Мне не надо искать окна по Alt+Tab и искать в какой из проектов я ещё не внес правки. В gnome так можно? Назначить открытые окна на шорткаты, желательно не заходя в меню, а потом так же легко переназначить для выполнения другой задачи?
Под тормозит я имел в виду время от нажатия комбинации до момента, когда окно получит фокус. Т.е. сам автоматор, наверно, не тормозит, но тормозит его запуск. Не суть важно, не смог с ним получить приемлемый отклик. В Linux же я получаю мгновенный отклик если приложение уже запущено.
Но это пол беды, я в Mac OS хоткеи не смог настроить. Они работают до тех пор пока текущая программа их не переопределит. Надо либо выдумывать сложные хоткеи, которые больше нигде не используются (но тогда они сложные и вся прелесть теряется) либо придумать что-то еще.
Большинство окон удобно разворачивать на весь экран, особенно на ноутбуке. Между полноэкранными окнами надо как-то переключаться.
Несколько рабочих столов, листание тачпадом как на макбуке, тайловые оконные менеджеры. Пробовал, не понравилось. Хоткеи удобнее.
Сомневаюсь, что разрешение глаза тут играет какую-то ощутимую роль. Речь идет об очень низких разрешениях, гораздо ниже, чем разрешение глаза. Если правильно помню, то у первой Sony PlayStation стандартное разрешение 320x240, но в некоторых видеороликах на границе красного визуальное разрешение падает еще в 2 раза, просто огромные пиксели. Подобное наблюдал на Nintendo DS, там разрешение еще меньше, 256х192.
Только понял, что обе системы не умеют сглаживание. Я думаю, что если бы красный/синий канал растянули до оригинального разрешения хотя бы с билинейным сглаживанием, то картинка была бы намного лучше.
Цветовая субдискретизация не очень хорошо описана. А тут автор, видимо, ошибся (или опечатался):
Исключение составляет 4:1:0, обеспечивающее одну выборку цветности в каждом блоке разрешения яркости 4 на 4.
Если я правильно понял из вики (https://ru.wikipedia.org/wiki/%D0%A6%D0%B2%D0%B5%D1%82%D0%BE%D0%B2%D0%B0%D1%8F_%D1%81%D1%83%D0%B1%D0%B4%D0%B8%D1%81%D0%BA%D1%80%D0%B5%D1%82%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F), то описание X:a:b означает разбиение изображения на блоки X 2 пикселя. Яркостная составляющая записывается для каждого пикселя (всего X 2 пикселей), а цветовая для a усредненных пикселей в первой строке и b усредненных пикселей во второй строке (всего a + b пикселя). При этом либо b = a либо b = 0. В первом случае разрешение цветовой составляющей по вертикали соответствует оригинальному, а во втором случае оно уменьшается по вертикалив 2 раза.
Соостетственно, 4:1:0 сохраняет одну выборку цвета на блок 4х2 пикселя. Про исключения в вики (русской и английской) вроде бы не написано.
Во многих старых играх наблюдал огромную пикселизацию в видеороликах в сценах, где много красного. Я догадывался, что это из-за 4:2:0. Но до сих пор не очень понимаю, почему это так заметно только с красным цветом. Не помню ничего подобного с синим или зеленым. Верить в то, что разрешение красного канала меньше чем синего или зеленого пока отказываюсь. Подозреваю, что дело в том, что уменьшеное разрешение цвета записывается для красного и синего каналов, а для зеленого вычисляется из яркости, что дает большее разрешение. Если так, то большую пикселизацию можно было бы наблюдать и на синем цвете, но сцены с плавными синими переходами встречаются редко, а, например, красный огонь часто.
Хотелось бы услышать комментарий от знающих людей.
Кстати, согласен. Подключить гирлянду к готовой библиотеке практически не требует каких-то особых знаний и умений. Придумать алгоритм чтоб он был субъективно приятным и нравился результат — отличная разминка для мозгов. Выбрать рандомный цвет, чтобы он был приятен и радовал глаз (не темный, не блеклый) — не тривиальная задача. Банальные бегущие огни тоже могут быть интересными, если задаться целью сделать их плавными и не раздражающими.
Плюсом получите уникальный результат, которого нет ни у кого.
Кстати, вот мои исходники для AtMega8. Нужны 2 кнопки и переменный резистор для регулировки скорости: https://github.com/masyamandev/LedStrings
Верно. При этом все элементы, которые с индексом большим, чем 41 смещаются. Массив не подходит, т.к. надо будет переместить все элементы, что в общем случае выливается в O(n).
Структура на основе дерева работает за O(log(n)). Гарантировано. Алгоритмы перебалансировки не такие страшные. AVL и красно-черное дерево как раз про это. Они поддерживают дерево (почти) сбалансированым, с определенными гарантиями, в том числе и по скорости.
SkipList тоже работает за O(log(n)), но это в среднем. Может и дольше. Как мне кажется, в среднем он может быть медленнее дерева, но это не точно, надо мерять.
Не успел утром ответить Вам на комментарий ниже, отвечу здесь.
Мне было важно 3 вещи:
На SkipList + любая таблица можно сделать. Но не совсем так, как Вы написали в этом камменте. В качестве хранилища обычный двусвязный список не подойдет. Найдя узел из него нельзя получить его индекс. А если вместо двусвязного списка использовать SkipList, то можно посчитать количество элементов до конца списка и на основании этого вычислить индекс.
В целом, не удивительно, что такой подход сработает. Ведь SkipList и дерево очень похожи по возможностям, хоть и сильно отличаются в реализации. SkipList даже проще, т.к. предоставляет из коробки возможность узнавать количество элементов до конца.
Другое дело, что SkipList по памяти хуже чем дерево, т.к. каждый узел требует дополнительный массив или даже два. И скорее всего по производительности тоже будет хуже. Было бы интересно протестировать.
Deque это общее название двухсторонней очереди. Можно сделать на двусвязном списке (тогда нет возможности быстро доставать элементы по индексу и соответственно бинарного поиска) или на циклической очереди (тогда нет возможности быстро вставлять/удалять в середину).
Есть ещё возможность использоать SkipList, там получше с этим.
Но основная особенность в том, что у меня элементы не отсортированы. Это видно даже на примере с [“q”, “w”, “e”, “r”, “t”, “y”, “u”].
Согласен, не разобрался в обозначениях и напутал.
Кстати, спасибо за карту. Не сразу понял, что на позиции можно кликать и это ссылки на игру с соответствующим состоянием. Очень прикольно.
По карте видно, что есть 3 позиции, в которой Север может сделать не правильный ход (и проиграть при правильной стратегии Юга). А может и не делать и не проигрывать. Т.е. эти плохие ходы для Севера бессмыслены, что я и хотел сказать в первом комментарии. Стратегия не проигрывать есть, а стратегии выигрывать нет.
В одном сценарии из 3х цепочка до проигрыша довольно длинная, а в двух других проигрыша Севера наступает через 6 ходов (суммарно для двух игроков). Скорее всего глубина просчета немного меньше.
Когда Вы тестировали, то первый игрок выигрывал скорее всего из-за того, что у него были более короткие цепочки ходов до проигрыша и алгоритм их опознавал раньше. Вот и все :)
Да, не проиграть первому игроку, наверно, можно. Второму — точно можно. Насчет гарантировано выиграть — не уверен.
Смотрите, у Вас на графике есть положение, крайнее справа, S1421:
Ход левой нижней лункой, N2105:
Из этого положения у Вас на графике 2 варианта: S1502 и S1520:
Или я что-то не понимаю или у Вас ошибка. Оба варианта невозможны из состояния N2105.
Единственный вариант не проиграть это ходить в S0530:
Поправьте меня, если я ошибаюсь.
Ок, возможно не баг, а фича. Я не знаю, на сколько ходов вперед просчитывает алгоритм. Возможно, он действительно не досчитывает до того момента, когда проигрыш становится очевидным.
Я думаю, что Вам это проще проверить: увеличить глубину поиска, кешировать гарантировано проигрышные стратегии, возможно, есть смысл как-то отдельно обрабатывать циклы. И запустить просчитать все подольше. Выигрышная стратегия если и есть, то только у второго игрока. Но, скорее всего нет, т.к. скорее всего алгоритм бы ее нашел и использовал бы.
Вообще, работа прикольная, для поиграть — вполне устраивает. Притензия была только к наличию выигрышной стратегии. На самом деле я бы вообще не открыл игру, если бы не челлендж с поиском стратегии. Одно дело найти что-то хитрое, что сложно уложить в голове и совсем другое дело взять противника измором, надеясь, что он где-то провтыкает. Особенно при игре с ботом :)
Анализ проводить не буду, для этого придется более глубоко разобраться в теме.
Но я попробовал нажимать стрелку вперед. В одной игре раз 5 прошел цикл (не совсем цикл, ходы немного отличались, но в итоге в игре несколько раз были одинаковые состояния, например [0440]). Надоело. А один раз я проиграл, но тогда первые 3 хода я сделал сам, чтобы не ждать.
Так что, все-таки, похоже на баг в алгоритме. Хотя с ним играть даже интереснее. Но это если играть, а не пытаться найти выигрышную стратегию, которой нет.
Поправьте, пожалуйста, в тексте, чтобы не вводить людей в заблуждение.
Так ли это? Второй игрок может загнать игру в цикл и таким образом не проиграть. Мне удалось 2 раза выиграть, но это, похоже, баг алгоритма. Алгоритм иногда делает разные ходы из одинаковых состояний. Можно пользоваться кнопкой назад и повторять ход и получать разные результаты. Или не получать, я не разобрался от чего это зависит. Немного странно, учитывая то, что автор писал про сложность (отсутствие) рандомизации.
Буду обозначать ход игрока буквами L и R — брать шарики из левой лунки или правой соответственно. Состояние игры буду обозначать четырьмя цифрами [ЛевыйВерх, ПравыйВерх, ЛевыйНиз, ПравыйНиз].
Перовые ходы из состояния [2222] должны быть такие:
L[3014] L[0116] R[0332 или 3032].
Если мы попали в состояние [0332], то нужно делать такие ходы, опять же обязательно:
R[0440*] L[3122] L[4013] L[1115] R[0332 или 3032].
В результате попадаем в одно из тех двух состояний, которые были после третьего хода.
Второй игрок может всегда сводить игру к состоянию [0322] и никогда не проигрывать.
* Иногда на этом ходу можно получить состояние [2141] вместо [0440]. Один раз я выиграл из этого состояния. Потом несколько раз в него попадал, но довести до победы не удавалось.
Состояние [3032] более сложное, там гораздо больше вариантов. Один раз удалось победить через эту комбинацию, но стратегию не нашел. Да это и не важно. Второй игрок не обязан допускать такое состояние.
Резюмируя: выигрышной стратегии у первого игрока, похоже, нет. Но если все время ходить правильно и не делать ошибок, то ошибки может делать алгоритм и тогда у него можно победить. Поправьте меня, если я ошибаюсь.
Обновил скрипт.
Добавил Ваше пожелание со сворачиванием окон, а заодно немного переделал механизм назначения главного окна. Теперь какое-то из окон всегда назначено главным, если надо переназначить, то это нужно делать явно.
Так же есть идея переделать механизм переназначения главного окна. Чтоб сначала нажимать комбинацию сброса, а потом комбинацию окна. Тогда при переназначении не будет прыжков: попасть в старое окно, нажать сброс главного окна, перейти в нужное окно и только потом назначить его главным.
Спасибо за отзыв. Рад что кто-то попробовал. :)
На самом деле, я и не надеялся, что кто-то вот прям сразу все себе настроит и прям сразу привыкнет. Для того, чтобы подсесть на хоткеи требуется время. А спрыгнуть еще сложнее. :)
Идея со сворачиванием тоже интересная, спасибо. Залью в репозиторий при возможности.
Давно не видел правый Winkey в ноутбуках. Понял, что почти не пользуюсь правыми Alt и Ctrl, но переключение языка на них в KDE повесить не смог. Может мало копал.
Да и сомнения есть, стараюсь не настраивать то, что нельзя будет настроить на рабочем макбуке.
Супер, отличная программа!
Легко настраивается, основную задачу выполняет хорошо.
К сожалению, нельзя настроить на отдельный шорткат Firefox в Private Browsing. И нет возможности создать кастомные шорткаты для привязки именно к окнам, а не к приложениям.
В любом случае, с ней намного лучше, чем без нее. Спасибо :)
Тут же идея в том, что на один шорткат навешены и запуск и получение фокуса. Плюс навигация по разным окнам одного приложения.
Давно не пользовался gnome, возможно там много подобавляли, я не знаю.
Можно ли в gnome повесить на разные шорткаты окно обычного Firefox и окно Firefox в Private Browsing? Ведь технически это одно и то же приложение. И желательно так, чтоб не перенастраиать это после перезагрузки или закрытия одного из окон.
Или другой сценарий. Я обновляю, например, файлы конфигурации в нескольких микросервисах. Каждый микросервис открыт в отдельном окне Idea. Мне нужно сделать несколько однотипных изменений в файлах во всех микросервисах. Я привязываю все нужные окна Idea к разным шорткатам (выбираю клавиши рядом, у меня это Alt+1...Alt+0). А дальше вношу однотипные правки во все проекты. Т.е. сначала меняю file1 во всех проектах, затем меняю file2 и т.д. Мне не надо искать окна по Alt+Tab и искать в какой из проектов я ещё не внес правки. В gnome так можно? Назначить открытые окна на шорткаты, желательно не заходя в меню, а потом так же легко переназначить для выполнения другой задачи?
Вот бы еще производителям ноутов это объяснить. Особенно одной яблочной компании.
Под тормозит я имел в виду время от нажатия комбинации до момента, когда окно получит фокус. Т.е. сам автоматор, наверно, не тормозит, но тормозит его запуск. Не суть важно, не смог с ним получить приемлемый отклик. В Linux же я получаю мгновенный отклик если приложение уже запущено.
Но это пол беды, я в Mac OS хоткеи не смог настроить. Они работают до тех пор пока текущая программа их не переопределит. Надо либо выдумывать сложные хоткеи, которые больше нигде не используются (но тогда они сложные и вся прелесть теряется) либо придумать что-то еще.
Большинство окон удобно разворачивать на весь экран, особенно на ноутбуке. Между полноэкранными окнами надо как-то переключаться.
Несколько рабочих столов, листание тачпадом как на макбуке, тайловые оконные менеджеры. Пробовал, не понравилось. Хоткеи удобнее.
Сомневаюсь, что разрешение глаза тут играет какую-то ощутимую роль. Речь идет об очень низких разрешениях, гораздо ниже, чем разрешение глаза. Если правильно помню, то у первой Sony PlayStation стандартное разрешение 320x240, но в некоторых видеороликах на границе красного визуальное разрешение падает еще в 2 раза, просто огромные пиксели. Подобное наблюдал на Nintendo DS, там разрешение еще меньше, 256х192.
Только понял, что обе системы не умеют сглаживание. Я думаю, что если бы красный/синий канал растянули до оригинального разрешения хотя бы с билинейным сглаживанием, то картинка была бы намного лучше.
Спасибо, интересная статья (обе).
Цветовая субдискретизация не очень хорошо описана. А тут автор, видимо, ошибся (или опечатался):
Если я правильно понял из вики (https://ru.wikipedia.org/wiki/%D0%A6%D0%B2%D0%B5%D1%82%D0%BE%D0%B2%D0%B0%D1%8F_%D1%81%D1%83%D0%B1%D0%B4%D0%B8%D1%81%D0%BA%D1%80%D0%B5%D1%82%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F), то описание X:a:b означает разбиение изображения на блоки X 2 пикселя. Яркостная составляющая записывается для каждого пикселя (всего X 2 пикселей), а цветовая для a усредненных пикселей в первой строке и b усредненных пикселей во второй строке (всего a + b пикселя). При этом либо b = a либо b = 0. В первом случае разрешение цветовой составляющей по вертикали соответствует оригинальному, а во втором случае оно уменьшается по вертикалив 2 раза.
Соостетственно, 4:1:0 сохраняет одну выборку цвета на блок 4х2 пикселя. Про исключения в вики (русской и английской) вроде бы не написано.
Во многих старых играх наблюдал огромную пикселизацию в видеороликах в сценах, где много красного. Я догадывался, что это из-за 4:2:0. Но до сих пор не очень понимаю, почему это так заметно только с красным цветом. Не помню ничего подобного с синим или зеленым. Верить в то, что разрешение красного канала меньше чем синего или зеленого пока отказываюсь. Подозреваю, что дело в том, что уменьшеное разрешение цвета записывается для красного и синего каналов, а для зеленого вычисляется из яркости, что дает большее разрешение. Если так, то большую пикселизацию можно было бы наблюдать и на синем цвете, но сцены с плавными синими переходами встречаются редко, а, например, красный огонь часто.
Хотелось бы услышать комментарий от знающих людей.
Кстати, согласен. Подключить гирлянду к готовой библиотеке практически не требует каких-то особых знаний и умений. Придумать алгоритм чтоб он был субъективно приятным и нравился результат — отличная разминка для мозгов. Выбрать рандомный цвет, чтобы он был приятен и радовал глаз (не темный, не блеклый) — не тривиальная задача. Банальные бегущие огни тоже могут быть интересными, если задаться целью сделать их плавными и не раздражающими.
Плюсом получите уникальный результат, которого нет ни у кого.
Кстати, вот мои исходники для AtMega8. Нужны 2 кнопки и переменный резистор для регулировки скорости: https://github.com/masyamandev/LedStrings
The Last Mission.
https://www.youtube.com/watch?v=Qq79lE8sVj4