Тема: Утилита DaDither: конвертация изображений
Перенесено из другой ветки
Персональный компьютер "Агат" - технические беседы (является частью agatcomp.su / agatcomp.ru) Как зарегистрироваться?
Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
ПЭВМ "Агат" 7-9: Форум → Эмуляторы и утилиты для PC → Утилита DaDither: конвертация изображений
Перенесено из другой ветки
Ну вот 128х256х16 точно.
А где можно почитать об этом режиме? Есть ли образец графического файла для этого режима?
0 - палитра 1 агат-9 (по умолчанию которая)
...
8 - палитра 1 агат-9 (оттенки серого через "видеосигнал")
...
F - таблица палитр в байтах R - $08...$0F, G - $18...$1F, B - $28...$2F.
Это финальная версия?
И правильно ли я понимаю, что в Агате можно реализовать гигаскрин, т.е. переключать две разные экранные области по прерыванию? Если да, то предлагаю и этот режим обозначить.
> А где можно почитать об этом режиме?
А вот про него в сообщениях 13-16 этой темы.
http://forum.agatcomp.ru//viewtopic.php?id=307
> Это финальная версия?
Мне показалось так удачней всего, с точки зрения возможных дополнений.
Если у вас есть соображения по этому поводу, ну т.е. исправления - буду рад.
> И правильно ли я понимаю, что в Агате можно реализовать гигаскрин,
Насколько я знаю, можно применить к любому режиму такую фишку. Ведь у агата экранных страниц как у дурака фантиков. Вообще думаю подробности avivanov76 может сказать.
А что предполагается иметь на выходе конвертера в случае трансляции картинки в гигаскрин? Если две штуки файлов .Fil , то несложно это проверять на реале.
Кстати, при использовании ячейки палитр, такое тоже возможно, сообщение 14 тут:
http://forum.agatcomp.ru//viewtopic.php?id=275
Опять же avivanov76 в этом шарит.
И правильно ли я понимаю, что в Агате можно реализовать гигаскрин, т.е. переключать две разные экранные области по прерыванию?
Да, конечно можно. NMI синхронизированы с кадровой разверткой, поэтому можно переключать графические страницы (и даже разные режимы) во время обратного хода развертки. Был и софт, который это использовал. Была тут на форуме пара сообщений про это, например тут и где-то еще.
А что предполагается иметь на выходе конвертера в случае трансляции картинки в гигаскрин? Если две штуки файлов .Fil , то несложно это проверять на реале.
Непосредственно утилита. На выходе три fil файла. В основном записаны сразу два экрана. В двух дополнительных по одному экрану. Т.е. что удобнее использовать, то и используйте. 4096 цветов для gigascreen еще не реализованы, но планируются.
Цвета рассчитаны для калиброванного CRT монитора. Какие оттенки будет получаться на LCD - рассчитать невозможно в принципе. Буду признателен, если потестируете. Я не уверен, что я полностью правильно понял структуру fil файла, заголовок также нужно проверять.
Еще мне интересно, а как были получены/рассчитаны значения цветов из таблицы http://agatcomp.ru/agat/Hardware/Monic.shtml
Я не уверен, что я полностью правильно понял структуру fil файла, заголовок также нужно проверять.
Там на выходе вполне корректный FIL, но не стоит к указателю длинны прибавлять длину хвоста.
Лучше в указателе заносить только длину самой картинки. Это для универсальности и совместимости с софтом который про хвост ничего не знает.
На примере картинки 128х128: сейчас у вас указано Точка загрузки: $2000 Длина кода: $20FC.
А надо как у стандартного экрана: $2000 Длина кода: $2000.
Т.е. все остается как сейчас у вас, кроме одного байта.
Еще мне интересно, а как были получены/рассчитаны значения цветов
Это была комедия:) в поисках правильных цветов я валял дурака:
Сперва ставил монитор с реальным агатом и рядом другой агат подключенный к плате видеозахвата и там настраивал похожую картинку, потом смотрел какие кода цветов получились. Попутно Voldemar0 напугал меня что трубка может быть севшая и не так цвета передавать, и если колокольчик я использовал абсолютно новый, то 32втц был поношенный и я (даже рассказывать не буду как) договорился с архивом завода, вроде МЭЛЗ, и раздобыл там нулёвую трубку.
Дальше безумие только усиливалось - у знакомых в типографии взял пистолет который считывает цвет, когда его направляешь на что-то, потом у друга на дилере BMW взял аналогичное устройство. В итоге получилось очень близкое и у меня было еще пару "хороших" идей :)
Но все это безобразие прекратил SnakE, изучив внимательно схему и подобрав нужные цвета, который удивительно похожи на реал, вот тогда то и выяснилось что несоответствие оттенков серого через разъем "видеосигнал" продиктованы схемой.
Вообще конвертер очень понравился, все по делу и все удобно\очевидно. Сразу видно что поход продуманный.
Планируются ли режимы Apple][ ?
Лучше в указателе заносить только длину самой картинки. Это для универсальности и совместимости с софтом который про хвост ничего не знает.
А текущий софт умеет отображать изображения с палитрой 4096? Если нет - то я бы предложил компромисс: для обычных палитр писать размер без футера, а для 4096 с футером.
Планируются ли режимы Apple][ ?
Lo-Res какой-то слишком маленький, путем конверсии ничего путного не сделать. Hi-Res какой-то наркоманский, я пытался в нем разобраться, но не осилил схему формирования бит в зависимости от цвета. Double Hi-Res еще не смотрел.
А вы еще не проверяли, как выглядит гигаскрин на реальной машине? Мне интересно какова будет субъективная оценка уровня мерцания.
> для обычных палитр писать размер без футера, а для 4096 с футером.
Не, это точно ни к чему.
Эти байты - указатель для агатовских дос, читает то он кратно сектору, но заносят в озу в соответсвии с указанной длинной.
Например, некоторые графические редакторы или скажем вот эта игрушка: http://agatcomp.ru/agat/Software/Game/A … ra35.shtml
(она как раз картинки такие использует в качестве уровней) -
ничего не знают о существовании моего хвоста (а он им и не нужен совсем), и сразу за картинкой начинают свой код, таким образом загрузка лишних 252 байт вместе с картинкой в озу - поломают прогу. А если будет указана стандартная длинна, то будет совместимость с старым софтом у "Хвостатых картинок".
Если под агат, понадобится написать прогу которая анализирует хвост, то тут проблем нету и указанная длинна 2000 не мешает.
THE BEST вообще может загрузить вместе с хвостом, если надо, не оглядываясь на то, что указано в файле. В ИКП, после загрузки, последний сектор целиком остается в теле ДОС - бери и анализируй.
> А вы еще не проверяли, как выглядит гигаскрин на реальной машине
Пока у меня нет такой возможности, но сделаю это обязательно. И вообще погоняю прогу эту, может еще какие-то мелочи скажу. Может ребята раньше подключатся и опробуют.
Но насколько я помню из детства - мерцания минимум, если вы про то мерцание от которого на спектруме потом глаза болят.
Может вынести обсуждение в отдельную тему?
Например, некоторые графические редакторы или скажем вот эта игрушка ничего не знают о существовании моего хвоста (а он им и не нужен совсем)
Мне не понятно, зачем пытаться скармливать программам, которые не знают о палитре 4096, файлы с палитрой 4096?
Может вынести обсуждение в отдельную тему?
Можно и отдельную тему. Мне не принципиально.
> Lo-Res какой-то слишком маленький, путем конверсии ничего путного не сделать.
Есть еще Double Lo-Res это 80х40 (агатовский то 64х64 реализовали).
Но насчет слишком маленького не соглашусь. Ведь вашу прогу можно использовать и для точного прямого переноса.
Т.е. нарисовал в PAINT картинку 40х48 с правильной палитрой, и прям тут же загнал её в FIL, да еще и с хвостом уже заполненным. Удобно? Удобно!
я вам больше скажу, затеял я подготовить пару картинок для проверки платы палитр. Очень мне понравились межуровневые картинки из игры TinTin на SNES. Там как раз 128х128 и 16 цветов (такие может плата палитр воспроизвести). И вот я всё думал, как бы поудобней заполнить цвета в хвосте. Больше месяца не решался на эту рутину. А вчера, буквально за 5 минут сделал штук 20 вашей прогой. т.е. просто открывал картинку, выставлял все что нужно, и получил на выходе FIL уже с заполненными цветами в хвосте да еще и с возможностью осветлить\затемнить. Спасибо!
(картинка в аттаче).
Что касается Apple режимов: про HiRes на этом форуме вам могут подробно рассказать.
Кроме того возможно будет полезны:
Про Double Lo-Res http://forum.agatcomp.ru//viewtopic.php?id=314
Про Double Hi-Res http://forum.agatcomp.ru//viewtopic.php?id=135
Могу накидать готовых FIL для разных режимов Apple, кстати.
> Мне не понятно, зачем пытаться скармливать программам, которые не знают о палитре 4096, файлы с палитрой 4096?
Да нет, никто не собирается скармливать старым прогам картинки с 4096 цветов.
Дело в другом, ведь все зависит от целей и задач.
Про предложенному вами компромиссу получается что только те хвосты, которые имеют инфу о палитре 4096 имеют право быть загруженными за картинкой в озу.
Но в хвосте не только инфа о палитре, но и минимум о режиме.
Пример 1: никто не станет скажем адаптируя вышеупомянутую игру под 4096 цветов перелопачивать её с ног на голову чтоб высвободить после экранной области 252 байт, да и зачем, эти 252 байт уже есть (остались) в теле дос после загрузки. Красиво встроят опрос того места где в дос последний сектор целиком и всё.
Значить полученный по компромиссу FIL придется подправлять...
Пример 2: решили сделать слайд шоу картинок для различных режимов, без всяких там 4096 цветов. И хотим на лету знать режим именно прям за картинкой. С учетом компромисса у нас такие файлы не тянут за собой в ОЗУ хвост. придется подправлять...
И т.д. и т.п. почему я и говорю все зависит от целей и задач.
Вношу рацпредложение :)
Поскольку с учетом специфика агата, востребованными будут в основном файлы где размер указан без футера, сделать это по умолчанию, но,
сделать функцию типа ставить галочку "записывать в FIL размер с футером". И все довольны и на все случаи жизни удобство. Вот это было бы действительно отлично.
Ок, убедили. Исправил запись на размер без футера.
Кое что заметил, если при сохранении FIL назвать картинку например "GOLFgolf" , то агатовское имя выглядит нормально.
А если скажем "ГОЛЬФгольф" , то агатовское имя выглядит как "?????уюыщт"
Похоже неправильно преобразуется виндовый wchar в агатовскую кодировку.
Похоже неправильно преобразуется виндовый wchar в агатовскую кодировку.
Где можно почитать про агатовскую кодировку?
Тут есть картинки агатовских знакогенераторов:
http://agatcomp.su/agat/Hardware/useful/CharSet.shtml
Но важно вот ещё что:
в семёрках обычно не было строчных букв в знакогенераторе, но немало софта хранило текст в виде полных 8 бит. В том числе штатная dos33 хорошо различает заглавные и строчные буквы в именах файлов. При этом в семёрочном Бейсик-60 возможности переключить регистр на вводе не было.
Так что если имя файла было написано строчными буквами, этого и не видно на экране (без расширения знакогенератора или какой нибудь цветовой индикации регистра) и ввести с клавиатуры его невозможно. И чтобы всё таки обратиться к такому файлу, нужно было пробежать курсором по имени (ввод с экранного озу).
Но это ещё не всё:
Когда на девятках полный знакогенератор стал стандартом и в ИКП-Бейсике сделали ввод строчных-заглавных, то это было сделано немного хитро: при включении латиницы латинские буквы вводились заглавными (логическое продолжение семёрки), а русские - строчными. Нажатие РЕГ меняло регистр.
Но нажимать РЕГ было лень, поэтому нередко русские имена файлов идут строчными буквами, а латинские почти всегда заглавными.
Этот момент имеет смысл как-то учесть при вводе имени файла: может быть латинице менять регистр или просто предупреждение выводить где-то сбоку (не отдельным окном, а просто строкой), которая будет вылезать при вводе строчных букв и сообщать что-то вроде "При использовании строчных букв у вас могут возникнуть проблемы с доступом к файлу на Агат-7".
Мне кажется ты усложняешь, не стоит ориентироваться на ранние семерки с отсутствием строчных.
Достаточно сориентироваться на эту картинку:
Используя для строчных $40-7F а для заглавных и цифр $A0-FF. Этого будет достаточно.
Ну максимум еще Ё , ё - 0F , 9F.
Все равно на все случаи жизни не предусмотреть.
> Все равно на все случаи жизни не предусмотреть.
Вы тут обсуждали, как на все случаи жизни предусмотреть размер файла, а теперь семёрка - не важно, у всех девятки или полный знакогенератор ? Я, например, вообще семёрку с расширенным не видел. Только по рассказам слышал, что они существуют. Семёрки есть у меня и Алекса.
--
Есть предложение к автору проги: пакетный режим обработки.
Настроил параметры и фигакнул сразу сотню картинок по одному набору параметров.
Скажем, сразу директорию. Или сделать поддержку WM_DROPFILES - drag'n'drop - с explorer перетащил группу файлов и сразу результат тут же получил.
{Это будет самый простой вариант конвертнуть на агат видеоролик.}
И ещё: возможность сохранения настроек. Хотя бы только текущие или может быть даже в именнованном наборе (файл настроек с произвольным именем, например). Чтобы если подобрал их удачно, потом вернуться.
УУУУ, точно накошмарил :)
Главное, что надо понимать, утилита поддерживает огромную кучу олдовых ЭВМ, и уверен что автору приходится вникать в неочевидные особенности каждой в процессе работы. Это вообще не очень просто, так зачем ему усложнять жизнь и путать?
Теперь по порядку, смотрим картинку:
И прикидываем по ней мою фразу из 18 сообщения:
Используя для строчных $40-7F а для заглавных и цифр $A0-FF. Этого будет достаточно.
Т.е. на всех без исключения девятках (поскольку у них всегда полный ЗГ) и на семерках с полным ЗГ будут правильно отображаться и строчные и заглавные.
А на семерках с урезанным знакогенератором, просто строчные буду выглядеть как заглавные ($40-7F), мы все к этому привыкли.
Действительно, есть около 4 процентов софта, который ничего не знает о строчных буквах (устанавливает старший бит в 1). Но это его проблемы, а не Агата. И даже в те времена на это никто не оглядывался при написании софта. Не вижу смысла и в данном конкретном случа оглядываться.
И еще, есть подозрение, что картинки для агат будут конвретить имено Агатовцы:) и им (нам) про эти 4 процента известно.
garnizon пишет:Ну вот 128х256х16 точно.
А где можно почитать об этом режиме? Есть ли образец графического файла для этого режима?
Вчера добавили в утилиту: http://agatcomp.ru/agat/PCutils/filConverter.shtml этот режим.
Кстати там и Apple режимы все есть. Можно создать образец любого.
Вчера добавили в утилиту
Как это планируется кодировать в футере?
Я чуть изменил его, но на графические режимы не коснулось. http://agatcomp.ru/agat/PCutils/EXIF.shtml
128х256 - 8 в старшей тетраде, остальное так же осталось.
Обновил.
-Исправлена кодировка fil файла
-Добавлен режим 128x256
-Добавлен 4096 для гигаскрин
А такой фокус с платой палитр не возможен (как по ссылке выше) :
Можно даже круче фокус сделать - палитру ведь можно менять по прерываниям. IRQ, по моему, генерируется на каждую текстовую строку. Проблема правда в том, что все 48 регистров за время обратного хода луча по строке перезагрузить не удастся - быстродействия не хватит. Но если поделить палитру на 2 части по 8 цветов, а картинку подготовить так, чтобы больше 8 цветов в смежных строках не использовалось, то можно обновлять палитру блоками по 8 цветов. В теории можно получить, например, режим 128x128 с 256 цветами одновременно.
Ведь утилита может сама готовить такую (поделить палитру на 2 части по 8 цветов, а картинку подготовить так, чтобы больше 8 цветов в смежных строках не использовалось) картинку перед эмуляцией 256 Цветов?
Отлично все работает!
А такой фокус с платой палитр не возможен (как по ссылке выше) :
Можно даже круче фокус сделать - палитру ведь можно менять по прерываниям. IRQ, по моему, генерируется на каждую текстовую строку. Проблема правда в том, что все 48 регистров за время обратного хода луча по строке перезагрузить не удастся - быстродействия не хватит. Но если поделить палитру на 2 части по 8 цветов, а картинку подготовить так, чтобы больше 8 цветов в смежных строках не использовалось, то можно обновлять палитру блоками по 8 цветов. В теории можно получить, например, режим 128x128 с 256 цветами одновременно.
Ведь утилита может сама готовить такую (поделить палитру на 2 части по 8 цветов, а картинку подготовить так, чтобы больше 8 цветов в смежных строках не использовалось) картинку перед эмуляцией 256 Цветов?
ПЭВМ "Агат" 7-9: Форум → Эмуляторы и утилиты для PC → Утилита DaDither: конвертация изображений
Форум работает на PunBB, при поддержке Informer Technologies, Inc