svofski, извини, но если честно то я не понял как твой ответ соотносится с моим вопросом. Если сжимать по байтово то будет хуже сжиматься?
Вид для печати
svofski, извини, но если честно то я не понял как твой ответ соотносится с моим вопросом. Если сжимать по байтово то будет хуже сжиматься?
Байты битпланов сжимаются хуже, чем байты с парами пикселей.
Что касается сжатия pic2.pic
w256 - 23620
w512 - 22705
w1024 - 21265
w2048 - 20780
Видно, что до 1024 включительно выигрыш от сжатия растет быстрее, чем пенальти от увеличения буфера. Распаковка и getbyte конечно будут медленнее, но если расположить буфер впритык к 8000h, то не сильно медленнее (проверяем знак). Надо ли это делать - не уверен, но если что - резерв по сжатию есть.
Значит я не понял твоего вопроса. Что значит сжимать побайтово? С моей точки зрения все уже и так сжимается побайтово.Цитата:
Сообщение от parallelno
- - - Добавлено - - -
256 все-таки хороший компромисс. Но если dzx0 в принципе через условную компиляцию будет поддерживать разные размеры буферов -- это дело хорошее. Не только ведь картинки сжимать, и не только прогрессивные и не только полноцветные. А если чисто для этой демки, смысла нет, тут уж получилось что получилось по-моему.Цитата:
Сообщение от ivagor
svofski, я имел ввиду данные картинки в том виде в котором она лежит в видеопамяти сжать как линейный кусок памяти от $8000 до $ffff.
- - - Updated - - -
ivagor уже ответил что так хуже сжимается.
parallelno, понятно. Да, так хуже. Кроме того тут не только упаковка, но и эффект.
Обновил все файлы с последними мегаспидапами от ivagor-a. Тут конечно можно разворачивать циклы и все такое, но заметного прироста это не дает.
Мозолят глаз всевозможные push-pop-ы, но я думаю это все от лукавого. Без них только если совсем радикально как-то все менять.
svofski и ivagor, вопрос не по теме как таковой, т.к. я далёк и от железа и от математики, но вы сейчас тут походу одни кто считает такты ;-) Если представить гипотетический однотактовый процессор, которую любую арифметическую и логическую операцию над 1-2 байтами выполняет за 1 такт, а над последовательностью байт за количество байт тактов. То вся ваша аппаратная оптимизация потеряет смысл и перейдёт в плоскость математической оптимизации?
Насчет терминов - я бы все же назвал эти два аспекта "оптимизация реализации" и "оптимизация алгоритма". Оптимизация реализации имеет смысл и для RISC-подобного конвеерного процессора. Пусть базовые команды выполняются в идеале за такт, но с учетом конвеера там возникают конфликты по доступу к исполнительным устройствам. И даже без конфликтов конвеера (или для гипотетического неконвеерного процессора) выбор конкретных команд важен (смотря еще какие команды). Ну а оптимизация алгоритма, или выбор более удачного алгоритма - это как правило более действенное средство, если такие алгоритмы существуют или их можно разработать.
Я про гипотетический процессор, где любая команда выполняется за так, без всяких конвейеров.Цитата:
Сообщение от ivagor
Хочу порекомендовать Retro assembler. Очень много возможностей, встраивается как плагин в VS Code.
https://enginedesigns.net/retroassembler/
Документация
https://enginedesigns.net/download/retroassembler.html
Проект GameNoname написан на нем. Если есть желающие могу рассказать подробнее как и что в нем есть.
Посмотрел слегка. Не увидел IRP/IRPC... грустно.( У меня был проектик в начале 2000-х, 36000 строк, на m80 (1981г!) под CP/M небезизвестного Б.Гейтса. Попытки перевести на что то более другое (современное) не возымели успеха! Многие вообще сыпались на таком объёме (Zilog в т.ч.), у многих не хватало требуемых директив... В общем, забил и успокоился.(
M80, а что такое irp/irpc? Может можно найти замену?
- - - Updated - - -
M80, возможно .generate может заменить irp. А вот для irpc придется писать какой то внешний распарсиватель.
Вот, вот. Считаю m80 классикой, с его макросредствами. При том что хрен-знамо каких годов! Вот нашел L80)
QP/M 2.7 62K
A>dir
POWER .COM : PCPLUS .BIN : XDIR .COM : RUN .COM
ZSID .COM : DIS .COM : XSUB .COM : RDR .COM
L80 .COM : M80 .COM : DDTZ .COM : 1 .bas
BOOTGEN .COM : XLOAD .COM : DEBUGZ .COM : DBGINST .COM
SYSGEN .COM : 2 .bas : 3 .bas : BAS .COM
CONVERT .COM : MBASIC .COM : REBOOT .COM
A>l80
Link-80 3.44 09-Dec-81 Copyright (c) 1981 Microsoft
*
Вот и пусть чего не катят на Билла Гейстса! 1981 год, однако продукт пользуется, кто бы чего не говорил. Какие есть возражения?
У меня нет возражений. :)
В "Болдере" Лебедева, если не ошибаюсь, именно такой алгоритм очистки экрана был.Цитата:
Сообщение от ivagor
Ещё будучи школотой в начале 1990х и, увы, ничего не зная про LFSR - ломал голову, что это у автора игры за хитрый random generator, который не повторяется и гарантированно покрывает все точки экрана.
Добавил ссылки на документацию по AY-3-8910 и КР580ВИ53 в раздел о звуке
Можно поправить ссылку на музон из Арканоида на прямую -- https://svofski.github.io/pretty-8080-assembler/?arkmusЦитата:
Сообщение от parallelno
Извините за полуоффтоп, но я послушал версию по ссылке и ее звук мне не нравится. Если что - критикую себя, т.к. указан там в качестве ответственного за тонгенератор. Берем абсолютно те же ноты svofski и играем семплами через таймер (лучше Arkan_Sample2_NoBuzz2) в v06x (в других эмуляторах не стоит, в крайнем случае в emu80) или на реале - совсем другое дело.
Вариант с семплами безусловно звучит чище, но он занимает почти всю память. А тот, что в рыбе -- крохотный.
В варианте с семплами выполняется переброска семплов из исходных позиций в "выровненные". Это был задел на зацикливание, но в арканоиде это не нужно и можно просто играть семплы по исходным адресам, при этом будет занимать 11 Кб. Да, это много, но все же не вся память. Надо бы вернуться к несемплерному варианту и попробовать улучшить.
Добавил информацию про редктор звуковых эффектов в раздел по звуку.
Читая документацию по AY немного запутался.
В этой доке http://tenroom.ru/scalar/ware/766/index.html указано управление через порты 4, 5, 6
В этой http://tenroom.ru/scalar/ware/765/index.html порты 15, 14
В гигачад плеере тоже используются 15 и 14 порты.
И то и то правильно, эмуляторы поддерживают все варианты? По скорости и удобству второй вариант выглядит удобнее.
Это альтернативный вариант подключения AY, в порт ПУ Вектора.Цитата:
Сообщение от parallelno
Что-то уже не стало хватать квазидиска. :)) Подскажите пожалуйста как читать с диска и есть ли какие-либо тулзы для автоматизации создания дискеты.
v06x создает образ открытого дискетой каталога в виде dirimage.fdd, но там есть нюансы. Попробуй загрузиться с какого-нибудь диска (я попробовал T-72, был под рукой) и подключить каталог в дисковод B: -- из файлов в каталоге соберется образ dirimage.fdd. За всех не скажу, но VV имеет аналогичную фичу.
svofski, спасибо, попробую. А как читать из диска?
Ты имеешь ввиду из своей программы? Это занудно и скучно. Нужен или МикроДОС, у него все функции CP/M доступны, но это для игры совсем печаль-тоска. Или самому писать работу с секторами. Если без файлов, то в общем это совсем несложно -- посмотри работу с портами FDD. Я думаю тебе проще всего разобраться с ними по сорцам эмулятора.Цитата:
Сообщение от parallelno
Но лучше сжать код и данные получше :)
Да из своей программы. Понял. Посмотрю. Спасибо!
Код и данные конечно можно ещё пожать, но много не вииграть мне кажется так как и так все сжато с zx0. Я тут подумал что мне поможет дополнительный квазидиск. Но вот даже не знаю насколько это распространено. Сможет кто-нибудь протестировать на реальном устройстве или нет? А v06x поддерживает два квазидиска?
Нет, но это хороший мотиватор сделать поддержку нескольких квазидисков. В реалах я думаю, что это очень большая редкость. Но ты ведь можешь выпустить игру на картридже в порту ПУ и тогда тебе вообще все будет нипочем.Цитата:
Сообщение от parallelno
Кстати, поддержка ПЗУ в ПУ это тоже то, чего в v06x пока нет и нужен хороший мотиватор, чтобы сделать.
Сложно сказать, сколько их в реале... Подключение двух квази-дисков было сделано давно, чему свидетельствует тест "Дождь", а использоваться в программах такая конструкция стала относительно недавно. Сейчас есть два варианта получения Вектора с двумя КД, первый вариант -- подключение двух "железных" КД, и второй -- прошивка комбодевайса на два КД. У меня есть первый вариант, т.е. подключены два квази-диска.Цитата:
Сообщение от parallelno
Протестить я смогу, например, по мере возможности.Цитата:
Сообщение от parallelno
Занудно добавлю, что судя по Дождю подключали до 8 квазов, интересно бы глянуть, как это выглядело.Цитата:
Сообщение от Improver
Привет!
Какие есть хорошие форматы сжатия индексированных картинок?
Возможно есть такая тема, но я не нашел к сожалению.
вот пример того что хочется сжать
https://i.ibb.co/YkpV7xP/image-intro2-0.png
Пробовал упаковывать индексы цветов по два на байт, затем zx0, получилось 15481 байт. Если сжимать RAW картинку, то получается хуже.
Уверен что можно гораздо лучше. Подскажите пожалуйста как. :v2_dizzy_roll:
- - - Добавлено - - -
Пытаюсь экспериментировать.
увеличение контраста - 13627 байт
https://i.ibb.co/s6S28JF/image-intro2-dither.png
picture upload
без дизеринга - 9853 байт
https://i.ibb.co/ydhZ7WW/image-intro2.png
free image sharing
- - - Добавлено - - -
UPKR упаковшик дает 9026 bytes для подконтрасченой картинки без дизера
Кроме перехода к более мощным упаковщикам еще одно средство - изменение порядка обхода со строк на те или иные квадраты.
А что за квадраты имеются ввиду?Цитата:
Сообщение от ivagor
- - - Updated - - -
У меня есть мысль разбить картинку на тайлы. Тайлы проанализировать на схожесть и реиспользовать тайлы которые похожи. Но явно я переизобретаю какой то велосипед. :)
НапримерЦитата:
Сообщение от parallelno
0 1
2 3
вместо 0 1 2 3
Векторное кодирование. Пробовал для однобитных (двухцветных) картинок, в принципе приемлемо. Сжатие с потерями, а дальше можно пробовать дожимать обычными упаковщиками.Цитата:
Сообщение от parallelno
Спросил ChatGPT4 как ему идея. Он сказал что это похоже на Vector Quantization алгоритм и в частности есть стандартное решение VQ-based Image Compression (VBIC). :)
- - - Добавлено - - -
попробовал. получилось чуть хужеЦитата:
Сообщение от ivagor
2x2 blocks - 10218 bytes
может конечно что-то упустил или ошибся.
Зависит от картинки. Переформулирую более обще: "Кроме перехода к более мощным упаковщикам еще одно средство - изменение порядка обхода". Например для третьей картинки (без дизера) лучше подходит обход по столбцам.Цитата:
Сообщение от parallelno
Прям хочется вернуться к LFSR-Пушкину, но я сдержусь.
Хорошая идея. Но там уже было по столбцам когда я опубликовал тесты.Цитата:
Сообщение от parallelno
Нашел что один из цветов дублится, попробую заменить дубликатный индекс. Интересно насколько поможет.
Помогло на 40 байт :)
- - - Добавлено - - -
Извини, Понкратова-Черного знаю, LFSR-Пушкина не знаю. Кто это? :)Цитата:
Сообщение от svofski
- - - Добавлено - - -
После того как отсортировал индексы по яркости, UPKR сжал до 8636 bytes (26.35498%)