Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 29

Поздравляю с быстрым релизом!
Пускай это будет не последнее творение под MSX, и с нетерпением жду шедевров под MSX2/2+
Успехов! ;)

Всего голосов 3: ↑3 и ↓0+3
Нужно было бы придумать очень простой вариант кодера.
А не рассматривали CCITT T6? Не требует много ресурсов и эффективно сжимает монохромные изображения. Использовался для факсимильных сообщений.
Всего голосов 1: ↑1 и ↓0+1

Проблема в том, что это не изображение.
В том смысле, что это тайловый режим, и каждый кадр пересылаются в видеопроцессор не тайлы, а таблица имен (так называемая тайловая карта)

Всего голосов 1: ↑1 и ↓0+1
Понял. Мне сначала показалось, что это тайлы декодируются, а это речь уже о картинке из тайлов (точнее из их фрагментов).
Комментарий пока не оценивали0

Экран 32х24 строится из 768 знакомест (тайловая карта таким же размером в байтах), в которые выбираются тайлы из таблицы.
Есть несколько режимов. В простом, есть 256 тайлов, таблица шаблонов которых занимает 2048 байт.
Проблема этого режима в том, что 256 тайлов не покрывают всю таблицу имен уникальными тайлами.
И есть более широкий режим с 768 уникальными тайлами (уникальный набор для каждой 1/3 экрана), которые покрывают весь экран, но размер таблицы шаблонов становится равным 6144 байта (и 2048 байт на таблицу цветности).

Приходится выбирать: пересылать 768 байт в простом режиме, или 6144 - в псевдо-растровом.

Всего голосов 2: ↑2 и ↓0+2
Мне вспоминается Sonic 3D Blast. Там для видео в интро, если память не изменяет, использовали несколько трюков: неполное покрытие экрана, прореженную частоту кадров, черезстрочную развёртку и дублирование строк с помощью прерываний (изображение было сжато по вертикали в два раза).
Всего голосов 1: ↑1 и ↓0+1

Да, MSX2 все это умеет (не MSX1), причем возможностей даже больше чем у NES.
Жаль что таких игр и таких эффектов почти никто не делал.
Платформа позволяет чудеса! :)

Всего голосов 4: ↑4 и ↓0+4

очень интересная первая картинка)

с душой подошли к ней

Всего голосов 2: ↑2 и ↓0+2
Вот прочитал я это, и снова теперь меня мучает эта мысль запустить bad apple на телефоне Siemens CX75, который у меня валяется и до сих пор вполне себе работает (только батарейка почти не держит). Причём не на J2ME — это для слабаков и будет лагать — а нативно, эльфом, напрямую в буфер экрана. Осталось «всего лишь» понять, чем эти эльфы можно компилировать в 2022 году на macOS и дореверсить нужные части прошивки.
Всего голосов 3: ↑3 и ↓0+3

У вас на видео, на 2:00 примерно, ваш голос записался.

Всего голосов 1: ↑1 и ↓0+1

=) это запись с реального демопати Chaos Construction 2021 и там много голосов) но к сожалению, моего там нет...

Всего голосов 1: ↑1 и ↓0+1

Получается, у вас каждый кадр кодируется и отображается независимо, а что, если сделать как в видеокодеках: I-кадры с полной информацией и P-кадры с разницей с предыдущим?

Всего голосов 1: ↑1 и ↓0+1

это проверялось, но получается, что в среднем кадры отличаются друг от друга на 60-100 элементов (тайлов), а в некоторых случаях кадры резко отличаются (когда происходит инверсия например или поворот персонажа), в среднем различие 60-100 байт - и это только данных, но нужно также сохранить адрес где произошло изменение и полученный массив уже очень плохо упаковывается и затраты на её отрисовку больше. И есть ещё один момент: представим основной цикл, мы записываем в VDP (видеопроцессор) адрес в VRAM(видеопамять) по которому мы ходим произвести запись, при последовательной записи этот адрес автоматически увеличивается в VDP, и не приходится его записывать его ещё раз, в случае если адрес случайный, то при каждой записи в VRAM (через VDP) придётся передавать адрес, а это очень затратная операция.

Ну и равномерность потока, так как изображение иногда резко меняется, то важно, что бы очень сильно загруженные моменты видео отрисовывались с такой же скоростью, как и более простые. Поток конечно же не равномерный, в среднем он 120-140 байт, но иногда скачет и до 300 байт на кадр, что бы выровнять этот поток используется буфер в 16кБ, в который подгружается с дискеты по 128 байт в среднем за кадр, так вот буфер на некоторых сценах выбирается на 80%, это когда расходы на отрисовку сцены очень большие и не нет времени вычитывать с дискеты. Мелочей много =) но это интересно =)

Всего голосов 2: ↑2 и ↓0+2
это очень затратная операция.
Понятно, что в скорости профита бы не было (ибо пограничные случае со 100% разницей всё равно будут), но объём это реально могло бы уменьшить. Если, например, 1-2 байта пропускать дольше, чем писать, то можно применять при повторении 3 или более байт.

