Программирование

[ivagor]

Про упрощатель у меня есть не особо оригинальная мысль:
1) делим картинку на квадратные или прямоугольные блоки
2) в рамках блока оставляем 2 или 4 цвета из 16
Тут несколько степеней свободы или точек приложения сил для экспериментов
1) какие размеры блоков выбрать
2) сколько цветов в рамках блока
3) как выбирать цвета (понятно, что тут с потерями) когда выбор неоднозначен
Из упаковщиков я бы, по крайней мере для начала, ориентировался на salvador. Он умеет сжимать под кольцевой буфер заданного размера и для буфера 256 байт есть готовый распаковщик zx0.
Для примера: пусть блоки 8x8, в блоках 4 цвета из 16. Картинка 256x256: 16 Кб пиксели, 2 Кб цвета блоков. Т.е. в примере из 32 Кб сократили до 18 и это еще без сжатия "обычным" упаковщиком. Другое дело, как будет выглядеть такая упрощенная картинка, возможно, что совершенно неприемлемо.
Вариант с блоками можно развить до иерархического, опять же надо пробовать, возможно это дурацкая идея, а может где-то хорошо подойдет.

[Advertiser]

[Improver]

Про упрощатель у меня есть не особо оригинальная мысль:
1) делим картинку на квадратные или прямоугольные блоки
2) в рамках блока оставляем 2 или 4 цвета из 16

А что если картинку сначала разделить на четыре плоскости по цветам? А потом уже делить на монохромные блоки, при этом сплошная заливка областей картинки даст хорошее сжатие...

[parallelno]

А что ты думаешь про результаты упрощателя которые я представил выше?

[ivagor]

Если сравнивать с беспотерьным вариантом, то результаты интересные. Но, как я ранее написал, считаю, что надо сравнивать с целевыми значениями (сколько места и сколько картинок требуется) и с использованием чего-то менее сурового, чем upkr.

[ivagor]

В принципе одноцветные блоки должен дожимать упаковщик. Но есть другой вариант - если цветов на блок 4, то всего комбинаций 65536, а для картинки 256x256 будут востребованы максимум 1024. Часть комбинаций можно задействовать для индикации неких специфичных блоков, например одноцветных. Для палитровых картинок разбиение на плоскости в общем случае вряд ли много что даст, разве что в связке с оптимизацией палитры (перестановками).

[Improver]

Для палитровых картинок разбиение на плоскости в общем случае вряд ли много что даст

Тут надо просто поставить эксперимент, как будут сжиматься теми же упаковщиками те же картинки, но разбитые по плоскостям. А если будет последовательное заполнение 32кб, это может упростить (и ускорить) распаковщик?

[ivagor]

А если будет последовательное заполнение 32кб, это может упростить (и ускорить) распаковщик?

Конечно, просто распаковываем в экран распаковщиком общего назначения. Но по пикселям лучше сжимает.

[svofski]

Когда делал Бадап, столкнулся с тем, что надо как-то делать образ диска с файлами. Есть чудесная утилита SteinBlume и плюгины к древним фарам, но все они интерактивные. А мне надо, чтобы все было терминально угрюмо и из командной строки. Поэтому я взял давно уже написанный код из vector06js и завернул его в отдельную утилиту, которая позволяет взять рыбу fdd по вкусу и положить в нее свои файлы.

Написано на js, для запуска нужна node (npm не нужен). exe можно сделать если будет спрос, но мне самому не нужно и пока никто не просил.

https://github.com/svofski/v06c-fddutil/

- - - Добавлено - - -

P.S. Это по-моему самая толковая тема про разработку для Вектора. Может быть можно сделать ее Важной?

[parallelno]

Добавил информацию про тайминги кадра.

[parallelno]

Добавил информацию о портах.