Или вот такой вариант под 8 цветов. К сожалению на компе, за которым я сейчас, нет матлаба, а без него как без рук. Пришлось использовать для транзита BMP2SCR с разрешением 256x192. В 384x256 получилось бы лучше.
Или вот такой вариант под 8 цветов. К сожалению на компе, за которым я сейчас, нет матлаба, а без него как без рук. Пришлось использовать для транзита BMP2SCR с разрешением 256x192. В 384x256 получилось бы лучше.
Последний раз редактировалось ivagor; 29.01.2019 в 18:18. Причина: удалил вложения в связи с выкладыванием вариантов с разрешением 384x256
Если нужно выводить в один прием и сверху-вниз, то можно использовать буфер на несколько строк, для примера в parrot3lines.zip - буфер на 3 строки.
Живая загрузка - это хорошо, на CPC есть демка - Breaking Baud. Может и на спеке такое есть, я не в курсе.
Попробовал несколько вариантов конверсии в 8 цветов. Полностью не один не устраивает, разве что аляповато-грубый parrot8c_384 понравился насыщенностью. Для сравнения рядом картинка DDp (она растянута по горизонтали чуть сильнее, чем моя).
Последний раз редактировалось ivagor; 02.02.2019 в 15:04. Причина: удалил вложения
Я в код не лазил, и так и не понял в каком формате хранятся эти картинки. Почему они занимают даже меньше экранного ОЗУ, потому что предварительно чем-то запакованы?
Что касается самих картинок. В 8 цветов картинка безусловно ярче и контрастнее, но вместе с тем в глаза бросаются грубые рваные края в местах перехода цветов.
Мне кажется, что получить идеальную картинку, при ограничении на только чёрный цвет бумаги, будет очень проблематично. Но подумать над алгоритмом всё-таки стоит. В своём конверторе спектрумовской графики я зажигаю пиксели и крашу их в тот цвет (чернила или бумаги), пикселей цвета которого больше в обрабатываемом байте (Optimization On). Думаю, что это самое очевидное, что приходит в голову, но на всякий случай поинтересуюсь, использовал ли ты подобный метод при конвертировании цветных картинок? А может быть стоит как-то через строчку красить пиксели? Например, если в верхнем байте чередуются чёрные и красные пиксели, а в нижнем байте желтые и чёрные, то на итоговой картинке создаётся иллюзия, что чередуются красные и жёлтые пиксели.
С уважением, Станислав.
Картинки и у DDp и у меня упакованы MegaLZ.
parrot8c_384 получен с аналогичным преобразованием на финальной стадии. Но важно и что было до этого, какой дизеринг, какая фильтрация (если была). Еще я с гаммой и другими параметрами экспериментировал. У DDp дизеринг скорее всего какой-то вариант error diffusion.
Последний раз редактировалось ivagor; 29.01.2019 в 15:03. Причина: убрал спекуляцию насчет гаммы
Слегка подкрутил параметры преобразования и стало получше. Слева - "новый" вариант, справа - "старый".
По поводу определения значений "переднего плана" и атрибутов. Возможен подход с преобразованием в YUV (или в похожую систему), фильтрацией цветоразностных для уменьшения их пространственного разрешения и значения переднего плана получаем из Y, а атрибутов из YUV.
Немного капитанства. Для конверсии на MX можно использовать BMP2SCR, режимы MLT/Hicolor modes. Да, разрешение и цветовые возможности MX не будут раскрыты на 100%. Зато есть редактор для творческих личностей.
Слушайте а ведь просто же приколхозить прерывание по кадровому импульсу? Было бы по человечески. Отключалось бы через (а там есть своб бит в 55?) 55 скажем
Или чуть менее человечно - бит статуса в 55 который на обратном рейтресе 1
- - - Добавлено - - -
Мне вообще непонятна эта страсть отечественных дизайнов эмэйчур компов не иметь кадрового прерывания
Как заговор какой прямо, чтобы игр хороших не писали ;-)
Впрочем и 2мгц 8080 при 16 кб буфера кадра это не про скроллеры и тд
Эх почему не было в СССР советского VDP типа TMS99 или хотя бы текстового контроллера типа мотороллы 6845 или как там ее звали
medvdv, хороших игр не писали не потому что процессор 8080 и нет прерываний-)
а просто потому что не писали, и содрать не у кого было
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)