Комментарии 29
Поздравляю с быстрым релизом!
Пускай это будет не последнее творение под MSX, и с нетерпением жду шедевров под MSX2/2+
Успехов! ;)
Нужно было бы придумать очень простой вариант кодера.А не рассматривали CCITT T6? Не требует много ресурсов и эффективно сжимает монохромные изображения. Использовался для факсимильных сообщений.
Проблема в том, что это не изображение.
В том смысле, что это тайловый режим, и каждый кадр пересылаются в видеопроцессор не тайлы, а таблица имен (так называемая тайловая карта)
Экран 32х24 строится из 768 знакомест (тайловая карта таким же размером в байтах), в которые выбираются тайлы из таблицы.
Есть несколько режимов. В простом, есть 256 тайлов, таблица шаблонов которых занимает 2048 байт.
Проблема этого режима в том, что 256 тайлов не покрывают всю таблицу имен уникальными тайлами.
И есть более широкий режим с 768 уникальными тайлами (уникальный набор для каждой 1/3 экрана), которые покрывают весь экран, но размер таблицы шаблонов становится равным 6144 байта (и 2048 байт на таблицу цветности).
Приходится выбирать: пересылать 768 байт в простом режиме, или 6144 - в псевдо-растровом.
очень интересная первая картинка)
с душой подошли к ней
У вас на видео, на 2:00 примерно, ваш голос записался.
Получается, у вас каждый кадр кодируется и отображается независимо, а что, если сделать как в видеокодеках: I-кадры с полной информацией и P-кадры с разницей с предыдущим?
это проверялось, но получается, что в среднем кадры отличаются друг от друга на 60-100 элементов (тайлов), а в некоторых случаях кадры резко отличаются (когда происходит инверсия например или поворот персонажа), в среднем различие 60-100 байт - и это только данных, но нужно также сохранить адрес где произошло изменение и полученный массив уже очень плохо упаковывается и затраты на её отрисовку больше. И есть ещё один момент: представим основной цикл, мы записываем в VDP (видеопроцессор) адрес в VRAM(видеопамять) по которому мы ходим произвести запись, при последовательной записи этот адрес автоматически увеличивается в VDP, и не приходится его записывать его ещё раз, в случае если адрес случайный, то при каждой записи в VRAM (через VDP) придётся передавать адрес, а это очень затратная операция.
Ну и равномерность потока, так как изображение иногда резко меняется, то важно, что бы очень сильно загруженные моменты видео отрисовывались с такой же скоростью, как и более простые. Поток конечно же не равномерный, в среднем он 120-140 байт, но иногда скачет и до 300 байт на кадр, что бы выровнять этот поток используется буфер в 16кБ, в который подгружается с дискеты по 128 байт в среднем за кадр, так вот буфер на некоторых сценах выбирается на 80%, это когда расходы на отрисовку сцены очень большие и не нет времени вычитывать с дискеты. Мелочей много =) но это интересно =)
это очень затратная операция.Понятно, что в скорости профита бы не было (ибо пограничные случае со 100% разницей всё равно будут), но объём это реально могло бы уменьшить. Если, например, 1-2 байта пропускать дольше, чем писать, то можно применять при повторении 3 или более байт.
но нужно также сохранить адрес где произошло изменениеЕсли есть возможность узнать текущий адрес, то не нужно. Распаковка ведь потоковая. Нужна просто ещё одна команда отрисовки: пропустить N байт (т.е. оставить без изменений).
никаких операций сравнения, дополнительного суммирования, обращения к памяти в основном цикле выполнять нельзя, так как все очень быстро должно выполняться, несмотря на то, что в статье я написал очень упрощенный алгоритм, основной цикл отображения данных сильно заоптимизирован в борьбе за такты процессора...
однозначно можно и нужно перебирать алгоритмы упаковки и распаковки, возможно они будут лучше, компактнее, в данной реализации после нескольких попыток был оставлен описанный в статье вариант
Тогда придется на каждую непоследовательную операцию записи в видеопамять, устанавливать адрес записи через порты, например:ld a, newAddrHigh
out (#99),a
ld a, #94
out (#99),a
ld a, newAddrLow
out (#99),a
Для MSX это 60 тактов и 12 байт на одну запись. Если вдруг найдется кадр с черезбайтовой записью разницы, попадание в частоту кадров будет невыполнимым.
Если вдруг найдется кадр с черезбайтовой записью разницыНу обычно такое не кодируется как разница. Во многих реализациях алгоритмов вообще невозможно указать неэффективные значения повторяемых цепочек — диапазон значений смещён (например, на +3: 0000..1111 — не 0..15, а 3..18).
да, смещенный диапазон, к примеру, в распространенном RLE, но в данном случае ориентация была на простоту алгоритма (после переборов нескольких вариантов, которые не давали преимуществ по размеру данных), так как нужно было закодить декодер на Z80, конечно, была реализована модель на более высокоуровневом языке, а потом пренесена на asm z80, сложный алгоритм было бы, возможно, дольше отлаживать.
кстати, получившийся поток сжимается zip с 320кБ, до примерно 260кБ, что говорит о том, что избыточности в нем не так много...
кстати, получившийся поток сжимается zip с 320кБ, до примерно 260кБ, что говорит о том, что избыточности в нем не так много...Ну, я бы на deflate не ориентировался, всё-таки он очень чувствителен к типу данных. Лучше на T6 в данном случае смотреть, он изначально заточен на такое. TIFF вроде его поддерживает.
У меня была парочка проектов по извлечению изображений в формате T6 из БД некоторых приложений. Конвертировал в PNG с deflate. Они в итоге на порядок больше весили.
Я писал в свое время компрессор с потерей качества на zx spectrum
Частотный, по знакоместам 4х4 пиксела (2 байта). Надо сильно ужать видос - оставляешь 16/32/сколько места есть чанков в словаре, и все. Даже 32 чанка уже давали витамин, т.к. 16 бит гарантированно ужимались в 5.
Вероятно, что-то подобное можно сделать для ямы.
Чистая и талантливая реализация Bad Apple. А главное все олдскульно чисто, без современных костылей при воспроизведении на исходной платформе.
Так сказать непревзойденный pure-изм. ;)
Оу, круто!
А у вас случайно в комплекте с Ямахой софта обучающего не было? Того что в классах стоял? Конкретно интересует "Алгоритм"
есть такой диск: роботландия, вот что в неё входило, может быть "Алгоритм" это одна из этих программ?
Судя по названиям не похоже, помню в "Алгоритме" были задачки плана "Переход через дорогу" со списком действий вида "Посмотреть налево", ... - и нужно было их расставить в правильном порядке.
Но это тоже выглядит интересно. Можете куда-то выложить?
да, ссылку скину в личку,
ещё мне коллеги поискали, нашли дискету #3 на ней есть такие программы
пакет "информатика-90" =)
Логика - очень классная игра, оказалось совсем её не помнил, что такая была, но на информатике мы её проходили, очень интересная, пойду искать ещё диски информатика... там ещё видимо много чего интересного есть
А в screen 0 с 80x24 не получится? Разрешение по горизонтали почти в два раза больше и тайлы 6x8.
Bad Apple для MSX на CC'21