Утилита DaDither: конвертация изображений (Страница 3 из 4)

Эти видео сняты с разной частотой кадров, где мерцание - 60 к/с, где нет 25 к/с.
Получается на втором видео, эффект гигаскрин должен быть идеально выражен. Но вместо квадратиков на записи артефакты. В реальности, на экране квадраты как в эмуляторе и на первом видео.

Один и тот же синтетический цвет может быть получен разными вариантами. Например серый (R=0.5, G=0.5, B=0.5) может быть получен как

1) ((R=0, G=0, B=0) + (R=1, G=1, B=1)) / 2
2) ((R=1, G=0, B=0) + (R=0, G=1, B=1)) / 2
3) ((R=0, G=1, B=0) + (R=1, G=0, B=1)) / 2
4) ((R=0, G=0, B=1) + (R=1, G=1, B=0)) / 2

При этом из этих четырех вариантов наименьшее мерцание имеет вариант 3 (зеленый+магента), поэтому варианты 1, 2 и 4 никогда не используются.

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

Я подправлю алгоритм, он чуть уменьшит мерцание, но все равно некоторые синтетические цвета будут формироваться не из "родных" цветов, а из тех, что дают меньшее мерцание.

Update

Подправил алгоритм. Теперь формируется такой кадр:

Так, стоп. Внимательное изучение матчасти показало, что моя реализация гигаскрина, мягко говоря, топорная. Страницами надо "хлопать" в разы чаще. Беру тайм-аут на уточнение некоторых деталей и переделку.

Лучшее на свете описание режимов отображение Apple][

Все описание в документе - относится к оригинальным Apple][. И набор цветов у них свой. С уточнением что 10 и 5 цвет выглядят на реальной машине одинаково, хотя в эмуляторе AppleWin искусственно они по разному отображаются (тоже наверное имеет право на жизнь). Подробности в сообщении 3 тут: http://forum.agatcomp.ru//viewtopic.php?id=135
Вероятно в таком виде инфа полезна для отдельной вкладки "Apple" утилиты.

Следующая инфа,  вероятно полезна для дополнения вкладки "АГАТ" утилиты:
У агат есть только HiRes, других графических эпловских режимов нет. Причём, по терминологии выше, он цифровой и с четкими горизонтальными границами пикселей. Причём заливки нет, т.е. всегда полосатое.
И цвета, "подключают для себя" цвета #0, #1, #2, #4, #5, #7 из основного набора, как в таблице тут:
http://agatcomp.ru/agat/Hardware/Monic.shtml
Т.е. хоть как-то картинка похожа будет на оригинальную эпл по цветам.
Однако по совокупности изменений режима, конечная картинка может выглядеть несколько иначе на вид.
Поэтому я в описании хвоста отделил эпловский HIRES от агатовского.
http://agatcomp.ru/agat/PCutils/EXIF.shtml

Update:
- Режим 16 Colors по умолчанию.
- Возможность добавления комментария.
----
Я не имею ни одной идеи, как автоматически конвертировать во что-то более менее адекватное в Hires, поэтому отложено на неопределенное будущее.
----
Плагин для TotalCommander для просмотра fil файлов с графикой.

В окне не осталось свободного места (выберите gigascreen и увидите).

В окне нет свободного пространства для размещения "12 строчек по 16 символов".

У меня не такой большой монитор. И окно в текущем виде занимает почти всю высоту монитора. А бывают мониторы и еще меньше.

Гигаскрин2 от создателя гигаскрин1 :)

Как оказалось, на Спектрумах гигаскрин делается не переключением кадров, а переключением строк. В связи с этим пришлось гоняться за телевизионным лучом, программку переписать полностью (пару раз) и заодно словить кучу самых разных проблем.

Проблема 1: частоты. В отличие от Спектрума, у Агата ДК и процессор работают от разных тактовых генераторов. Поэтому надо не просто выждать нужные 65,3 такта процессора, но еще и принять меры на случай уползания момента переключения. Ясно, что дробное число тактов отмерить нельзя, поэтому момент переключения постепенно сползает к началу гасящего импульса. Но за 8 строк он далеко не уползает и остается внутри гасящего импульса, а там приходит новое прерывание и все заново синхронизируется. Тем не менее, с кварцем 14 МГц момент переключения поползет вперед и переключение будет где-то посреди строки.

Проблема 2: время вызова обработчика. Процессор может выполнять какую-то инструкцию (до 7 тактов), плюс сам вызов занимает 7 тактов, плюс команда STA производит запись только спустя 3 такта. Итого задержка от начала гасящего импульса может достигать 17 тактов, в то время как сам гасящий импульс имеет длительность 16 мкс.

В связи с этим пришлось отказаться от штатного способа установки обработчиков через адреса $36F, $37E, потому что обработка прерываний в DOS занимает слишком много времени. Кроме того, основной код программы не должен содержать инструкций длинее 5 тактов :) У меня основной код - это цикл опроса клавиатуры, поэтому там все нормально. Но вообще, делать что-то полезное одновременно с показом гигаскрина довольно трудно, потому что процессор 80% времени проводит внутри обработчиков прерываний.