но нужно также сохранить адрес где произошло изменение
Если есть возможность узнать текущий адрес, то не нужно. Распаковка ведь потоковая. Нужна просто ещё одна команда отрисовки: пропустить N байт (т.е. оставить без изменений).
Всего голосов 1: ↑1 и ↓0+1

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

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

Комментарий пока не оценивали0

Тогда придется на каждую непоследовательную операцию записи в видеопамять, устанавливать адрес записи через порты, например:
ld a, newAddrHigh
out (#99),a
ld a, #94
out (#99),a
ld a, newAddrLow
out (#99),a

Для MSX это 60 тактов и 12 байт на одну запись. Если вдруг найдется кадр с черезбайтовой записью разницы, попадание в частоту кадров будет невыполнимым.


Всего голосов 1: ↑1 и ↓0+1
Если вдруг найдется кадр с черезбайтовой записью разницы
Ну обычно такое не кодируется как разница. Во многих реализациях алгоритмов вообще невозможно указать неэффективные значения повторяемых цепочек — диапазон значений смещён (например, на +3: 0000..1111 — не 0..15, а 3..18).
Комментарий пока не оценивали0

да, смещенный диапазон, к примеру, в распространенном RLE, но в данном случае ориентация была на простоту алгоритма (после переборов нескольких вариантов, которые не давали преимуществ по размеру данных), так как нужно было закодить декодер на Z80, конечно, была реализована модель на более высокоуровневом языке, а потом пренесена на asm z80, сложный алгоритм было бы, возможно, дольше отлаживать.

кстати, получившийся поток сжимается zip с 320кБ, до примерно 260кБ, что говорит о том, что избыточности в нем не так много...

Всего голосов 1: ↑1 и ↓0+1
кстати, получившийся поток сжимается zip с 320кБ, до примерно 260кБ, что говорит о том, что избыточности в нем не так много...
Ну, я бы на deflate не ориентировался, всё-таки он очень чувствителен к типу данных. Лучше на T6 в данном случае смотреть, он изначально заточен на такое. TIFF вроде его поддерживает.

У меня была парочка проектов по извлечению изображений в формате T6 из БД некоторых приложений. Конвертировал в PNG с deflate. Они в итоге на порядок больше весили.
Всего голосов 1: ↑1 и ↓0+1

Я писал в свое время компрессор с потерей качества на zx spectrum

Частотный, по знакоместам 4х4 пиксела (2 байта). Надо сильно ужать видос - оставляешь 16/32/сколько места есть чанков в словаре, и все. Даже 32 чанка уже давали витамин, т.к. 16 бит гарантированно ужимались в 5.

Вероятно, что-то подобное можно сделать для ямы.

Всего голосов 1: ↑1 и ↓0+1
MSX forever!
Чистая и талантливая реализация Bad Apple. А главное все олдскульно чисто, без современных костылей при воспроизведении на исходной платформе.
Так сказать непревзойденный pure-изм. ;)
Всего голосов 2: ↑2 и ↓0+2

Оу, круто!

А у вас случайно в комплекте с Ямахой софта обучающего не было? Того что в классах стоял? Конкретно интересует "Алгоритм"

Всего голосов 1: ↑1 и ↓0+1

есть такой диск: роботландия, вот что в неё входило, может быть "Алгоритм" это одна из этих программ?

Комментарий пока не оценивали0

Судя по названиям не похоже, помню в "Алгоритме" были задачки плана "Переход через дорогу" со списком действий вида "Посмотреть налево", ... - и нужно было их расставить в правильном порядке.

Но это тоже выглядит интересно. Можете куда-то выложить?

Комментарий пока не оценивали0

да, ссылку скину в личку,

ещё мне коллеги поискали, нашли дискету #3 на ней есть такие программы

пакет "информатика-90" =)
Диск #3
Диск #3

Логика - очень классная игра, оказалось совсем её не помнил, что такая была, но на информатике мы её проходили, очень интересная, пойду искать ещё диски информатика... там ещё видимо много чего интересного есть

игра "Логика"
игра "Логика"
Комментарий пока не оценивали0

а можно попросить этим пакетом поделиться? Был раньше в сети, да страничка та давно умерла (

Комментарий пока не оценивали0

загляните к нам в группу телеграмм MSX Inside =) там можно и не только эту дискетку, но и кучу полезностей по MSX

Комментарий пока не оценивали0

А в screen 0 с 80x24 не получится? Разрешение по горизонтали почти в два раза больше и тайлы 6x8.

Всего голосов 1: ↑1 и ↓0+1

если обеспечивать совместимость с MSX1, то все же 40х32, но сама идея классная, так как уменьшение тайла может позволить увеличить детализацию, но, к сожалению, я в свое время до этого не догадался)

но спасибо за наводку)

режимы msx1
режимы msx1
Всего голосов 2: ↑2 и ↓0+2
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr