...В 16 битном цвете 128 на 160 влезет 3 картинки. Учитывая ваши мультяшные картинки, то 4х цветных более чем хватит...
Вообще-то есть еще и алгоритмы сжатия картинок. И, кстати, эти алгоритмы используются в форматах *.gif, *.pcx или даже *.bmp (это для относительно простых алгоритмов, естественно *.jpg никто на AVR использовать не будет). Так что, если интересует именно уменьшение используемого места, то, вероятно, применение простых алгоритмов сжатия поможет.
Строки 2 и 3 заставляют заподозрить, что не совсем оптимально.
И еще: при уменьшении глубины цвета используется один из двух приемов: дизеринг и округление, причем генерация оптимальной палитры для них должна осуществляться по различным алгоритмам. На приведенных картинках используется дизеринг.
Но я тут упоминал о сжатии: сжиматься, конечно, лучше будет картинка с округлением. Причем, возможно, меньший размер получится даже у картинки с большей глубиной цвета.
andriano ,
- палитра рисуется руками, в фотошопе, в коде, в паинте, да где угодно
- оптимизация/упаковка изображения имеет смысл при мощном / жирном МК, тут задача сделать простенькую игрушку, времен 80х годов.
- ваши умные слова про глубины цветов это конечно хорошо, но для персоналок. для МК имеет смысл максимально приготовить контент к выводу на отображаемое устройство
ЗЫ. В 90е годы мы успешно без интернета, умных книжек, фотошопа и прочих благ нынешней цивилизации сами придумывали и писали алгоритмы масштабирования/оптимизации улучшения изображений и прекрасно их применяли. Так что ваши комментарии, извините, не к месту.
Я позволил себе пронуммеровать пункты в цитате, чтобы было понятно, к чему относятся ответы.
andycat пишет:
andriano ,
1.- палитра рисуется руками, в фотошопе, в коде, в паинте, да где угодно
2- оптимизация/упаковка изображения имеет смысл при мощном / жирном МК, тут задача сделать простенькую игрушку, времен 80х годов.
3- ваши умные слова про глубины цветов это конечно хорошо, но для персоналок. для МК имеет смысл максимально приготовить контент к выводу на отображаемое устройство
4 ЗЫ. В 90е годы мы успешно без интернета, умных книжек, фотошопа и прочих благ нынешней цивилизации сами придумывали и писали алгоритмы масштабирования/оптимизации улучшения изображений и прекрасно их применяли. Так что ваши комментарии, извините, не к месту.
1. Вообще говоря, палитра должна быть оптимизирована под конкретный рисунок или группу рисунков. Совершенно непонятно, как этого можно достичь "руками".
2. Вот как раз в 80-х упаковка/сжатие изображения применялась очень широко, с чего бы это? (напомню, что типичный ПК имел 64К памяти и 2 МГц процессор при минимум 4 такта на инструкцию, тогда как avr328 - 2К памяти и 16 МГц при 1 такте на инструкцию. Т.е. соотношение производительность_процессора/объем_памяти на тогдашних ПК было примерно в 1000 раз хуже, чем сегодня на avr).
3.1. см. 2.
3.2. У этой темы уже 11 страниц и больше половины из них посвящены тому, как хранить в памяти 1-2-3-4 бита на пиксель, а при выводе перекодировать в 16 бит на пиксель. Т.е. сама тема опровергает Ваше утверждение.
4. А почему, собственно, не к месту? Если уж даже в 90-е этим уже занимались - "без интернета, умных книжек, фотошопа и прочих благ", то сейчас уж сам Бог велел.
соглашусь, но ТСу надо попроще и чтоб быстро. Ну а по поводу AVR, если б у него оперативки было побольше, хотя бы как в спектруме, чтоб ворочать/сжимать/разжимать/конвертировать картинки, то вопросов бы не было, приходиться работать с тем что есть. Даже вшивый спрайтик 32*32*16бит в оперативку не влезет :(
Update: впрочем это мысль, нарисовать online преобразование картинок/цветов с непосредственным выводом на экран, займусь как нибудь.
1. Вообще говоря, палитра должна быть оптимизирована под конкретный рисунок или группу рисунков.
Это путаница возникла из-за двух встречных подходов в теме. Первый это раскрашивание чёрно-белых картинок разными цветами. Второй, это попытка экономного хранения и вывода на экран "полноцветных фото" с возможно их меньшей экзекуцией.
Просто дёргать сразу 2-4 бита из байта не очень могу пока.
Религия не позволяет?
Да, нет, просто тяжко с &,>>,| с битовыми операциями, альтернативы использую редко. Ну и первое направление мне интересней, особенно алгоритмы сжатия массивов "бит-пиксель":)
Да, нет, просто тяжко с &,>>,| с битовыми операциями, альтернативы использую редко. Ну и первое направление мне интересней, особенно алгоритмы сжатия массивов "бит-пиксель":)
Не понимаю, как можно что-то сделать, пользуясь инструментом, которым не умеешь пользоваться. Это все равно, как пытаться писать стихи, зная не все буквы.
IMHO сначала нужно освоить инструмент (хотя бы в минимальной мере), и только потом что-то пытаться при помощи него сделать.
andriano, тема в Песочнице, пусть человек развлекается :)
Я не развлекаюсь, а ищу и проверяю доступные мне варианты.
К примеру на этой картинке я чётко вижу, что алгоритм RLE даст существенную экономию памяти при её хранении, однако запрос "скетч для сжатия-распаковки массива данных по RLE" ничего не даёт.
А зачем её сжимать? Экономить надо когда памяти не хватает, однобитная эта картинка зацмер 2.5 КБ, т е если их10 и больше, тогда стОит заморачиваться.
А алгоритм примитивный, берете строку 128 бит, считаете подряд идущие единички, заиисываете количество и 1,потом нолики, количество и ноль и т д
lilik, все выше приведённые функции должны работать на вашем дисплее, они тупо 16 битный цвет пинают в spi.
ЗЫ. Я думал вы давно уж попробовали....
Ленитесь :)
Цветов маловато в движущейся фигурке, не очень красиво по сравнению с фоновой картинкой, и смысл прозрачных внутренностей не понимаю.
Смысл спрайта чтоб движущаяся фигурка двигалась не в квадратике а аккуратно по фону, т е достаточно прозрачным делать наружную часть картинки.
Ну и кроме подвижных ног было бы не плохо поворачивать лицо в сторону движения.
Цветов маловато в движущейся фигурке, не очень красиво по сравнению с фоновой картинкой, и смысл прозрачных внутренностей не понимаю. Смысл спрайта чтоб движущаяся фигурка двигалась не в квадратике а аккуратно по фону, т е достаточно прозрачным делать наружную часть картинки. Ну и кроме подвижных ног было бы не плохо поворачивать лицо в сторону движения.
Цветов четыре, один это прозрачный, поэтому остаётся три. Прозрачные внутренности, как и вся демонстрация не более чем проверка способа одновременного вывода данных из разных массивов-картинок. Скорости отрисовки хватит чтоб рисовать и движение ног и разворот фигурки или лица от края. В общем можно разрабатывать игры на фоновых картинках, но уже не очень интересно.
вот чем хороша RP2040 ограничение тока на пине можно задать программно (и задается по умолчанию)
надо бы табличку составить по токам подсветки для разных дисплеев, а то так и выжечь пин недолго
вот чем хороша RP2040 ограничение тока на пине можно задать программно (и задается по умолчанию)
надо бы табличку составить по токам подсветки для разных дисплеев, а то так и выжечь пин недолго
вот чем хороша RP2040 ограничение тока на пине можно задать программно (и задается по умолчанию)
надо бы табличку составить по токам подсветки для разных дисплеев, а то так и выжечь пин недолго
Проще поставить эмиттерный повторитель.
если выходного тока хватает, то не стоит, будем иметь уменьшение надёжности системы
...надо бы табличку составить по токам подсветки для разных дисплеев, а то так и выжечь пин недолго
28-29 мА ток подсветки при напряжении 3,3В.
получил пару таких пару красных 1.8 с SD, в красных подсветка поярче, запитываю или от пина или от 3.3 вольта, РАСПИНОВКА ДИСПЛЕЕВ НЕ СОВПАДАЕТ МЕЖДУ СОБОЙ
ну нет....
4 цвета - в каждом байте картинке, т е в каждом пикселе, младшие 2 бита указывают номер цвета в палитре:
соответственно в 16 цветной картинке в каждом байте младшие 4 бита указывают на цвет в палитре:
Строки 2 и 3 заставляют заподозрить, что не совсем оптимально.
И еще: при уменьшении глубины цвета используется один из двух приемов: дизеринг и округление, причем генерация оптимальной палитры для них должна осуществляться по различным алгоритмам. На приведенных картинках используется дизеринг.
Но я тут упоминал о сжатии: сжиматься, конечно, лучше будет картинка с округлением. Причем, возможно, меньший размер получится даже у картинки с большей глубиной цвета.
andriano ,
- палитра рисуется руками, в фотошопе, в коде, в паинте, да где угодно
- оптимизация/упаковка изображения имеет смысл при мощном / жирном МК, тут задача сделать простенькую игрушку, времен 80х годов.
- ваши умные слова про глубины цветов это конечно хорошо, но для персоналок. для МК имеет смысл максимально приготовить контент к выводу на отображаемое устройство
ЗЫ. В 90е годы мы успешно без интернета, умных книжек, фотошопа и прочих благ нынешней цивилизации сами придумывали и писали алгоритмы масштабирования/оптимизации улучшения изображений и прекрасно их применяли. Так что ваши комментарии, извините, не к месту.
Я позволил себе пронуммеровать пункты в цитате, чтобы было понятно, к чему относятся ответы.
1.- палитра рисуется руками, в фотошопе, в коде, в паинте, да где угодно
2- оптимизация/упаковка изображения имеет смысл при мощном / жирном МК, тут задача сделать простенькую игрушку, времен 80х годов.
3- ваши умные слова про глубины цветов это конечно хорошо, но для персоналок. для МК имеет смысл максимально приготовить контент к выводу на отображаемое устройство
4 ЗЫ. В 90е годы мы успешно без интернета, умных книжек, фотошопа и прочих благ нынешней цивилизации сами придумывали и писали алгоритмы масштабирования/оптимизации улучшения изображений и прекрасно их применяли. Так что ваши комментарии, извините, не к месту.
1. Вообще говоря, палитра должна быть оптимизирована под конкретный рисунок или группу рисунков. Совершенно непонятно, как этого можно достичь "руками".
2. Вот как раз в 80-х упаковка/сжатие изображения применялась очень широко, с чего бы это? (напомню, что типичный ПК имел 64К памяти и 2 МГц процессор при минимум 4 такта на инструкцию, тогда как avr328 - 2К памяти и 16 МГц при 1 такте на инструкцию. Т.е. соотношение производительность_процессора/объем_памяти на тогдашних ПК было примерно в 1000 раз хуже, чем сегодня на avr).
3.1. см. 2.
3.2. У этой темы уже 11 страниц и больше половины из них посвящены тому, как хранить в памяти 1-2-3-4 бита на пиксель, а при выводе перекодировать в 16 бит на пиксель. Т.е. сама тема опровергает Ваше утверждение.
4. А почему, собственно, не к месту? Если уж даже в 90-е этим уже занимались - "без интернета, умных книжек, фотошопа и прочих благ", то сейчас уж сам Бог велел.
поставил плюсик :)
соглашусь, но ТСу надо попроще и чтоб быстро. Ну а по поводу AVR, если б у него оперативки было побольше, хотя бы как в спектруме, чтоб ворочать/сжимать/разжимать/конвертировать картинки, то вопросов бы не было, приходиться работать с тем что есть. Даже вшивый спрайтик 32*32*16бит в оперативку не влезет :(
Update: впрочем это мысль, нарисовать online преобразование картинок/цветов с непосредственным выводом на экран, займусь как нибудь.
1. Вообще говоря, палитра должна быть оптимизирована под конкретный рисунок или группу рисунков.
Это путаница возникла из-за двух встречных подходов в теме. Первый это раскрашивание чёрно-белых картинок разными цветами. Второй, это попытка экономного хранения и вывода на экран "полноцветных фото" с возможно их меньшей экзекуцией.
Естественно, весь пиксель - в одном единственном месте, собирать его по частям из разных мест - решение, мягко говоря, странное.
Согласен, поэтому 128*480 :)
То есть вот это:
не по частям из трех разных мест?
:)
Из трёх не совсем разных мест.
Просто дёргать сразу 2-4 бита из байта не очень могу пока.
Даже вшивый спрайтик 32*32*16бит в оперативку не влезет :(
Т.е. для описанного случая достаточно 64 байтов. Раскодируем такими кусочками и отправляем на экран.
Просто дёргать сразу 2-4 бита из байта не очень могу пока.
Просто дёргать сразу 2-4 бита из байта не очень могу пока.
Да, нет, просто тяжко с &,>>,| с битовыми операциями, альтернативы использую редко. Ну и первое направление мне интересней, особенно алгоритмы сжатия массивов "бит-пиксель":)
Да, нет, просто тяжко с &,>>,| с битовыми операциями, альтернативы использую редко. Ну и первое направление мне интересней, особенно алгоритмы сжатия массивов "бит-пиксель":)
IMHO сначала нужно освоить инструмент (хотя бы в минимальной мере), и только потом что-то пытаться при помощи него сделать.
:)
Стихи можно без букв, сочинять. Писать не обязательно, правда память должна быть хорошая.
andriano, тема в Песочнице, пусть человек развлекается :)
andriano, тема в Песочнице, пусть человек развлекается :)
Я не развлекаюсь, а ищу и проверяю доступные мне варианты.
К примеру на этой картинке я чётко вижу, что алгоритм RLE даст существенную экономию памяти при её хранении, однако запрос "скетч для сжатия-распаковки массива данных по RLE" ничего не даёт.
А зачем её сжимать? Экономить надо когда памяти не хватает, однобитная эта картинка зацмер 2.5 КБ, т е если их10 и больше, тогда стОит заморачиваться.
А алгоритм примитивный, берете строку 128 бит, считаете подряд идущие единички, заиисываете количество и 1,потом нолики, количество и ноль и т д
однако запрос "скетч для сжатия-распаковки массива данных по RLE" ничего не даёт.
С другой стороны на такой картинке алгоритм даст проигрыш, а не экономию.
Поэтому и выбираются решения, которые просто работают и те что умеет разработчик.
Дизеринг тоже своеобразная штука, трудно сказать лучше с ним или без него.
Сделал игру. Скорости отрисовки хватает вполне, правда с ухищрением при движении картинок:
Если пренебрегать заставкой игры, то влазит в про мини 168.
добавил рисование графических примитивов и текста
добавил рисование графических примитивов и текста
:)
Теперь мне осталось только дисплей такой купить.
Сделал игрушку с уже 3 подвижными картинками, тоже работает хорошо.
lilik, все выше приведённые функции должны работать на вашем дисплее, они тупо 16 битный цвет пинают в spi.
ЗЫ. Я думал вы давно уж попробовали....
Ленитесь :)
Да, подвис, хочу для себя сформировать общие правила и подходы при создания игрушек на st7735 и уно.
общие правила и подходы
универсальных решений не бывает к сожалению, все зависит от каждой конкретной задачи.
Ну и частные, двигать картинку по картинке, а не по фону.
Вот такой подход аппаратно не реализуем, да и по видео он явно избыточен.
https://arduino.ru/forum/proekty/avrkanoid
Да, подвис, хочу для себя сформировать общие правила и подходы при создания игрушек на st7735 и уно.
Эти два требования взаимно противоречивы.
Общее правило таково: размер оперативной памяти должен существенно превосходить размер видеопамяти.
Очевидно, для пары st7735 и Uno это общее правило не выполняется.
Ну и частные, двигать картинку по картинке, а не по фону.
Вот такой подход аппаратно не реализуем, да и по видео он явно избыточен.
https://arduino.ru/forum/proekty/avrkanoid
Призрак рыцаря.
Цветов маловато в движущейся фигурке, не очень красиво по сравнению с фоновой картинкой, и смысл прозрачных внутренностей не понимаю.
Смысл спрайта чтоб движущаяся фигурка двигалась не в квадратике а аккуратно по фону, т е достаточно прозрачным делать наружную часть картинки.
Ну и кроме подвижных ног было бы не плохо поворачивать лицо в сторону движения.
Цветов четыре, один это прозрачный, поэтому остаётся три. Прозрачные внутренности, как и вся демонстрация не более чем проверка способа одновременного вывода данных из разных массивов-картинок. Скорости отрисовки хватит чтоб рисовать и движение ног и разворот фигурки или лица от края. В общем можно разрабатывать игры на фоновых картинках, но уже не очень интересно.
ВНИМАНИЕ! Заказал дисплеи 1.7" и 1.8" получил, распиновка между ними не совпадает!!!
распиновка между ними не совпадает!!!
а должны? дисплеи же разные.
Да и какая разница какая распиновка.
ВНИМАНИЕ! Заказал дисплеи 1.7" и 1.8" получил, распиновка между ними не совпадает!!!
Типа, так:
ВНИМАНИЕ! Заказал дисплеи 1.7" и 1.8" получил, распиновка между ними не совпадает!!!
Я, помнится, купил 1306 (это OLED 128x64), он i2c - это 4 контакта.
Потом купил, как я думал, такой же. Решил проверить на схеме, собранной для первого.
Оказалось, в распиновке земля и питание - наоборот.
Причем, кроме распиновки они ничем больше не различались.
Пришёл 1,8" TFT. Вывод LCD, судя по всему надо подключить к +3,3V. Нужен ли токоограничивающий резистор?
Пришёл 1,8" TFT. Вывод LCD, судя по всему надо подключить к +3,3V. Нужен ли токоограничивающий резистор?
нет, но лично я предпочитаю подключать на пин с шимом
нет, но лично я предпочитаю подключать на пин с шимом
Пин LCD потребляет ток. Вы используете какую-либо схему между пинами ардуино и дисплея?
нет, но лично я предпочитаю подключать на пин с шимом
Пин LCD потребляет ток. Вы используете какую-либо схему между пинами ардуино и дисплея?
нет, напрямую с пина, ток не измерял, но для светодиода 10ма хватит, а нагрузочная способность пина до 30ма
нет, напрямую с пина, ток не измерял, но для светодиода 10ма хватит, а нагрузочная способность пина до 30ма
Ясно.
Как-то не очень нагружать пины.... Если, кроме дисплея больше ничего, тогда может, и нормально.
На моём дисплее подсветка берёт 28-29 мА.
нет, напрямую с пина, ток не измерял, но для светодиода 10ма хватит, а нагрузочная способность пина до 30ма
Там до 200 мА может быть.
вот чем хороша RP2040 ограничение тока на пине можно задать программно (и задается по умолчанию)
надо бы табличку составить по токам подсветки для разных дисплеев, а то так и выжечь пин недолго
вот чем хороша RP2040 ограничение тока на пине можно задать программно (и задается по умолчанию)
надо бы табличку составить по токам подсветки для разных дисплеев, а то так и выжечь пин недолго
Проще поставить эмиттерный повторитель.
вот чем хороша RP2040 ограничение тока на пине можно задать программно (и задается по умолчанию)
надо бы табличку составить по токам подсветки для разных дисплеев, а то так и выжечь пин недолго
Проще поставить эмиттерный повторитель.
если выходного тока хватает, то не стоит, будем иметь уменьшение надёжности системы
...надо бы табличку составить по токам подсветки для разных дисплеев, а то так и выжечь пин недолго
28-29 мА ток подсветки при напряжении 3,3В.
28-29 мА ток подсветки при напряжении 3,3В.
Во-первых, неплохо бы опубликовать методику и схему измерения.
А во-вторых, провести измерения также в диапазоне хотя бы от 2.97 В до 3.63 В.
Измерял китайским мультиметром ток потребления дисплея с подсветкой и без. Потом составлял разность. Сейчас экранчик забросил пока до новых идей.
...надо бы табличку составить по токам подсветки для разных дисплеев, а то так и выжечь пин недолго
28-29 мА ток подсветки при напряжении 3,3В.
получил пару таких пару красных 1.8 с SD, в красных подсветка поярче, запитываю или от пина или от 3.3 вольта, РАСПИНОВКА ДИСПЛЕЕВ НЕ СОВПАДАЕТ МЕЖДУ СОБОЙ