Есть люди, у которых ПК в аптайме по нескольку месяцев (от обновления до обновления), и всё это время всякие IDE, браузеры и прочие программы запущены с момента загрузки ПК 🙂
Думаете, без потерь получится меньше 20 байт на кадр в среднем получить (в том же разрешении и с тем же фреймрейтом)? Допустим, даже если дизеринг отключить, сделав картинку менее "шумной"; запомнить временные точки инвертирования цветовой палитры в видео (иначе невыгодно будет спускаться в одноцветные блоки)... Не верится) upd. Но вообще затея интересная, если не лень будет, хотя бы сожму просто для понимания масштабов, мб и правда лучше будет таким алгоритмом воспользоваться.
Чуть выше я лихо упомянул серию алгоритмов LZ**, они обращаются к распакованным данным и требуют их буферизации в оперативе, чтобы можно сделать окно достаточно большим, а в меге её всего 2 килобайта (а я музыку ещё планировал прикрутить). Но не упомянул про обычное кодирование по Хаффману. Сейчас каждый блок весит по байту, но самыми популярными с огромным отрывом являются полностью чёрный и полностью белый, для которых, учитывая разрыв, Хаффман, скорее всего, выдаст двухбитовые коды, что примерно раза в полтора уменьшит размер данных (скажем, с текущих 30 килобайт до 20). Освободившихся 10 килобайт с головой хватит для музыки, быть может даже фреймрейт получится поднять немного.
Вы буквально описали схему, которую я использовал) Только фокус ещё в выборе тех самых 256 ключевых блоков, после кластеризации детали гораздо лучше выглядят.
Да и просто это неспортивно — использовать внешнюю память, когда на плате установлены безумные 32 мегабайта памяти,
Так подумал и я... и сжал с потерями Bad Apple в 7 FPS в разрешении 40x32 и впихнул данные видео и кодек целиком в 32 килобайта памяти atmega328p / Arduino UNO. Данные ещё можно сжать в два раза с помощью LZ77, оставив несколько килобайт под синтезатор и данные музыки. Вот только статью об этом всё руки не доходят написать...
как в старые добрые времена зависишь от сторонних dll и без них даже не скомпилируется
сложить рядом с исходниками нужные бинарные либы
можете, пожалуйста, прояснить этот момент? Я, конечно, пока ненастоящий растовчанин, но статическая линковка Rust сейчас является его и плюсом (всё своё ношу с собой) и минусом (бинари довольно крупные получаются) одновременно, а все crates собираются по месту из исходников. То есть, испытал абсолютно противоположный вашему опыт.
Про системы сборки: для C и C++ стараюсь использовать CMake, где возможно (если проект сам в себе; если либы поддерживают или легко адаптируются под CMake), который уже генерирует Makefile или Ninja, где как лучше, а также compile_commands.json для clangd. С ним удобнее поддерживать зависимости в порядке и в целом проще иерархию проекта строить.
Сейчас активно пробую Rust, там вообще уже всё предусмотрено - и пакетный менеджер, и система сборки, и статический анализатор, и даже тестирование; пока моё мнение складывается не в пользу C/С++ (по большей части).
Я писал код в таком режиме несколько лет, без всяких intellisense и статических анализаторов - просто в vim без плагинов: пишешь несколько сотен строк, потом (зачастую) читаешь портянку, которую выдаёт компилятор, потом исправляешь; и так в цикле, пока не будет ошибок и предупреждений; а ведь потом ещё отлаживать. Опыт не самый лучший, открыл для себя vscode, стало проще (да, жрущий электрон с плагинами на джаваскрипте) - всё в реальном времени: пишешь, сразу же исправляешь косяки свои; и тут же в git выделяешь нужные изменения, коммитишь и т.д.
Метод, которому учат большинство детей в школе, — длинное умножение — включает в себя много шагов с отдельными произведениями, которые нужно записывать и позже комбинировать.
вот наступит чебурнет и куда будет стучаться git или apt
Насчёт пакетов - хотя бы в mirror.yandex.ru, например. Если не обращаться к белым спискам, то есть ещё и, внезапно, BitTorrent, только в случае зеркалирования репозитортев он будет не под пиратским флагом :)
если быть точным, то без ручной пересборки некоторых пакетов (mesa, gtk3, gtk4, qt6-base и пр.), в зависимостях которых есть либы обоих протоколов, у вас не выйдет сделать отдельно иксовую или отдельно wayland сборку, только солянку.
Может немного оффтоп, но как думаете, реально ли уместить в 512 байт (максимум, 1 килобайт) инструкций AVR хотя бы двухканальный синтезатор (шум и меандр) и в ещё 1 килобайт мелодию минуты на 3 (несколько небольших партий, которые повторяются в течение всей мелодии)? Сжимаю Bad Apple, видео вместе с декодером уже умещаются в 32 килобайта с выводом на дисплей (40x32, 7 FPS), думаю, стоит ли ещё музыку приделать. Модулировать планирую в половину амплитуды динамика через ШИМ за неимением ЦАП.
Извините
... пока оба операнда отличны от NaN :)
только для целочисленного деления. В случае чисел с плавающей точкой существуют ±inf и NaN.
Есть люди, у которых ПК в аптайме по нескольку месяцев (от обновления до обновления), и всё это время всякие IDE, браузеры и прочие программы запущены с момента загрузки ПК 🙂
Думаете, без потерь получится меньше 20 байт на кадр в среднем получить (в том же разрешении и с тем же фреймрейтом)? Допустим, даже если дизеринг отключить, сделав картинку менее "шумной"; запомнить временные точки инвертирования цветовой палитры в видео (иначе невыгодно будет спускаться в одноцветные блоки)... Не верится) upd. Но вообще затея интересная, если не лень будет, хотя бы сожму просто для понимания масштабов, мб и правда лучше будет таким алгоритмом воспользоваться.
Чуть выше я лихо упомянул серию алгоритмов LZ**, они обращаются к распакованным данным и требуют их буферизации в оперативе, чтобы можно сделать окно достаточно большим, а в меге её всего 2 килобайта (а я музыку ещё планировал прикрутить). Но не упомянул про обычное кодирование по Хаффману. Сейчас каждый блок весит по байту, но самыми популярными с огромным отрывом являются полностью чёрный и полностью белый, для которых, учитывая разрыв, Хаффман, скорее всего, выдаст двухбитовые коды, что примерно раза в полтора уменьшит размер данных (скажем, с текущих 30 килобайт до 20). Освободившихся 10 килобайт с головой хватит для музыки, быть может даже фреймрейт получится поднять немного.
Вы буквально описали схему, которую я использовал) Только фокус ещё в выборе тех самых 256 ключевых блоков, после кластеризации детали гораздо лучше выглядят.
Влезает тютелька в тютельку (32720 байт).
Так подумал и я... и сжал с потерями Bad Apple в 7 FPS в разрешении 40x32 и впихнул данные видео и кодек целиком в 32 килобайта памяти atmega328p / Arduino UNO. Данные ещё можно сжать в два раза с помощью LZ77, оставив несколько килобайт под синтезатор и данные музыки. Вот только статью об этом всё руки не доходят написать...
можете, пожалуйста, прояснить этот момент? Я, конечно, пока ненастоящий растовчанин, но статическая линковка Rust сейчас является его и плюсом (всё своё ношу с собой) и минусом (бинари довольно крупные получаются) одновременно, а все crates собираются по месту из исходников. То есть, испытал абсолютно противоположный вашему опыт.
Почти как привычка сохранять файл у некоторых)
Про системы сборки: для C и C++ стараюсь использовать CMake, где возможно (если проект сам в себе; если либы поддерживают или легко адаптируются под CMake), который уже генерирует Makefile или Ninja, где как лучше, а также compile_commands.json для clangd. С ним удобнее поддерживать зависимости в порядке и в целом проще иерархию проекта строить.
Сейчас активно пробую Rust, там вообще уже всё предусмотрено - и пакетный менеджер, и система сборки, и статический анализатор, и даже тестирование; пока моё мнение складывается не в пользу C/С++ (по большей части).
Я писал код в таком режиме несколько лет, без всяких intellisense и статических анализаторов - просто в vim без плагинов: пишешь несколько сотен строк, потом (зачастую) читаешь портянку, которую выдаёт компилятор, потом исправляешь; и так в цикле, пока не будет ошибок и предупреждений; а ведь потом ещё отлаживать. Опыт не самый лучший, открыл для себя vscode, стало проще (да, жрущий электрон с плагинами на джаваскрипте) - всё в реальном времени: пишешь, сразу же исправляешь косяки свои; и тут же в git выделяешь нужные изменения, коммитишь и т.д.
...или просто использовать статический анализатор
почему-то порвало с этого
В голове:
27*9 = 180+63 = 243
32*9 = 270+18 = 288
16*12 = 160+32 = 192
Насчёт пакетов - хотя бы в mirror.yandex.ru, например. Если не обращаться к белым спискам, то есть ещё и, внезапно, BitTorrent, только в случае зеркалирования репозитортев он будет не под пиратским флагом :)
стимпанк, получается
так ведь на пониженной надо))
На современных великах пониженная есть
Причём иногда достаточно сильная
Интересно, как бы выглядела органическая коробка передач :D
Как вам такие дороги? :)
если быть точным, то без ручной пересборки некоторых пакетов (mesa, gtk3, gtk4, qt6-base и пр.), в зависимостях которых есть либы обоих протоколов, у вас не выйдет сделать отдельно иксовую или отдельно wayland сборку, только солянку.
вам не кажется расточительным создавать файл лишь ради того, чтобы через мгновение удалить? или он создаётся в tmpfs?
Может немного оффтоп, но как думаете, реально ли уместить в 512 байт (максимум, 1 килобайт) инструкций AVR хотя бы двухканальный синтезатор (шум и меандр) и в ещё 1 килобайт мелодию минуты на 3 (несколько небольших партий, которые повторяются в течение всей мелодии)? Сжимаю Bad Apple, видео вместе с декодером уже умещаются в 32 килобайта с выводом на дисплей (40x32, 7 FPS), думаю, стоит ли ещё музыку приделать. Модулировать планирую в половину амплитуды динамика через ШИМ за неимением ЦАП.