Проблема 3: IRQ возникает в начале 7, 15, 23 и т.д. строк. Со строками 0-6 возникает конфликт двух обработчиков: в 311 строке предыдущего кадра вызывается IRQ, а в нулевой строке его перешибает NMI. Пришлось изменить код еще раз и заставить обработчик IRQ во время кадрового гасящего импульса быстренько выходить, а NMI научить переключать строки. Когда это не заработало так, как ожидалось, то выяснилось, что NMI вызывается синхронно со строчным гасящим импульсом, а не с началом отображения строки. (Владимир выкладывал картинку, но я эту тонкость с импульсами прохлопал.)

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

Мерцание, к сожалению, все равно ощущается, хотя, на мой взгляд, умеренное.

Я смотрел здесь и здесь.

В частности, вот этот абзац:

Как раз Игорь говорил про "волнение над отмелью".

Формально - да, что при переключении кадров, что при переключении строк на экран выводится два полукадра с отличающейся картинкой. Но, видимо, на заметность мерцания влияет размер областей одного цвета.

Я думаю, что в начале 90-х утилиты, формирующие шахматку, были не у всех. И если для гигаскрина использовались картинки с большими областями одинакового цвета, то построчное переключение давало меньшее мерцание, чем покадровое.

В случае Агатовского режима 128x128 происходит похожая ситуация: каждый пиксель занимает две строки (и в ширину он достаточно большой). Поэтому переход к построчному переключению приводит к уменьшению размера пикселя - фактически, получается режим 128x256 (и на экране, в отличие от эмулятора, это видно).

Я согласен, в режиме 256x256 построчное переключение, скорее всего, будет выглядеть хуже, потому что в смежных строках окажутся одинаковые строки шахматки. Но и режим 256x256 на Агате менее интересен для гигаскрина, потому что цветов всего 4. Ну, в теории 5, если учесть аппаратные палитры, но это не сильно помогает, потому что цвета первичные и их наложение будет давать заметное мерцание.

Понятно. В случае zx это переключение экранов каждую строку нужно как раз для того, что бы перевести соседние строки в противофазу.

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

Правильно ли я понимаю, что видиосистема читает память/палитру дважды для каждой строки? Первый раз для верхней части строки, и второй раз для нижней части? И в вашем алгоритме происходит переключение страниц не только при смене строки, но и в момент перехода от верхней части к нижней части строки?

Если да, то тогда имеем следующую исходную ситуацию (Т - темный пиксель, Я - яркий пиксель, с учетом их физического размера):

   Фрейм 0       Фрейм 1
0: ТТЯЯТТЯЯ...   ЯЯТТЯЯТТ... 
0: ТТЯЯТТЯЯ...   ЯЯТТЯЯТТ...
1: ЯЯТТЯЯТТ...   ТТЯЯТТЯЯ...
1: ЯЯТТЯЯТТ...   ТТЯЯТТЯЯ...
2: ТТЯЯТТЯЯ...   ЯЯТТЯЯТТ...
2: ТТЯЯТТЯЯ...   ЯЯТТЯЯТТ...
   ...           ...

И при переключении каждую строку результат будет таким:

   Фрейм 0       Фрейм 1
0: ТТЯЯТТЯЯ...   ЯЯТТЯЯТТ... 
0: ЯЯТТЯЯТТ...   ТТЯЯТТЯЯ...
1: ЯЯТТЯЯТТ...   ТТЯЯТТЯЯ...
1: ТТЯЯТТЯЯ...   ЯЯТТЯЯТТ...
2: ТТЯЯТТЯЯ...   ЯЯТТЯЯТТ...
2: ЯЯТТЯЯТТ...   ТТЯЯТТЯЯ...
   ...           ...

Т.е. переключение каждую строку приводит к тому, что двойной пиксель просто смещается на полустроку вниз. А должно быть в идеале так:

   Фрейм 0       Фрейм 1
0: ТТЯЯТТЯЯ...   ЯЯТТЯЯТТ... 
0: ЯЯТТЯЯТТ...   ТТЯЯТТЯЯ...
1: ТТЯЯТТЯЯ...   ЯЯТТЯЯТТ...
1: ЯЯТТЯЯТТ...   ТТЯЯТТЯЯ...
2: ТТЯЯТТЯЯ...   ЯЯТТЯЯТТ...
2: ЯЯТТЯЯТТ...   ТТЯЯТТЯЯ...
   ...           ...

Т.е. лучше использовать иную стратегию переключения.

Оффтоп: И получается, что меняя страницы в правильный момент, можно создать программный режим 128x256?

Программа автоматически уменьшит шрифт и отступы, если обнаружит, что не вмещается в рабочую область монитора.