Просмотр полной версии : GMX Pic View
Всем привет.
Сделал вьювер изображений для экрана Scorpion GMX и сконвертировал несколько картинок к нему.
Всего картинок 19, больше на диск и не влезет без сжатия. Каждая весит 32768 байт.
Выкладываю вьювер и конвертер к нему. Конвертер кушает только специально подготовленные в GIMP по размеру и цвету картинки.
Была мысль сделать поддержку формата GRF.
На АТМ и Профи есть похожий графический режим с байтом цвета на байт пикселей, то есть 2 цвета на строчку 1*8 пикселей. Есть коллекция картинок в формате GRF, конвертеры, вьюверы.
Но я пошёл своим путём, потому что у них больше цветов.
На АТМ экран 640*200 2 цвета на байт из палитры 64. Профи 512*240, 2 цвета на байт из палитры 256. А на GMX только 16 стандартных цветов.
В общем, смотрим только своё, родное.
735177351873519
73520
Новые версии с поддержкой GRF:
73639
73642
73705
Upd.
Самые свежие версии тут (https://cloud.mail.ru/public/Nwek/SmSAFUh54)
Или здесь (https://drive.google.com/drive/folders/19-O-MY2XkgRUmUUZ98xZ83juCuaBe32I?usp=sharing)
Понимает форматы:
- Свой формат (32768 байт, копия экрана GMX)
- GMX #0f - свой формат (16128 байт, копия атрибутов)
- GRF Profi mono (ч.б.)
- GRF Profi 16c
- GRF Profi 256c (16 из палитры 256)
- GRF (BLK) ATM 64c (16 из палитры 64)
- ZX 6144, 6912, 6913
- Font 2048
- IFL - Multicolor (8*2) (9216 байт)
- MLT - Multicolor (8*1) (12288 байт)
- MC - Multicolor (8*1) (12288 байт)
- MCX - Multicolor (8*1) (24576 байт)
Эмулятор Unreal (https://cloud.mail.ru/public/UbmH/dqVvcRWzm), настроенный на GMX. Запустить, нажать F3 чтобы выбрать образ дискетки. И Enter запустить.
Универсальный конвертер, в том числе в родной формат pic view:
DaDither (https://zx-pk.ru/threads/32400-dadither-eshche-odna-programka-dlya-dit).
Для Профи:
Img2Grf (https://zx-pk.ru/threads/30113-img2grf-konvertor-izobrazhenij-v-fajly-formata-grf.html). Конвертер изображений в файлы формата GRF.
Картинки от Профи (https://zx-pk.ru/threads/32246-gmx-pic-view.html?p=1083622&viewfull=1#post1083622).
Для АТМ:
RetroX to GRF v0.1 converter (http://alonecoder.nedopc.com/zx/retroxtogrf.rar). Утилита для создания цветных GRF картинок.
Картинки от АТМ (http://atmturbo.nedopc.com/download/isdos/grfview/grf_pict.zip).
Сделай поддержку GRF. Режим 16 цветов, является стандартным режимом для Профи, а режим с палитрой 16 из 256 цветов - расширенным. Сейчас работаю над добавлением в свой конвертер возможности работать в режиме 16 цветов. Так его можно будет использовать для подготовки изображений под GMX.
Вообще GRF - это универсальный формат, к тому же расширяемый (для Профи есть две версии: для стандартных 16 цветов и с палитрой). Незачем плодить кучу несовместимых. Более того в твоём случае можно поддержать вывод картинок с палитрой. Просто перед выводом нужно пересчитать палитру и привести цвета к ближайшим стандартным цветам. Я это делаю через "серость", пока только на ПС. Все цвета приводим к серому (число 0-255), после чего находим ближайшие значения. Конечно цвета "поплывут" и часть изображения может "пропасть", но это лучше чем ничего. Подобный финт у меня запланирован для моего вьювера под CP/M. Правда могут быть проблемы с форматом хранения цвета, но если что придётся конвертировать на лету.
Небольшое отступление: не знаю как у GMX, но у Профи возможны три режима работы с цветами: 8 цветов+яркость единая для чернил и фона+мерцание, 16 цветов (яркость раздельная для чернил и фона, нет мерцания), палитра 16 из 256. Все режимы аппаратные и не могут быть сразу на одной машине. Режим 16 цветов эмулируется в режиме палитры 256. Режим 8 цветом, считатся "вымершим". Для универсальности формат хранения цвета совпадает с форматом стандартного спекки.
tae1980, спасибо за разъяснения. Попробую сделать GRF, если смогу. Для GMX родной режим "8 цветов+яркость единая для чернил и фона+мерцание", да и то с яркостью мне не понравилось. Лучше только 8 цветов. Ещё и размеры пикселей наверняка разные у разных машин.
- - - Добавлено - - -
Да, поддержка GMX в твоём конвертере будет очень кстати.
- - - Добавлено - - -
В смысле поддержка 16 или лучше 8 цветов. Хотя выключить бит яркости и при просмотре не долго. Так что можно и 16.
Попробую сделать GRF, если смогу.
Формат очень прост. Вот описание для Профи.
Обращаю внимание, что минимальная длина заголовка 128 байт, но может быть и больше (+8). Но последнее скорее всего для нас не актуально, хотя я рассматриваю возможности внесения изменения. В "+9", хранится признак стандартности, в настоящее время там либо 0 - цвета стандартного спекки, либо 19 - палитра 16 из 256. При чем различий 8 или 16 цветов нет. Но возможно стоит ввести для универсальности, так как 16 цветные картинки начнут моргать, на тех машинах где этот режим не поддерживается. Думаю подобное различия не ввели так как 8 цветные Профи, были крайне не продолжительное время.
Формат Profi GRF:
+0 слово DW HSIZE горизонтальный размер картинки в точках
+2 слово DW VSIZE вертикальный размер в строках растра
+4 байт DB BPP бит на точку или точек в байте (в зависимости от AMOD)
+5 байт DB AMOD 1 - цвет на каждую точку, 0 - байт аттрибутов на байт точек
+6 слово DW BPS длина образа одной строки растра в байтах
+8 байт DB HLEN длина заголовка в записях по 128 байт (и 0, и 1 соответствует 128 байт)
+9 байт DB 0 признак стандартного формата ( если формат будет изменяться, изменится и этот байт )
+10 118 х DB 0 резерв
или палитра (при +9=19($13)). 16 байт по 1 байту на цвет в формате GGGRRRBB
BPP AMOD режим хранения информации
--- ---- -----------------------------------------
8 0 PROFI-mono
4 0 PROFI-color (байты точек и аттрибутов чередуются, точки раньше аттрибутов)
2 1 CGA (4 цвета, байт описывает 4 точки)
4 1 EGA (16 цветов, байт описывает 2 точки)
5 1 VGA (32 цвета, байт описывает 1 точку)
8 1 VGA (256 цветов, байт описывает 1 точку)
Причем я встречал вроде картинки только PROFI-color (байты точек и аттрибутов чередуются, точки раньше аттрибутов) и Profi-Mono
- - - Добавлено - - -
В смысле поддержка 16 или лучше 8 цветов.
8 цветов - единая яркость для чернил и бумаги, 16 цветов - яркость раздельная. Такие названия используются на Профи.
Алгоритмы подбора цветов будут разные.
tae1980, а картинки от АТМ откроются на профи? Или наоборот. Раз уж формат универсальный. И как будут выглядеть, как задумано или с искажениями?
а картинки от АТМ откроются на профи? Или наоборот. Раз уж формат универсальный. И как будут выглядеть, как задумано или с искажениями?
Сама картинка да. Но насколько я знаю, формат заголовка у них другой. Хотя могу и ошибаться. Уж не знаю зачем и почему, но информацию о палитре на АТМ засунули в начало заголовка. Решения, на мой взгляд, граничит с бредом, так как в конце заголовка есть куча зарезервированного места, а сам заголовок можно "бесконечно" расширять. Но, повторю, я могу ошибаться, так как у меня нет точной информации, только её обрывки. И конечно будут проблемы с пересчётом палитры.
У формата GRF в целом есть как плюсы так и минусы. Это линейной формат, графика в нём храниться линейно, что упрощает навигацию по файлу, а сама картинка не привязана к формату физического экрана, и информацию можно без проблем выводить даже в окно, или картинка может быть больше/меньше физического экрана. Но при выводе нужны дополнительные вычисления, что его замедляет.
В нашем случае он удобнее иных форматов, например bmp, так как точки в нём хранятся побайтно, их по сути их нужно просто правильно прочитать.
NEO SPECTRUMAN
21.09.2020, 02:14
нету скриншота с эмулятора
непорядок!
https://jpegshare.net/images/bd/7b/bd7b591656637a952ffdbe0a67439c17.png https://jpegshare.net/images/e2/9a/e29af84aa70c6e192616d16043b6ae6f.png
- - - Добавлено - - -
а где нибудь можно увидеть сам алгоритм конвертации?
мне как раз нужен алгоритм конвертации из 16 цветов на пиксель
в такой "аппаратный мультиколор"
а тут на вид результат не плохой
Жаль мало кто увидит "вживую" работу софта (и я в том числе). Реальный Scorpion GMX не у многих, а эмуляторов нет. :(
а тут на вид результат не плохой
Жаль что это всё проявлятся только сейчас, а в 90х каждый тянул одеяло на себя.
Подобная графика была бы тогда бомбой. Физически возможности были уже в начале 90х, а по факту программы способные раскрыть их возможности в полной мере появляются только сейчас.
а где нибудь можно увидеть сам алгоритм конвертации?
На знаю какой именно алгоритм использовал izzx (https://zx-pk.ru/members/9027-izzx.html), но у меня лучший результат в 85% случаях даёт такой: просматриваем цвета в байте, находим:
* подсчитываем частоту появления цветов для байта, правого и левого полубайта
* самый темный/светлый цвет для байта, правого и левого полубайта, находим средние значения.
* если в байте 1, 2 цвета, то проблем нет.
* если в байте 3 цвета, берём самый частый и альтернативный ему по серости.
* берём за основу самый частый цвет в байте, определяем он "светлый" или "тёмный" и в каком полубайте этот цвет встречается чаще. Вторым цветом берём самый частый альтернативный цвет из другого полубайта.
* Проверяем оба цвета на идентичность, если они одинаковый - подбираем иной цвет по аналогичной схеме, если цвета в полубайте заканчиваются (например, там все цвета в той же серости, что и основной цвет), переходим в полубайт с первым основным цветом.
Самый лучший результат по резкости даёт аналогичная схема, но когда берут за основу самые светлые и тёмные цвета. Но тут часть базовых цветов может "поплыть", так как самые светлые/темные цвета не обязательно самые частые.
Можно не использовать полубайты, но по моим ощущениям с ними результат на 10-15% лучше.
NEO SPECTRUMAN, у меня довольно простой алгоритм. Сначала в GIMP всё приводится в 16 (15) цветов. Потом в конвертере цвета 0-3 и 8-11 считаются фон, цвета 4-7 и 12-15 считаются пиксель. Затем высчитывается какого цвета из строчки 8 пикселей больше, тот и становится цветом байта, и так же фона.
Приложу код на C#.
73525
Такой код выдаёт 8 цветов. А чтобы было 15 надо раскоментировать две строчки bright=1
А где взял скриншот из эмулятора? Я думал нету эмуляторов на GMX. Без эмулятора трудно ).
Затем высчитывается какого цвета из строчки 8 пикселей больше, тот и становится цветом байта, и так же фона.
По сути берёте два самых частых цвета.
При таком подходе сильно теряется детализация и плохо передаются грани областей.
Первый алгоритм который реализовал. Только фон это самый частый цвет, чернила - второй по частоте.
https://imageup.ru/img226/thumb/2020-09-21_13-21-133657293.jpg (https://imageup.ru/img226/3657293/2020-09-21_13-21-13.png.html)
NEO SPECTRUMAN
21.09.2020, 12:28
Я думал нету эмуляторов на GMX. Без эмулятора трудно ).
gmx есть в унриале тслабса
но не доделан он
- - - Добавлено - - -
http://forum.tslabs.info/viewtopic.php?f=29&t=142
По сути берёте два самых частых цвета.
По сути да, но не совсем. Сначала точки делятся на пиксели и фон. Если была одна точка зелёная (цвет 4), четыре красные (цвет 2) и три синие (цвет 1), то у нас будет в итоге цвет зелёный пиксель и красный фон. А не красный и синий.
- - - Добавлено - - -
gmx есть в унриале тслабса
я так и подумал. Спасибо!
Максагор
21.09.2020, 13:13
По сути да, но не совсем. Сначала точки делятся на пиксели и фон. Если была одна точка зелёная (цвет 4), четыре красные (цвет 2) и три синие (цвет 1), то у нас будет в итоге цвет зелёный пиксель и красный фон. А не красный и синий.
А по какому принципу тогда идет сортировка цветов? Почему, например, тут именно зеленый?
А по какому принципу тогда идет сортировка цветов? Почему, например, тут именно зеленый?
А я вот выше писал что у меня цвета 0-3 и 8-11 считаются фон, цвета 4-7 и 12-15 считаются пиксель. Если условно пронумеровать 16 цветов спека от 0 до 15. Таким образом если в строчке 8 пикселей есть зелёный цвет, то он принимается за пиксель. А красный, к примеру, принимается за фон. А уж потом отдельно вычисляется сколько какого цвета пикселей и сколько какого цвета фон в пределах этой строчки 8 пикселей.
73526
- - - Добавлено - - -
Цвета повышенной яркости у меня условно называются номерами 8-15.
По сути да, но не совсем. Сначала точки делятся на пиксели и фон. Если была одна точка зелёная (цвет 4), четыре красные (цвет 2) и три синие (цвет 1), то у нас будет в итоге цвет зелёный пиксель и красный фон. А не красный и синий.
А причём тут зелёный цвет? За чем он нужен? По какому принципу произведено разбитие на цвета чернил и фона?
В свое работе пришёл к вывожу, что сам цвет не так уж и важен, важна его "серость". Так же практика показала, что в большинстве случаев цвета расположены с равномерным переходом с одной стороны на другую. Именно по этому, я стараюсь брать цвета с максимальной разницей по серости, с разных сторон байта.
- - - Добавлено - - -
А я вот выше писал что у меня цвета 0-3 и 8-11 считаются фон
А что буде,т если в байте будут цвета только 0-3 или 8-11? То есть только цвета фона или пикселей.
По какому принципу произведено разбитие на цвета чернил и фона?
А по никакому принципу. Я прикинул в уме что если что поярче, то это пиксель, а потемнее - фон )
А что буде,т если в байте будут цвета только 0-3 или 8-11?
Тогда будет один цвет на весь байт. Только фон.
Я темой не интересовался специально, как придумалось, так и вышло. Спасибо за идею что картинку надо ужимать по цветам в фотошопах.
- - - Добавлено - - -
Если не найдено пикселей в строчке, то цвет пикселей 0. Если не найдено фона, то фон 0.
- - - Добавлено - - -
Но если пикселей нет, то и цвет 0 ни на что не повлияет.
Если не найдено пикселей в строчке, то цвет пикселей 0. Если не найдено фона, то фон 0.
То есть если имеем в байте два цвета, предположим, 2 и 9, то в байте останется только один цвет 2 или 9?
Это не правильно!
То есть если имеем в байте два цвета, предположим, 2 и 9, то в байте останется только один цвет 2 или 9?
Получается так, верно подметили. Но видимо не так часто встречаются такие комбинации. В целом ещё помогает что пиксель на GMX (а Максагор сказал что и на АТМ, если я правильно услышал на стриме) по ширине вдвое уже высоты. Получается визуально 4 цвета на байт.
- - - Добавлено - - -
Запустил на эмуляторе. Работает. Режим GMX запустился после нажатия shift+ctrl+f12. По сравнению с реалом скрол не такой плавный и внизу строчка артефактов. Может настраивается, но и так отлично.
А где взял скриншот из эмулятора? Я думал нету эмуляторов на GMX. Без эмулятора трудно ).
Какой-никакой, а эмуль был, как всегда самый первый от Молодцова под Unreal. Может у кого-то и сохранился.
https://zx-pk.ru/threads/23228-emulyatsiya-scorpion-gmx.html
В ts-lab-совском возможно он и есть
и видео на ю-трубе похерили, копирасты, тбм((
Какой-никакой, а эмуль был
Да, выше ссылку кидали на Unreal от Ts-labs. Я уже осваиваю понемногу.
А, в смысле была и раньше версия под unreal? Ясно.
NEO SPECTRUMAN
22.09.2020, 20:28
пробежался глазами по старым темам
вообще говорят про снег
Эмуляция не полная - на видео не увидел "спецэффектов", как на аппаратном GMX. Должен быть "снег" на экране в расширенном графическом режиме. В GMX commander точно был, на сколько я помню. Газету не читал - не знаю, а во строенном в ПЗУ тесте вроде боролись со "снегом", чтобы не отпугнуть потенциального покупателя железки во время демонстрации нового графического режима.
такое есть на железном гмхэ?
когда он проявляется?
- - - Добавлено - - -
от Молодцова
куда этот молодцов только делсо...
пробежался глазами по старым темам
вообще говорят про снег
такое есть на железном гмхэ?
когда он проявляется?
Есть. В GMX командере и в CPM с моим драйвером слева мельтешит, иногда больше иногда меньше. Где-то сантиметр-два от левого края горизонтальные полоски пролетают. А с правого края не уверен, у меня телик съедает часть изображения ).
От чего зависит точно не знаю, по-моему от частоты опроса клавиатуры и от частоты обновления изображения. Как-нибудь надо повнимательнее посмотреть.
izzx, продолжая разговор о форматах файлов. Отмечу, что формат grf удобен для передачи и вывода информации в наших условиях, так как линейный, удобен в навигации по файлу, может хранить картинки отличные от физических размеров экрана и не зависит от железа, при этом информацию хранит по байтно. Но это требует дополнительных затрат при выводе картинки.
Для компенсации этого недостатка я ввожу формат SCR, по сути просто копию экрана (в моём случае в формате Профи). Его можно будет быстро загрузить, для конкретного железа, но только картинку в размер экрана. Если картинка будет иметь размеры или структуру отличные от физических размеров экрана, то начинаются пляски с бубнами. Но такой формат был бы полезен.
Предлагаю, ввести на него стандарт, что бы можно было на загрузить на разных машинах. Конечно все его плюсы будут только на том железе, на которое он рассчитан, но просмотреть можно будет везде.
Для этого потребуется к графическим данным добавить заголовок, в котором описать все их особенности. После чего их загрузка станет техническим вопросом.
Формат заголовка раелизовать на базе заголовка GRF, Если нет возражений, я внесу предложения по формату заголовка.
tae1980, С одной стороны хорошо, с другой дополнительные трудности. Я вот подумываю сделать просмотр форматов и АТМ и профи. А тут надо будет ещё три формата теоретически добавлять. Новые ГМХ, АТМ, профи, старые АТМ и профи. Всего шесть с тем что у меня уже есть.
- На АТМ похоже формат столбиками, а не линейный.
- В новом формате нужна чёткая метка что за версия формата. А то не отличить АТМ от Профи.
- Наверно и палитра нужна, без неё не выйдет.
- Где посмотреть палитру профи? Которая 16 цветов.
Максагор
23.09.2020, 13:09
Сама картинка да. Но насколько я знаю, формат заголовка у них другой. Хотя могу и ошибаться. Уж не знаю зачем и почему, но информацию о палитре на АТМ засунули в начало заголовка. Решения, на мой взгляд, граничит с бредом, так как в конце заголовка есть куча зарезервированного места, а сам заголовок можно "бесконечно" расширять. Но, повторю, я могу ошибаться, так как у меня нет точной информации, только её обрывки. И конечно будут проблемы с пересчётом палитры.
Даю информацию по формату файлов мультиколорных картинок АТМ под режим аппаратного мультиколора 640x200. Формат создавался в начале 90-х под написанный тогда же под ATM-версию CP/M по заказу "МикроАРТ" графический редактор GRAF. И там данные картинки имели расширение BLK. Позже я под OS TASiS написал вьювер этих картинок GRFVIEW.COM. Но так как в TASiS еще со времен iS-DOS расширение BLK зарезервировано за драйверами дисковых устройств (типа BLK - блочное устройство) и, чтобы избежать путаницы, здесь им было присвоено "свободное" расширение GRF - производная от названия редактора GRAF. А далее, собственно, о формате.
Только замечу, что у вас несколько неточные представления о заголовке. Он имеет фиксированную длину в 0084hex (или, соответственно, 132dec) байта. Вообще "удивлен удивлением" вас, ибо в том же стандартном факле картинок BMP также заголовок и данные о палитрке помещены в начале (хотя и не так, как в BLK/GRF, что естественно).
ФОРМАТ BLK(GRF)-ФАЙЛА
=====================
Смещение Кол-во Значение
============ ======== ============
#0000 #30(16x3) Палитра. Представляет собой 16 троек
значений GRB-цветов (именно в таком
порядке), представленных в виде сим-
волов ASCII:
"0"(#30) - цвет (G,R или B) выключен
"1"(#31) - цвет низкой интенсивности
"2"(#32) - цвет в режиме BRIGHT 0
"3"(#33) - цвет в режиме BRIGHT 1
Любое другое значение приравнивается
утилитой GRFVIEW к "3".
#0030(*) #03 Метка "GRF" - означает, что за ней
следуют два значащих байта
#0033(*) #01 Рекомендуемые атрибуты (INK & PAPER)
заднего фона, на который налагается
изображение. Актуально для картинок,
по размеру меньших 640x200.
#0034(*) #01 Рекомендуемый цвет бордюра (#00-#0F)
Может быть актуально при использова-
нии нестандартной палитры.
#0035 #4B Не используется. Может быть забито
любым мусором.
#0080(**) #01 X-координата (0-79) левого верхнего
угла выводимой картинки, измеряемая
в столбцах (1 стлб= 8 пикс= 1 байт)
#0081(**) #01 Y-координата (0-199) левого верхнего
угла выводимой картинки, измеряемая
в строчках (1 стр = 1 пиксель)
#0082 #01 WIDTH - ширина картинки в столбцах
(от 1 до 80)
#0083 #01 HIGH - высота картинки в строчках
(от 1 до 200)
#0084 WIDTH*HIGH Растр монохромного изображения.
Представляет собой последователь-
ность слева направо столбцов от
1 до x (x = WIDTH), состоящих из
y байтов каждый (y = HIGH), считая
сверху вниз.
#84+WIDTH*HIGH #nnnn Растр атрибутов. Полная аналогия
растра монохромного изображения по
структуре, с той лишь разницей, что
он прилагается в упакованном по ме-
тоду RLE виде. То есть, представляет
из себя последовательность двухбайт-
ных слов, первый байт в каждом из
которых означает количество (1-255)
последовательно идущих одинаковых
байтов атрибутов, а второй байт -
собственно, само значение атрибута.
----------------------------------
Примечания:
*) НОВОВВЕДЕНИЕ специально для утилиты GRFVIEW. В оригинале -
неиспользуемый участок. Может быть забит любым мусором.
**) Необязательные параметры X и Y картинки, особенно для утили-
ты GRFVIEW, где изображение автоматически центрируется, в соот-
ветствии со своими габаритами.
Теперь, что касается палитры: если конвертировать ТОЛЬКО в данные режим, можно подбирать любую адаптивную палитру - на PROFI такая картинка, если будет полноразмерная может не влезть целиком в экран по ширине (зато с избытком поместится по длине ибо 640х200 на ATM против 512x240 на PROFI). Но если задача сделать так, чтобы картинка нормально смотрелась и на GMX и на АТМ, значит надо конвертировать в спектрумовскую палитру. А она в этом заголовке будет выглядеть так (далее подразумеваются не цифры, а символы ASCII цифр):
000 - черный
002 - синий
020 - красный
022 - фиолетовый
200 - зеленый
202 - голубой
220 - желтый
222 - белый
000 - снова черный
003 - ярко-синий
030 - ярко-красный
033 - ярко-фиолетовый
300 - ярко-зеленый
303 - ярко-голубой
330 - ярко-желтый
333 - ярко-белый
При конвертации картинок надо помнить, что как и в GMX, пиксели по горизонтали "сплюснуты" в два раза по сравнению со спектрумовским режимом.
- - - Добавлено - - -
- На АТМ похоже формат столбиками, а не линейный.
Именно так. Причем сначала идут столбики биткарты, а затем столбики атрибутов, которые к тому же упакованы (метод описан выше). Сам формат байта атрибутов аналогичесн атрибуту в режиме спектрум-экрана, за исключением того, что бит флэш-мерцания заменен на отдельную яркость для INK и PAPER (в случае стандартной спектрумовской палитры, естественно. А по сути - это четвертый бит для выбора одного из 16 цветов). Итого получаем:
Биты:
0,1,2 - цвет для INK
3,4,5 - цвет для PAPER
6 - яркость для INK
7 - яркость для PAPER
- В новом формате нужна чёткая метка что за версия формата. А то не отличить АТМ от Профи.
Можно для отличия использовать поиск надписи "GRF" в заголовке (три байта по смещению 0030hex), и так определять, что это АТМ. Если попадется древний файл из CP/M, который этих букв не содержит (так как это моя модификация заголовка, не мешающая просмотру картинок СТАРТЫМИ вьюверами и редактором 90-х), то их можно вставить через любой HEX-редактор,а число картинок с модифицированным заголовком давно уже в разы превысило "древние" картинки.
- Наверно и палитра нужна, без неё не выйдет.
Собственно, формат палитры в заголовке я описал. А если конвертировать палитру с современных картинок (предварительно ужав до 16 цветов одновременно), переводя 24-битный цвет (где кажая компонента RGB имеет значение от #00 до #FF), то так как палитра АТМ имеет глубину цвета в два бита, то можно или просто в PC-палитре отбрасывать бладшие 6 битов каждо компоненты (и тогда RGB будут иметь только значения #00,#40,#80, #C0), а лучше брать усредненные значение - #00,#55,#AA,#FF - как показывает практика, они наиболее адекватны. Я в фотошопе "баловался" с адаптивной палитрой - получалось весьма неплохо.
Максагор, спасибо. Я вот ещё в палитрах ничего не понимаю. В граф. редакторе понятно как выбрать значения RGB и посмотреть что это за цвет. Но
- В заголовке мы описали какие в этой картинке цвета. А в конкретном атрибуте как они кодируются? Так же как обычно в ZX битами 0-5?
- Где почитать как приводить к ZX палитре эти варианты RGB?
О, уже ответил похоже.
Максагор
23.09.2020, 13:40
Максагор, спасибо. Я вот ещё в палитрах ничего не понимаю. В граф. редакторе понятно как выбрать значения RGB и посмотреть что это за цвет. Но
- В заголовке мы описали какие в этой картинке цвета. А в конкретном атрибуте как они кодируются? Так же как обычно в ZX битами 0-5?
- Где почитать как приводить к ZX палитре эти варианты RGB?
О, уже ответил похоже.
Тогда специально заострю внимание на спектрумовской палитре:
G R B
=========
#00 #00 #00 - черный
#00 #00 #AA - синий
#00 #AA #00 - красный
#00 #AA #AA - фиолетовый
#AA #00 #00 - зеленый
#AA #00 #AA - голубой
#AA #AA #00 - желтый
#AA #AA #AA - белый
#00 #00 #00 - снова черный (если делать имитацию "ярко-черного" как на некоторых самодельных клонах спектрума, т.е не 15, а 16 цветов, то можно взять значение #55 #55 #55, а в GRF-файле, соответственно, "111")
#00 #00 #55 - ярко-синий
#00 #55 #00 - ярко-красный
#00 #55 #55 - ярко-фиолетовый
#55 #00 #00 - ярко-зеленый
#55 #00 #55 - ярко-голубой
#55 #55 #00 - ярко-желтый
#55 #55 #55 - ярко-белый
P.S. Набор GRF-картинок формата АТМ для экспериментов с вьювером можно взять, например, здесь:
http://atmturbo.nedopc.com/download/isdos/grfview/grf_pict.zip
Единственное что там мало в какой из них именно спектрумовская палитра - я их почти все конвертировал через работу с адаптивной палитрой в фотошопе. Так что на GMX, где палитру менять нельзя, многие картинки будут выглядеть "неправильно" (но, как минимум, отображение "монохромной" (т.е. без вывода атрибутов) части будет нормальным, и, кстати, монохромные картинки там тоже есть), а вот на PROFI нормальный просмотр цветов возможен.
Хорошо, вот я взял наугад картинку. Там цвета 000101212323100110221332120231130121232333222111. Второй цвет 101 в какой цвет ZX пересчитается? И как.
Максагор
23.09.2020, 14:01
Хорошо, вот я взял наугад картинку. Там цвета 000101212323100110221332120231130121232333222111. Второй цвет 101 в какой цвет ZX пересчитается? И как.
Смотри, я уже говорил, что глубина цвета в палитре АТМ - 2 бита, а значит каждая компонента RGB имеет 4 уровня яркости (от 0 до 3, которые будут соответствовать на PC цветам #00, #55, #AA, #FF). Например, возьмем "R":
0 (#00) - цвет выключен (т.е. черный)
1 (#55) - тускло-красный - аналога на Спектруме нет
2 (#AA) - КРАСНЫЙ (аналог красного в режиме BRIGHT 0 на спектруме)
3 (#FF) - ЯРКО-КРАСНЫЙ (аналог красного в режиме BRIGHT 1 на спектруме)
Если мы берем указанный вами пример "101", который соответствует компонентам GRB, то получим смесь тускло-зеленого, выключенного красного и тускло-синего - т.е. ТУСКЛО-ГОЛУБОЙ цвет. А так как этот цвет "101" идет вторым по счету в палитре (если считать с единицы, или первым, если считать с нуля), то этот тускло-голубой включится вместо стандартного спектрумовского синего, подменив его собой.
- В новом формате нужна чёткая метка что за версия формата. А то не отличить АТМ от Профи.
Это всё в заголовке. И не только это.
- Наверно и палитра нужна, без неё не выйдет.
Палитра необходима, это да. Да же для тех машин, где её нет. Но это не сложно. Для 16 цветов это всего 16 байт. Провести их анализ и пересчёт не проблема, а процедуры скорее всего будут универсальные для всех машин.
- Где посмотреть палитру профи? Которая 16 цветов.
Они чем не отличается от стандартной для спекки.
Формат экрана Профи описан в моей статье в журнале ЗаРулём №25, а примеры загрузки на него GRF картинки в №26.
Всего шесть с тем что у меня уже есть.
Скорее всего больше. У меня 4 процедуры для загрузки формата GRF. Для картинок по ширине равных экрана и нет, и отдельно для ч/б и цветных картинок. Это нужно для оптимизации по скорости загрузки и вывода данных. Реально их 8 штук, так как реализовал два разных метода переброски данных.
Но думаю для "не родных" форматов экрана можно писать универсальные процедуры.
Ну так может всю эту последовательность "000101212323100110221332120231130121232333222111" можно принять за обычные цвета спека 0-15? Второй синий, третья триада красный... В общем тупо использовать атрибуты картинки как обычные ZX. Но бит мерцания погасить.
Максагор
23.09.2020, 14:20
Ну так может всю эту последовательность "000101212323100110221332120231130121232333222 111" можно принять за обычные цвета спека 0-15? Второй синий, третья триада красный... В общем тупо использовать атрибуты картинки как обычные ZX. Но бит мерцания погасить.
Обычная палитра спектрума в этой последовательности в заголовке будет выглядеть так:
"000002020022200202220222000003030033300303330333"
Просто спектрумовская палитра - это частный случай настройки 16-ти цветовых позиций. Просто имеем позиции для цветов от 0 до 15.
В стандартной спектрумовской настройке позиции 0-7 занимают цвета от черного до белого с выключенной яркостью, а от 8 до 15 - с включенной, только и всего.
А при ПРОГРАММИРОВАНИИ палитры можно в эти позиции забить даже ОДИНАКОВЫЕ цвета. Например, такая последовательность вообще ВЫКЛЮЧИТ все цвета:
"000000000000000000000000000000000000000000000000"
Она просто вместо всех цветов во все позиции запишет ЧЕРНЫЙ. И, кстати, это используется в софте, например, чтобы моментально погасить экран и спрятать процесс его обнуления/обновления.
В целом понятно. Надо пробовать кодить ).
им было присвоено "свободное" расширение GRF - производная от названия редактора GRAF
Вывод: 1) это совершенно разные форматы. 2) на мой взгляд, тут допущена ошибка в выборе названия расширения, так как данное уже занято, при чём как минимум с начала 90х.
Теперь уже как есть, придётся усложнять алгоритм разбора заголовка.
в том же стандартном факле картинок BMP также заголовок и данные о палитрке помещены в начале (хотя и не так, как в BLK/GRF, что естественно)
Насколько я понял из анализа имеющейся информации, формат GRF был "позаимствован" на Профи с других машин. Подробностей найти не смог, но сами возможности формата выходят далеко за возможности экрана Профи. И я не пойму откуда вы взяли, что у BMP палитра в вначале. Первыми символами идут "BM", а дальше технические данные о картинке, и только за ними палитра. Более того палитра может имеет переменные размеры. Повторю ещё раз, сама идея помещать в начало файла, информацию которая может иметь переменную длину, лично мне кажется не дальновидной и указывающую на плохую проработку теории. И не важно, что в данный момент на текущем железа палитра стандартна, всегда нужно думать о будущем.
зато с избытком поместится по длине ибо 640х200 на ATM против 512x240 на PROFI
За то Профи он выше, что позволяет разместить 30 строк, а не 25. Может не будем мериться чем либо?
Я не восторге от "войны" форматов в прошлом, и тем более не собираюсь её вести в настоящее время. Нужно как-то выходить из сложившейся ситуации.
Но если задача сделать так, чтобы картинка нормально смотрелась и на GMX и на АТМ
Скажу за себя, я бы хотел выработать единые механизмы и стандарты для просмотра графики на любых расширенных экранах, любых клонов.
Нужно выходить на стандартизацию.
Скажу за себя, я бы хотел выработать единые механизмы и стандарты для просмотра графики на любых расширенных экранах, любых клонов.
Нужно выходить на стандартизацию.
А мы так не придём к тому же bmp? Всеми признанный стандарт.
А мы так не придём к тому же bmp? Всеми признанный стандарт.
В существующих железных реалиях нет. Формат BMP рассчитан на 1, 4 байта на 1 точку, тогда как у нас 8 точек на 1, 2 байта. Да и структура экрана у нас "байтная".
То есть графика в формате BMP занимает до 4 раз больше места, сложнее обрабатываться, дольше грузиться и выводиться на экран. Как некий "обменный формат", формат BMP скорее всего будет использоваться. Но для хранения и вывода графики формат GRF, пока идеален.
izzx,
Цитата Сообщение от izzx Посмотреть сообщение
- Где посмотреть палитру профи? Которая 16 цветов.
Они чем не отличается от стандартной для спекки.
Поправка.
Структура описания цвета ни чем не отличается от стандартного для спекки. Но вот бит мерцания использоваться как яркость для чернил. Отдельная яркость для бумаги и чернил и позволяет говорить о наличие 16 цветов.
Для GMX, скорее всего самым разумным будет его отключать и использовать только бит яркости для бумаги. Но это дополнительная операция при выводе.
Можно задать для картинок 8 цветов, отдельный стандарт. +9 в заголовке. Например, значение 1. Что ускорит вывод таких картинок, при условии подготовки разных процедур чтения/вывода.
Но это лучше ещё раз обсудить.
NEO SPECTRUMAN
23.09.2020, 23:18
кстате на счет пол литры
машины без пол литры
вполне могли бы выдавать картинки в гигаскрине
в хардварном мультиколоре можно запилить хороший шахматный интерлейс
который будет сильно снижать уровень мерцания
кстате на счет пол литры
машины без пол литры
вполне могли бы выдавать картинки в гигаскрине
в хардварном мультиколоре можно запилить хороший шахматный интерлейс
который будет сильно снижать уровень мерцания
У меня в планах реализация просмотров максимального числа возможных форматов и методов показа. Как для стандартного экрана, так и для расширенного.
Так что если есть готовые алгоритмы или процедуры по теме, был бы очень заинтересован в их изучении.
В базовом варианте, для без палитровых машин, предлагаю приводить палитру к стандартным цветам на основе серости. Что позволит просмотреть содержимое файла. Но это потребует разбор каждого байта цвета, на цвета бумаги и чернил, замена их на соответствующие стандартные цвета, обратный сбор байта. Так как данную операцию нужно провести для каждых 8 точек, это значительно затормозит вывод.
NEO SPECTRUMAN
24.09.2020, 00:05
нужно провести для каждых 8 точек
зачем на каждые 8 точек?
сама адаптация будет быстрой
через жменю табличек
и обрабатываться будет только байт атрибутов
а байт пикселей дублируется на оба экрана как есть
а вот чтоб сделать правильную сортировку для шахматного интерлейса
ТТТТТТТТССССССССТТТТТТТТС ССССССС
ССССССССТТТТТТТТССССССССТ ТТТТТТТ
ТТТТТТТТССССССССТТТТТТТТС ССССССС
ССССССССТТТТТТТТССССССССТ ТТТТТТТ
где
Т - более "темные" 2 байта
С - более "светлые" 2 байа
уйдет достаточно много времени
если прикинуть на глаз думаю будет дето 1...2 секунды в лучшем случае
- - - Добавлено - - -
конечно можно сделать простой черезстрочник
без проверки яркости 8х1 знакоместа
это будет на порядок быстрее
и вполне будет работать
- - - Добавлено - - -
зачем на каждые 8 точек?
другими словами я говорю просто про имитацию палитры средствами гигаскрина
а не про конвертацию картинки
- - - Добавлено - - -
я могу нафотошопить как оно будет выглядеть
чтоб было видно стоит оно того или нет
только мне нужна АТМ-ная 640х200 картинка с пол литрой
вангую что для многих цветов не будет полноценной альтернативы
и что некоторые детали будут съедатсо
NEO SPECTRUMAN
24.09.2020, 02:32
вот 640x200 ATM c поллитра
и 640х200 GMX без поллитра рядом
без какой либо сортировки
просто шахматка 8х2
хотя примитивную сортировку можно сделать на уровне самих стаблиц
смотреть со скоростью развертки монитора
ATM
https://jpegshare.net/images/9b/33/9b333c618fe331a727186512bb8072bf.png
GMX gigascreen
https://jpegshare.net/images/4a/78/4a78c1c685084a4a1268b10421913bc6.png https://jpegshare.net/images/ca/8a/ca8a91cea0473cfeb23199b2343025f8.gif
ATM
https://jpegshare.net/images/20/f3/20f3c3158c8661690a6bee3d9b77588e.png
GMX gigascreen
https://jpegshare.net/images/24/fe/24fe7cfb80f64474a47f844126d7de2b.png https://jpegshare.net/images/3c/47/3c4795171bdcc944781481e234872176.gif
ATM
https://jpegshare.net/images/dc/28/dc28e98ce252bd1fe10ed36d172f9a7c.png
GMX gigascreen
https://jpegshare.net/images/e9/de/e9deccd7adf51a8fa8c24b3c4adf5e44.png https://jpegshare.net/images/4d/c6/4dc6ce6df7e8130f6cf9631b2ceeeede.gif
- - - Добавлено - - -
ну и конечно альтернативы для всех цветов нет
АТМ
https://jpegshare.net/images/3d/5c/3d5cd1576d712bc75be81f5df67852e0.png
GMX gigascreen
https://jpegshare.net/images/8a/2f/8a2f17a3aec58e19a4806cc8ba34e996.png https://jpegshare.net/images/08/48/08481193a89421ac63fb8bf65f587647.gif
и некоторые цвета лучше подставить в таблицу ручками
тк автоматический результат местами не торт...
ну и есное дело таблицы нужно делать под 2 варианта спековской палитры
alone и pulsar
и переключать их с менюшки
Набор GRF-картинок формата АТМ для экспериментов с вьювером можно взять, например, здесь
Подскажи, а является ли файл 250gto.grf из архива корректным? По моим экспериментам у него не хватает байтов в области атрибутов. А у многих файлов наоборот - есть лишние байты в области атрибутов.
Можно задать для картинок 8 цветов, отдельный стандарт. +9 в заголовке. Например, значение 1. Что ускорит вывод таких картинок, при условии подготовки разных процедур чтения/вывода.
Если в вашем чудо-конвертере будет поддержан такой формат, я могу прикрутить к своему вьюверу.
Второе. Для конвертации цветов действительно может нужна таблица один раз набитая скажем для профи 256*3 размером. И тогда легче пересчитывать цвета в 16. Я ещё не думал как конкретно преобразовывать, может и лишнее.
Третье. Надо ли делать поддержку прокрутки не влезающих по высоте картинок? По ширине так точно думаю показывать максимум 640 точек. Я ещё только прикручиваю ч.б. картинки от профи, а они длинные по высоте.
NEO SPECTRUMAN
24.09.2020, 12:00
Третье. Надо ли делать поддержку прокрутки не влезающих по высоте картинок? По ширине так точно думаю показывать максимум 640 точек. Я ещё только прикручиваю ч.б. картинки от профи, а они длинные по высоте.
просматривал виевереы на втрд
и вощем это прикольная функция
вот только бы как то еще информировать что там за пределеами еще что то есть
а то это не вчевидно
может не бегунки а хотя бы стрелки(которые потом исчезают) показывающие что есть продолжение
или хз
Максагор
24.09.2020, 12:16
Подскажи, а является ли файл 250gto.grf из архива корректным? По моим экспериментам у него не хватает байтов в области атрибутов. А у многих файлов наоборот - есть лишние байты в области атрибутов
250gto действительно поврежден, причем поврежден еще на дискетах от МикроАРТа. А лишние байты могут быть - редактор GRAF избыточно сохраняет почему-то.
Если в вашем чудо-конвертере будет поддержан такой формат, я могу прикрутить к своему вьюверу.
Второе. Для конвертации цветов действительно может нужна таблица один раз набитая скажем для профи 256*3 размером. И тогда легче пересчитывать цвета в 16. Я ещё не думал как конкретно преобразовывать, может и лишнее.
Функция будет. Но тут оказалось всё сложнее, чем на первый взгляд. Для нормального отображения картинки на реальном железе, стандартные цвета ЗХ в палитры должна идти строго в определенном порядке. Но нет ни каких гарантий, что они в таком порядке идут в исходной BMP. То есть нужно: 1) проверить в цвета в палитре на соответствие стандартным цветам ЗХ. 2) отсортировать их в нужно порядке. 3) внести изменение в загруженный (или уже сконверченный) файл. Так же нужны подпрограммы: удаление цвета из палитры, сортировка палитры (несколько вариантов), приведение цветов в палитре к стандартным цветам ЗХ. А так же подготовить несколько алгоритмов конверсии, скорее всего их будет 2-4. Есть изменении в процедурах формирования GRF, работа с цветом будет разная. Ну и возможно что-то упустил.
Короче, возни оказалось в разы больше чем планировалось изначально, так что всё затягивается.
Третье. Надо ли делать поддержку прокрутки не влезающих по высоте картинок? По ширине так точно думаю показывать максимум 640 точек. Я ещё только прикручиваю ч.б. картинки от профи, а они длинные по высоте.
В моём въювере под CP/M есть верительная прокрутка. Горизонтальная так же планируется, но так как мне она особо не нужна, а других пользователь программы я не знаю, её реализация постоянно откладывается.
Из-за того, что на хранения размеров у меня выделено только 1 байт, размер просматриваемой картинки ограничен 2048х2048. Что на мой взгляд покрывает все возможные потребности.
Максагор
24.09.2020, 14:52
Насколько я понял из анализа имеющейся информации, формат GRF был "позаимствован" на Профи с других машин. Подробностей найти не смог, но сами возможности формата выходят далеко за возможности экрана Профи. И я не пойму откуда вы взяли, что у BMP палитра в вначале. Первыми символами идут "BM", а дальше технические данные о картинке, и только за ними палитра. Более того палитра может имеет переменные размеры. Повторю ещё раз, сама идея помещать в начало файла, информацию которая может иметь переменную длину, лично мне кажется не дальновидной и указывающую на плохую проработку теории. И не важно, что в данный момент на текущем железа палитра стандартна, всегда нужно думать о будущем.
Ну у меня тоже нет какой-либо информации о том, что расширение GRF где-то закреплено за каким-то универсальным форматом, типа BMP. Поэтому и не рассматриваю его как что-то, из чего следуют какие-то "обязательства". Только напомню то, что уже говорил - в АТМовской CP/M эти картинки имеют расширение BLK, а расширение GRF пришлось ввести в iS-DOS/TASiS при написании вьювера, так как в этих системах расширение BLK еще с самого основания системы зарезервировано за драйверами блочных устройств (флоп, винт, RAM и так далее). ИМенно таким расширение выбрано из-за названия графического редактора под CP/M "GRAF", который может эти картинки создаватьи редактировать.
Что же касается палитры, то мне казалось, что я достаточно четко сказал, что в BMP заголовок и палитра (а я ее рассматриваю как часть заголовка) идут ВНАЧАЛЕ файла, ПЕРЕД растром. в АТМовской BLK/GRF также заголовок в 132 байта идет ПЕРЕД растром. При этом палитра действительно идет в самых первых 48-ми байтах заголовка. Но в отличие от BMP эта палитра по размеру фиксированная.
За то Профи он выше, что позволяет разместить 30 строк, а не 25. Может не будем мериться чем либо?
Я не восторге от "войны" форматов в прошлом, и тем более не собираюсь её вести в настоящее время. Нужно как-то выходить из сложившейся ситуации.
[оффтопик ON]
Мне кажется, что я за все годы нахождения на форуме вроде бы не давал повода подозревать в том, что я веду какие-то "межплатформенные" или "межформатные" войны. Мне как-то с подросткового возраста давно неинтересно мерянье пиписьками. И тем не менее, время от времени то тут, то там возникают какие-то инсинуации, намеки и проч. Возможно, иногда некоторые пользователи настолько увлекаются срачами и холиварами форума, что автоматически переносят кальку поведения их достаточно ограниченного количества участников на всех остальных форумчан.
Мне, повторюсь, холивары и выяснения у кого длинее не интересны. Я повторяю лишь то, что сказал и только то, что имел ввиду - что с учетом того, что максимальный размер мультиколорной картинки BLK/GRF равен экрану АТМ 640х200 (а также и GMX), то на экране PROFI 512х240 он не влезет. И наоборот - картинка размером с экран PROFI НЕ ВЛЕЗЕТ в экран АТМ по высоте. Писал я это с намеком на то, что где бы не писали универсальный просмотрщик мультиколорных картинок - на PROFI, ATM или Скорпион+GMX, придется предусмотреть скролл/прокрутку. Только и всего.
Скажите, что подвигло вас толковать мои слова по иному, "в негативном" ключе? Потому что я теряюсь в догадках, где я дал такой повод? Предлагаю в нашем общении раз и навсегда закрыть эту страницу "подозрений" и общаться нормально.
[оффтопик OFF]
Кстати, под спектрум в TR-DOS существуют еще и пару версий редактора мультиколорных картинок MEGA SCREEN. Они выложены на сайте "Virtual TR-DOS" с примерами картинок в комплекте. Форматы этих картинок тоже можно поддержать во вьювере.
В существующих железных реалиях нет. Формат BMP рассчитан на 1, 4 байта на 1 точку, тогда как у нас 8 точек на 1, 2 байта. Да и структура экрана у нас "байтная".
То есть графика в формате BMP занимает до 4 раз больше места, сложнее обрабатываться, дольше грузиться и выводиться на экран. Как некий "обменный формат", формат BMP скорее всего будет использоваться. Но для хранения и вывода графики формат GRF, пока идеален.
Так как я сам в свое время писал просмотрщик BMP-картинок под iS-DOS, то вроде бы не забыл еще, что формат BMP рассчитан на число 1, 4, 8 или 24 БИТА на точку. Вы. Наверное, просто перепутали. Так, например, 16-цветный BMP-рисунок размером 320х200 весит чуть меньше 32Кб - так как цветов 16, то выделяется 4 бита на пиксель, в результате в одном бйте содержится ДВА пикселья. Т.е. 320 пикселей в ширину - это 160 байт. 160х200=32000 байт, плюс впереди заголовок с меткой, параметрами и палитрой. Но если мультиколорную картинку держать в BMP-формате, то тогда файл действительно раздуется. Ибо там, где в мультиколоре есть 1 байт "растра" ил 8 монохромных "однобитных" пикселей и 1 байт единого атрибута для этих пикселей, то в 16-тицветном BMP будет целый 4 байта по два 4-битных пикселя в каждом. Файл раздуется в ДВА раза.
Но согласен с вами, что BMP годится скорее как "обменный" формат - быстро "на ходу" конвертировать его в мультиколор не получится. Да даже в гафическом режиме "каждая точка своим цветом" 320х200 на АТМ 16-цветный BMP не является самым оптимальным форматом для скорости вывода. Для быстрого вывода растровых спрайтов для этого был придуман формат BMS (и написан конвертер из BMP в BMS), где основные отличия - расположение в файле байтов растра не "линиями", а "столбцами" (плюдс еще пару моментов) - т.е. под более удобную и оптимальную работу со структурой экрана на АТМ. Само собой, таковой формат не будет оптимальным на других машинах с расширенной графикой, где структура расширения несколько иная. Поэтому я совмневаюсь в том, что возможен некий единый ОПТИМАЛЬНЫЙ формат. Единый - да, оптимальный - сомневаюсь.
NEO SPECTRUMAN
24.09.2020, 15:20
Само собой, таковой формат не будет оптимальным на других машинах с расширенной графикой, где структура расширения несколько иная. Поэтому я совмневаюсь в том, что возможен некий ежиный ОПТИМАЛЬНЫЙ формат. Единый - да, оптимальный - сомневаюсь.
для хардварных мультиколоров больших размеров
такой формат будет в любом случае оптимальней чем бмп
тк хранение именно в виде пиксели и атрибуты
а не в виде пиксели и пиксели...
Максагор
24.09.2020, 15:54
Третье. Надо ли делать поддержку прокрутки не влезающих по высоте картинок? По ширине так точно думаю показывать максимум 640 точек. Я ещё только прикручиваю ч.б. картинки от профи, а они длинные по высоте.
Конечно делать!
. Для быстрого вывода растровых спрайтов для этого был придуман формат BMS (и написан конвертер из BMP в BMS), где основные отличия - расположение в файле байтов растра не "линиями", а "столбцами" (плюдс еще пару моментов)
Если есть описание формата было бы интересно посмотреть. Вообще неплохо бы собрать собрать описание всех форматов в одном месте, например создать профильную тему, где в шапке хранить описание и ссылки на них, а ниже обсуждать.
NEO SPECTRUMAN
24.09.2020, 16:13
форматов в одном месте, например создать профильную тему, где в шапке хранить описание и ссылки на них, а ниже обсуждать.
к форуму прикручена же вики
что формат BMP рассчитан на число 1, 4, 8 или 24 БИТА на точку
однобитные это ч/б изображения, а мы говорили цветных. Но даже такие файлы будут в обработке тормозить. 4 битный и 8 битные почти идентичны. Просто 4 битных, информация упакована более плотно. На практике 4 битные файл в большинстве случаев можно встретить, только если создать их самим, и то система упорно будет пытаться сохранить 8 битные файлы.
Ну у меня тоже нет какой-либо информации о том, что расширение GRF где-то закреплено за каким-то универсальным форматом
Допускаю, но это лишь подтверждает плохую проработку теории. Формат GRF существовал почти "всегда" на "прямом конкурент АТМ". По себе судить не очень хорошо, но скажу, что я бы первым делом изучил документы на конкурента, может там уже решены мои задачи, а воспользоваться чужим опытом ни когда не грех. Но это лирика, уже как есть. тут и моя ошибка, услышав название "grf", я без проверки сделал не верное предположения об схожести форматов.
под спектрум в TR-DOS существуют еще и пару версий редакторма мультиколорных картинок MEGA SCREEN.
Нужно поддерживать :) При чем код на всех клонах минимум на 40% будет одинаковым, а часто до 90%.
- - - Добавлено - - -
к форуму прикручена же вики
И как я должен узнать что нужный мне формат вообще существует и назваться вот так? Или что есть несколько форматов решающих сходные задачи?
NEO SPECTRUMAN
24.09.2020, 16:18
И как я должен узнать что нужный мне формат вообще существует и назваться вот так? Или что есть несколько форматов решающих сходные задачи?
результат лучше тулить в вики
оно могут редактировать несколько человек
а первый пост может редактировать только один и все обновлятельство вешается на него
потом энтузиазм заканичивается и первый пост не обновляется...
100500 тем таких на форуме уже
давайте делать еще столько же
результат лучше тулить в вики
Хорошо. Мне нужны форматы фалов для гагаскриновских картинок и образци процедур для их вывода. Как мне найти это в вики?
При этом не знаю ни правильного названия ни одного из элементов вопроса.
NEO SPECTRUMAN
24.09.2020, 18:02
Хорошо. Мне нужны форматы фалов для гагаскриновских картинок и образци процедур для их вывода. Как мне найти это в вики?
При этом не знаю ни правильного названия ни одного из элементов вопроса.
отлично
вместо ты предлагаешь помойку на 300 пстов в которой с таким же успехом нельзя найти форматы фалов для гагаскриновских картинок и образци процедур для их вывода
а если и не помойку то выглядит это как портянка
про поиск средствами форума вообще молчу
тк он что есть что нет...
про поиск средствами форума вообще молчу
Что бы что-то искать нужно иметь хотя бы минимальные знание о том что ищешь. Как искать если ты ни чего толком не знаешь, только хотелки в голове?
Вот пример с форматом GRF, Максагор пишет, что когда создавал свой формат даже не знал, что уже есть формат с тем же расширением для тех же задач. И по этому создал несовместимый дубликат. Что сильно помог поиск по форуму? Или как быть мне, я знаю что под стандартный экрана есть ряд программный инструментов для расширения цветности. Есть даже статья с их описанием. Но ни где нет ни описание существующих форматов файлов, ни готовых библиотек, ни описание алгоритмов. Вернее 70% из этого в инете есть, но размазано тонким слоем. Что бы собрать инфу нужно около недели выискивать её крохи. Офигенно!
вместо ты предлагаешь помойку на 300 пстов в которой с таким же успехом нельзя найти форматы фалов для гагаскриновских картинок
Видел форум 4pda.ru? На каждую тему отдельная ветка, в шапке всё структурировано, большие объёмы текста спрятаны под спойлеры, ссылки либо прямо в шапке, либо в шапке ссылки на сообщения от куда качать. Нужно что-то найти, достаточно знать 2 слова по проблеме, после чего нужная ветка находиться в течении 5 минут. А уже из неё достаётся вся нужная инфа. Пропал модератор темы, админы форума могут назначить нового, даже выборы проводятся, как в фидо.
У нас же, чёрт ногу сломит. Сейчас у нас как раз мусорка (с точки зрения хранения информации), без возможности найти нужную инфу.
Вот что я бы хотел получить.
тк он что есть что нет...
Я задал прямой вопрос, как мне найти нужную инфу. Указал пример "запроса". Надеялся получить пошаговую инструкцию, а получить пост на философские темы.
На мой взгляд алгоритм должен быть следующем:
1. в поиске по форуму вбиваем "программные расширения графики" или аналогичное.
2. находим одноименную ветку.
3. где в первом посте перечислены все возможные расширения, с кратким описанием, с ссылкой на ветку по обсуждению.
4. впервом посте которой: подробное описание, примеры кода и т.п.
Если появляется новы тема по данному вопросу, она в обязательном порядке переносится в существующую. Флейм чистить безжалостно. Для нарушитель правил +++**!
И так по каждой теме.
NEO SPECTRUMAN
25.09.2020, 01:41
Я задал прямой вопрос, как мне найти нужную инфу. Указал пример "запроса". Надеялся получить пошаговую инструкцию, а получить пост на философские темы.
ну твой вопрос выглядел как сферически философский
и такой же ответ ты на него получил :)
- - - Добавлено - - -
На мой взгляд алгоритм должен быть следующем:
1. в поиске по форуму вбиваем "программные расширения графики" или аналогичное.
2. находим одноименную ветку.
3. где в первом посте перечислены все возможные расширения, с кратким описанием, с ссылкой на ветку по обсуждению.
4. впервом посте которой: подробное описание, примеры кода и т.п.
а твоем алгоритме ошибка
поиском по форуме ты находишь ровным счетом ничего
у тебя просто жменя тем содержащие такие же буквы или в лучшем случае последние темы где было разовое упоминание одного из искомых слов...
- - - Добавлено - - -
Видел форум 4pda.ru? На каждую тему отдельная ветка, в шапке всё структурировано
видел
но тут зхпкру
тут нет ни прилепленных постов
ни кураторов темы
много чего тут нет...
да и поиск по моему там лучше работает
и новые подразделы для лучшей сортировки тут выпрашивают годами....
Максагор
25.09.2020, 14:37
Что бы что-то искать нужно иметь хотя бы минимальные знание о том что ищешь. Как искать если ты ни чего толком не знаешь, только хотелки в голове?
Вот пример с форматом GRF, Максагор пишет, что когда создавал свой формат даже не знал, что уже есть формат с тем же расширением для тех же задач. И по этому создал несовместимый дубликат. Что сильно помог поиск по форуму?
Специально, чтобы закрыть вопрос о том, какие были и есть форматы - историческая справка:
Я так и не понял, есть ли какой-то единый стандарт GRF? Да, есть такая графика в версии CP/M для PROFI. Но CP/M как некая стандартная база - это изначально "текстово-консольная ОС". Все графические примочки уже нестандартны и "индивидуальны" для каждой машины с графическими возможностями. Т.е. файлы графики под такие "системы графики" не могут быть какими-то абсолютно универсальными.
Далее - сам формат мультиколорной графики на АТМ был создан МикроАРТом еще примерно в 1991 году. Только в самой CP/M имел он расширение BLK. Раньше или позже это создания такого формата на PROFI лично мне неизвестно. Но приедполагаю, что примерно одновременно (чуктьо раньше/чуть позже), а главное, независимо друг от друга, так как фирмы, создававшие спектрум-клоны и софт под них работали независимо друг от друга, и в отсутствии всераспространенного интернета регулярно друг с другом не общались и не координировались.
Это я к тому, что не могу уверенно утвержать, или принять со стороны утверждение, что какой-то "стандартный стандарт/формат для конкретных задач" уже существовал, на который "надо было равняться".
Что касается меня, то повторяю - я свой формат не создавал. Я просто изменил расширение BLK на GRF при создании поддержки в среде iS-DOS/TASiS (утилита GRFVIEW.COM) СУЩЕСТВУЮЩЕГО с 1991 года на АТМ формата мультиколорной картинки, и только потому, что расширение BLK в этой системе занято под драйвера - и там это как раз стандарт и менять это нельзя. Сам формат файла и растра в нем не менялся. При копировании этих файлов обратно на диск с CP/M (да хоть на диск с профинским Concurrent DOS) можно для того, чтобы не было путаницы, переименовать эти файлы обратно в BLK, и никакого ущерба для них не будет. И да - вьювер я писал (и, соответственно, менял расширение) еще ДО СОЗДАНИЯ данного форума - в 2004 году, тогда вообще по "ПРОДВИНУТЫМ" клонам спектрума выше Пентагона в том еще интернете было мало. Вести работы по стандартизациибыло затруднительно.
В любом случае - сейчас наша общая задача тут (как я ее понимаю) собрать информацию по уже всем имеющимся по факту форматам мультиколорных картинок для создания хорошего универсального вьювера - хоть под GMX, хоть под PROFI, хоять под другие машины. Чем больше форматов будет поддержано для отображения, тем лучше. Вот это хорошая, позитивная задача. По сути - это задача "на стыке" разных спектрум-клонов, поэтому, собственно, я и включился в даннуюдискуссию и привел формат, относящийся к АТМ.
Но CP/M как некая стандартная база - это изначально "текстово-консольная ОС". Все графические примочки уже нестандартны и "индивидуальны" для каждой машины с графическими возможностями.
Чисто из "вредности", так как здесь логическая ошибка. Всё так, но не учитывается возможность заимствования формата с других машин. Вот ещё раз кусок из описания формата GRF
BPP AMOD режим хранения информации
--- ---- -----------------------------------------
8 0 PROFI-mono
4 0 PROFI-color (байты точек и аттрибутов чередуются, точки раньше аттрибутов)
2 1 CGA (4 цвета, байт описывает 4 точки)
4 1 EGA (16 цветов, байт описывает 2 точки)
5 1 VGA (32 цвета, байт описывает 1 точку)
8 1 VGA (256 цветов, байт описывает 1 точку)
Причем я встречал вроде картинки только PROFI-color (байты точек и аттрибутов чередуются, точки раньше аттрибутов) и Profi-Mono
Тут видно что из 6 возможных вариантов, только два относятся к Профи, а так формат поддерживает графику до уровня VGA. Предпоследняя фраза из оригинального описания формата к графическому редактору, и из неё можно сделать вывод, что формат заимствованный. Откуда его взяли, понятия не имею, но было бы интересно узнать.
В любом случае - сейчас наша общая задача тут (как я ее понимаю) собрать информацию по уже всем имеющимся по факту форматам мультиколорных картинок для создания хорошего универсального вьювера - хоть под GMX, хоть под PROFI, хоять под другие машины. Чем больше форматов будет поддержано для отображения, тем лучше.
Тут да. Но думаю конечную задачу следует рассматривать шире. Нужно выработать единый подходы по всему спектру задач, на выходе получить среду или движок на подобие MK1 или AGD, который бы позволил быстро адаптировать игры под разные графические режимы и иные особенности разных клонов.
Начнём пока с графики, так как это наиболее ёмкая часть задачи.
Да тут уже грандиозные планы. Написание универсального просмотрщика, как я понимаю, могло бы получиться при наличии драйверов для разных экранов. Чтобы просто отобразить картинку хватит, а всякие гигаскрины уже слишком сложно. У меня была мысль, что может было бы проще взять готовый продвинутый вьювер и добавить в него поддержку разных экранов. Но добавить может только автор. А так кто будет писать единый универсальный?
NEO SPECTRUMAN
25.09.2020, 19:14
а всякие гигаскрины уже слишком сложно
для цветов на точку и хардварных мультиколоров это тьфу
вон даже алоновиевер
не все открывает картинке на всем
а некоторые только на накотором железе (по моему)
вон даже алоновиевер
не все открывает картинке на всем
а некоторые только на накотором железе (по моему)
Да, а он мог бы, наверно, за вечер написать просмотр всего на всём.
Да тут уже грандиозные планы.
Планы обычные. Нужно понимать куда движешься, и это понимание будет накладываться на принятые решения.
Написание универсального просмотрщика, как я понимаю, могло бы получиться при наличии драйверов для разных экранов.
Для вьювера в теории можно. И то я бы не делал. Для движка нет. Вернее так, это будут не только драйвера. Выше писал, что нужна "система" или "среда", называйте как удобнее.
Тут целый ворох проблем. Экраны разного размера и разных пропорций, а значит графика и спрайты будут весить по разному. Структуры экранов разные, а значит будут оптимальны разные алгоритмы вывода. Экраны размещаться в разных частях памяти, расширенные вообще в страницах. У разных клонов окно проецирования могут открываться в разных местах. ПЗУ может отключаться или нет. И т.п. и т.д. По этому ИМХО задачу вывода просмотра картинок с диска, оптимальнее решать в лоб. Общими для разных клонов будут базовые алгоритмы, но на их не сложно обернуть в код. Как пример, снова ссылаюсь на свою статью в 26 номере журнала "ЗаРулём". Кстати, было интересно услышать, способно или нет такое изложение помочь в работе с другими форматами экрана.
Если говорить о выводе спрайтов, то тут общими будет логика принятия решения, организации карт и прочее, индивидуальными процедуры вывода низкого уровня. Но и в этом случае придётся идти на значительные компромиссы. Но всё это нужно решать только после решения вопроса написания вьювера файлов с диска, так как это даст базовые вводные.
Пока я не могу придумать как обойти не отключаемость ПЗУ. Скорее всего придётся ввести в требование, что ПЗУ по любому должно отключаться. Хотя "война план покажет", возможно это пока не вижу путей решения. "Север, юг. Самое сложное определить где здесь запад и восток. Но это я обычно решаю в пути" (с) Троё в лодке не считая собаки.
Специально для NEO SPECTRUMAN попытался снять знаменитый "снег" на экране gmx. Прямо с экрана трубчатого ТВ. По левому краю мельтешит немного. А в gmx comander и с правого краю тоже. Вообще видно этот эффект не всегда, не с любым изображением. И больше проявляется при обращении к диску. Я тут нажимаю несколько раз обновить каталоги. Ну ещё и через весь экран полосы пролетают, это уже другое. Видимо переключение экранов.
Не знаю на всех ли экземплярах gmx такое есть.
https://youtu.be/k8tb1UPLzSQ
NEO SPECTRUMAN
01.10.2020, 20:07
Специально для
зачем специально для меня
оно нужно для всех
нет смысла оно скрывать
нужно писать на каждом заборе что есть снег
и найти\заново открыть способ борьбы с ним
а то захочет кто нить сделать софтварную поддержку
а оно будет снежить на реале...
что как бы не труЪ
как обойти не отключаемость ПЗУ
А зачем ПЗУ отключать? Чтобы впихнуть целую ОС для просмотра картинок?
Статьи в журнале почитал, интересно. Для общего понимания вопроса полезно.
А зачем ПЗУ отключать? Чтобы впихнуть целую ОС для просмотра картинок?
Экран Профи весит 32кб, его можно открыть в нижних 64кб полностью (графика, цвет), или частично (только одно). Но в любом случае это значительно больше чем стандартный экран. А если ПЗУ не отключать, то свободными будет только 16кб. С иными вариантами расширенного экрана думаю картина похожая. Если говорить о простом выводе картинки, оставшегося объёма памяти будет достаточно. Но если говорить о едином движке, то нет. Размеры спрайтов увеличатся в разы, код усложнится. И как-то это всё нужно увязать. По этому лишние 16кб будут крайне полезны.
В идеале конечно же, нужна единая ОС. Но это уже следующий этап, пока же выйти хотя бы на библиотеку работы со спрайтами с единым API для большинства платформ.
В идеале конечно же, нужна единая ОС.
Читал про недоОС. Говорят, что нужны все четыре окна памяти, иначе гиблое дело писать ОС. А так в ней уже есть поддержка jpg, bmp.
Читал про недоОС.
Скажем так, "как корабль назовёшь, так он и поплывёт" (с) Ребята в детстве не читали "Капитана Врунгеля".
Смешно даже называть это нечто "ОС для спектрума", так как она физически (теоретически и практически) может быть запущена на единственной спектрум совместимой машине. То есть её разрабы предполагают, что мы возьмём и выкинем на свалку все наши Ленинграды, Пентагоны, Профи, Скорпионы и прочее и побежим молится на то что нам укажут пальцем. В перспективы этого лично я не верю от слова "совсем".
Нет, это мы даже не рассматриваем это как вариант. На спекки есть только одна базовая ОС, на основе которой, что-то можно сделать - это CP/M. Но она требует доступа ко всем нижним 64кб, и крайней желательно наличия окна проецирования не в конце памяти (там куски ОС). Существуют доработки Пентагона которые позволяют отключать ПЗУ по схем Профи, и даже есть под это дело версия CP/M. Точно не готов сказать, но вроде есть схема которая позволит перенести окно проецирования на страница 2, как у Профи.
Да же простое отключение ПЗУ, позволит реализовать единую ОС. А если перенести страницу, то это повысит скорость работы на 20-40%, но думаю можно придумать схем работы и без этого. К сожалению, это всё требует железных доработок, но если ПЗУ не трогать, то шансы реализовать что-то более менее вменяемое критично малы. Одновременно с этим, сразу несколько клонов имеют такую возможность изначально - на них и нужно ориентироваться, включая фирменный спекки. И если мне не изменяет память для фирменных 48Кб машин, было устройство подключаемое к порту расширения, которое так же позволяло отключать ПЗУ и запускать CP/M. Можно пойти по этому пути.
Но повторю, это задача даже не завтрашнего дня.
NEO SPECTRUMAN
02.10.2020, 15:08
Смешно даже называть это нечто "ОС для спектрума", так как она физически (теоретически и практически) может быть запущена на единственой спектрум совместимой машине.
не совсем на одной
а на целых двух с половиной
а так соглашусь
ОС для одной машины это долбоклюизм...
Добавил файл в первом сообщении:
2020.10.02 v1.1a
Тестовая версия.
Добавлена поддержка форматов:
GRF profi mono (ч.б.)
GRF profi 16c (седьмой бит отбрасывается, чтобы не было мерцания)
Ширина картинок макс. 640 точек, высота макс. 1000.
Если картинка выше 200 строк, мигает зелёная стрелка. Можно прокрутить вниз.
Временно убраны кнопки слайдшоу, сделать цветным и чёрно-белым.
В пак добавлено несколько старых (наверное) картинок от профи.
С дискеты грузится долго (потому что через буфер 2 сектора), с карты нормально.
Если картинка выше 200 строк, мигает зелёная стрелка. Можно прокрутить вниз.
Чисто из эстетических целей, не считаю, что закрыть часть изображения хорошая мысль, пусть и малую. У меня вообще нет подобного индикатирования. Если считаете, что оно нужно могу вынести следующие предложения:
1. за счёт бордюра. черный- прокрутка не возможна, красный -прокрутка вниз, синий -прокрутка вверх, зеленый -в обе стороны. Все цвета темные.
2. у тебя есть мерцание, используй его. Пусть мерцает одна пиксельная линий, с той стороны в которую возможна прокрутка.
GRF profi mono (ч.б.)
GRF profi 16c (седьмой бит отбрасывается, чтобы не было мерцания)
Вот собрал у себя ~70 картинок, постарался выбрать со стандартными цветами и ч.б. (хотя ч.б. ещё вагон и маленькая тележка, да и наделать можно без проблем)
https://yadi.sk/d/4C_BUzhJqzHBjg
Такой вопрос, у экрана какие пропорции относительно стандартных? Нужно ли ужимать квартирки на ПС? Если да, то на сколько?
И ещё, думаю будет уместно выложить настроенную на работу с GMX версию Унрела. Что облегчить людям "порог входа".
tae1980,
1. Забыл сказать что стрелка у меня пару раз мигнёт и исчезнет. Так что не мешает.
2. За картинки спасибо, сразу нашёл глючок небольшой. Картинки высотой ровно 200 не открывались (из папки MICKEY). Уже поправил.
3. Чтобы пропорции были правильные я на ПС делаю картинки ровно в два раза шире. Картинки от профи некоторые выглядят вытянутыми по высоте.
4.Вот унреал с настройкой на gmx. Жёсткий диск не стал включать. Надо просто запустить, нажать Shift+Ctrl+F12, оно сбросится в главное меню. Затем F3 чтобы выбрать образ дискетки. И Enter запустить.
https://cloud.mail.ru/public/5n2n/5aXuNzwMd
3. Чтобы пропорции были правильные я на ПС делаю картинки ровно в два раза шире.
Значит на сжатие на 50%
Картинки от профи некоторые выглядят вытянутыми по высоте.
Почти все картинки ч.б. с твоего диска готовил я, ещё в конце 90х. Там вообще нет сжатия.
NEO SPECTRUMAN
05.10.2020, 15:20
Пока я не могу придумать как обойти не отключаемость ПЗУ. Скорее всего придётся ввести в требование, что ПЗУ по любому должно отключаться. Хотя "война план покажет", возможно это пока не вижу путей решения. "Север, юг. Самое сложное определить где здесь запад и восток. Но это я обычно решаю в пути" (с) Троё в лодке не считая собаки.
4000-7FFF декодер картинок (возможно сменный для каждого формата) пол литры таблицы итд....
8000-BFFF буфер для части оригинального изображения
С000-FFFF окно для подключения видео памяти и для чтения оригинального изображения и кидания оно в буфер
использовать только второй экран чтобы освободить 4000-7FFF под код
все ж элементарно
но не так быстро...
4.Вот унреал с настройкой на gmx. Жёсткий диск не стал включать. Надо просто запустить, нажать Shift+Ctrl+F12, оно сбросится в главное меню. Затем F3 чтобы выбрать образ дискетки. И Enter запустить.
Спасибо. Запустил.
Скорость загрузки очень даже хорошая, скорость скроллинга то же.
Только стартует эмулятор с экрана "зависания". И при переходе между картинками через раз вылетает окно дебагера.
Только стартует эмулятор с экрана "зависания". И при переходе между картинками через раз вылетает окно дебагера.
У меня тоже с экрана зависания стартует. Может можно побороть, но пока не знаю как.
А с дебагером я накосячил. Точку останова не убрал. Вот положил туда же новый вариант. Должно теперь без остановок работать.
Скорость загрузки очень даже хорошая, скорость скроллинга то же.
Скролл всё-таки аппаратный.
А загрузка на реале медленней. В эмуле стоит галка No delay, с ней быстрее.
2020.10.07 v1.1c
Добавлен формат:
GRF profi 256c
Все 256 цветов при загрузке конвертируются в 8 стандартных.
Алгоритм прямолинейный. Если уровень цвета больше половины его диапазона,
то он принимается равным 192 (из 255). Иначе 0.
Формат байта цвета у профи GGGRRRBB.
Например, цвет G может быть от 32 до 224. Если он 128 и больше, то приравнивается к 192.
Затем из палитры ZX выбирается конкретный цвет.
Например, зелёный - это 0,192,0 RGB.
73641
- - - Добавлено - - -
Картинки для примера взяты у tae1980.
На первой странице ссылки на конвертор и эмулятор.
izzx, Очень интересно. Планировал такой режим,а ты реализовал. :) Результат вполне достойный. Замечу, что номерные картинки 34хх, переводились не мною, и возможно они сразу делались под стандартные цвета, вот только их сохранили не корректно. Если интересно могу открыть временный доступ к моему архиву GRF картинок, там пожалуй уже пару тысяч. Когда у меня клинет мозги и туплю, но делать, что-то хочется, конверчу их десятками - процесс уже отработан до автоматизма.
По поводу алгоритма пересчета, мои мысли. Их должно быть два:
1. Разбить цвета спекки на группы по 2-3 близких цвета, по серости. Если дважды при переводе палитры 16 из 256 получается один и тот же цвет, брать ближайший из группы. Если цвета в группе кончились, брать который больше подходит (на картинки пропадёт 1 цвет). Тут максимально адекватная палитра, но возможна пропажа части деталей на картинки.
2. Если при конверсии палитры 16 из 256 дважды получается один и тот же цвет, то определяем какой из двух цветов лучше подходит к стандартному цвету, для второго ищем другой цвет. Если новый цвет так же уже занят, повторяем операцию. При таком подходе неизбежны искажения цветов, но все 16 цветов будут задействованный, все детали сохранены.
Оба вариант можно переключать по горячим клавишам.
- - - Добавлено - - -
Напрашиватся ещё один вариант, конвертировать через таблицу соответствий в 256 байт. Очень быстро. Но тут так же как-то нужно решать вопрос многократного получения одного цвета. Возможно через простое смещение по таблице к ближайшем свободному цвету, по варианту 2.
Но тут проблема в том, что палитры RRRGGGBB могут быть разные. И та что использую сейчас, скорее всего некорректная. Но без реала проверить и получить правильную не могу.
С другой стороны, так как при переводе к стандартным цветам спекки и так будут округления, то небольшие искажения в палитре 256 цветов значения не имеют.
tae1980, да, картинки 34хх получше выглядят. Может изначально стандартные цвета.
Архив можно выложить что не жалко, я на первую страницу добавлю.
С продвинутой обработкой цветов сложно реализовать на ассемблере. Да ещё несколько проходов ).
Таблица соответствий 256 байт хорошо. Но больше времени тратится на расшифровку каждого байта цвета и выбор соответствущего цвета из 16.
А ещё. Приложение sea.com оно же под cp/m? Хотел запустить cp/m в унреале, и посмотреть на цвета профи, но пока не разобрался как.
NEO SPECTRUMAN
08.10.2020, 10:10
Таблица соответствий 256 байт хорошо. Но больше времени тратится на расшифровку каждого байта цвета и выбор соответствущего цвета из 16.
не совсем понел о чем речь
но
для каждой картинки палитры
можно сначала строить свою таблицу
а потом уже быстро пропускать через нее всю картинку
для каждой картинки палитры
можно сначала строить свою таблицу
а потом уже быстро пропускать через нее всю картинку
Так и есть. Сначала строится палитра 16 цветов под конкретный рисунок. В этом месте можно было бы использовать готовую таблицу соответствий. Но таблица готовится всего один раз для каждого рисунка.
А потом берётся каждый байт цвета рисунка и из него сначала выбирается цвет чернил, там ещё и биты раскиданы. Типа 6 бит + 3,2,1 биты. А потом по этому номеру выбирается цвет из построенной таблицы в 16 байт.
Затем так же с цветом папера. Куча команд rrca, потом обратно rlca у меня. Потом оптимизирую, если смогу.
NEO SPECTRUMAN
08.10.2020, 12:09
речь же про перевод хардварного мультиколора но с пол литрой?
под gmx без поллитры?
можно сразу построить таблицу на 256 байт под нужную палитру (возможно при помощи еще пары таблиц : )
потом таблице кормить оригинальный байт атрибутов
а на выходе сразу получать готовый байт атрибутов с нужным ink-ом и paper-ом
постройка большой таблицы и быстрая конвертация
может оказаться быстрее чем твои бессмысленные извращение туда сюда с таблицей на 16 байт
в придачу думаю на постройку таблицу не уйдет много времени
- - - Добавлено - - -
байт атрибутов и там и там одинаков?
так PIPPPIII ?
или у кого то из них как у спектрума FBPPPIIII ?
речь же про перевод хардварного мультиколора но с пол литрой?
под gmx без поллитры?
Да
так PIPPPIII ?
Да.
Но я пока не могу сообразить как сделать универсальную таблицу. У каждой картинки в заголовке 16 цветов, но это только индексы. И они разные каждый раз. Когда берёшь конкретный байт цвета, надо через него выйти на индекс, а потом на цвет.
NEO SPECTRUMAN
08.10.2020, 13:40
Но я пока не могу сообразить как сделать универсальную таблицу.
ну сначала находишь альтернативы для 16 цветов
делаешь 2 таблицы
где у тебя 16
P_PPP___
и 16
_I___III
вместо таблицы с папером можно ложить прямо в код
потом развернутой процедурой
раскладываешь paper-ы
чем то таким
a = paper
ld h,tab
ld l,16 ;адрес с которого последовательно заливать paper-ы 8 значений подряд
ld (hl),a
inc l
ld (hl),a
inc l
...
заполняешь все 256 значений
за одну зануляются ink-и
для ink-а можно сделать 256 байтную таблицу адресов
где первые 16 значений L адрес цвета 0
вторые 16 значений L адрес цвета 1
итд
и записывать вот таким
b = ink
ld h,tab
ld d,addrtab
ld a,(de)
ld l,a
ld a,b
or (hl)
ld (hl),a
inc e
можно немножко подумать и сделать нахождение адресов inк-а
при помощи сложения
вместо дополнительной таблицы
может будет даже быстрей (нужно считать)
и таблица готова
- - - Добавлено - - -
по тактам на глаз дето
11*256 33*256
2816+8448
11264
думаю можно рассчитывать на дето 12К тактов на постройку таблицы
и для постройки 2-х 16 байтных таблиц с P_PPP___ _I___III
на глаз думаю уйдет дето до 2К тактов
дальше сам считай
будет ли достаточный выиграшь по тактам
если конвертировать через 256 байтную таблицу
и стоит ли оно делать
ЭЭЭ... у нас за цвет отвечает 1 байт. всего 256 разных значений. Что мешает сделать так?
1. Определить базовые цвета.
2. Сделать таблицу в 256 где перечислить все возможные комбинации базовых цветов.
3. При выводе просто брать байт из этой таблицы, без каких либо вычислений.
NEO SPECTRUMAN
08.10.2020, 14:24
ЭЭЭ... у нас за цвет отвечает 1 байт. всего 256 разных значений. Что мешает сделать так?
1. Определить базовые цвета.
2. Сделать таблицу в 256 где перечислить все возможные комбинации базовых цветов.
3. При выводе просто брать байт из этой таблицы, без каких либо вычислений.
все тоже самое написано выше
А ещё. Приложение sea.com оно же под cp/m? Хотел запустить cp/m в унреале, и посмотреть на цвета профи, но пока не разобрался как.
1. В эмуляторах цвета врут. Все известные палитры Профи, основаны на схеме RRRGGGBB, где ярки белый 11111111. А на реальном Профи это не так, яркий белый это 10110110. То есть все цвета "за" как бы находятся в "следующим спектре". В этом и есть геморрой. Я не понимаю как математически рассчитать значения цветов за "ярким белым". Есть мнение, что цвета до 10110110 "растут" с одним шагом, а после "идут вниз" с другим. Или что-то ещё похожее на это.
Единственное, что приходит в голову, это взять реал, подключить его через захват видео, наделать 256 скриншотов и в фотошопе получить значения цветов. Но пока нет ни реала (всё ещё в ремонте, за то потом будет аж два :), ни аппарата по видео захвату. А в унрелае вообще обрезали цвета на числе 192. Так что посмотреть палитру не удастся.
2. Да sea.com под CP/M. В 27 номере журнала ЗаРулём есть моя статья с обзором файловых менеджеров. К ней есть приложения с образами, в них есть текущая версия программы. Нужно только Унерал или ZXMak2 настроить на режим Профи.
Архив можно выложить что не жалко, я на первую страницу добавлю.
Планировал сделать галерею в группе ВК и собрать тематические образы. Но так как есть непонятки с палитрой тормазнулся. Материал разобран по рабочим папкам, где лежат исходные картинки и версии результатов обработки с разными настройками. Не думаю, что такое нужно выпускать "в свет".
1. Определить базовые цвета.
2. Сделать таблицу в 256 где перечислить все возможные комбинации базовых цветов.
3. При выводе просто брать байт из этой таблицы, без каких либо вычислений.
Теперь понятно.
Что-то не пойму как запустить MCX viewer 0.4 (http://alonecoder.nedopc.com/zx/MCX04.zip) чтобы он мне показал картинки GRF. Пробовал в эмулях Unreal, Emuzwin. Выбирал разные версии АТМ и Эва. Другие картинки кажет, а с расширением "g" не хочет.
NEO SPECTRUMAN
14.10.2020, 11:39
Emuzwin
эмузвин не может вообще
можно и не пытатсо
в унирале выбрать memory logic atm turbo 2
и custom romset bios 1.07.13 for atm2
ну и для АТМ-ов юзать нужно унриал от deathsoft-а
https://jpegshare.net/images/ae/da/aeda969bfe3898a34f4e9a60368f20b3.png
NEO SPECTRUMAN, вот спасибо, хорошо.
Пришло время картинок АТМ. Пробовал несколько вариантов преобразования цветов, но пока лучший самый простой. Его и оставил. В других вариантах бывает больше деталей, но искажаются цвета... Лучше, конечно, когда картинка изначально 8-16 цветов.
Добавил в пак картинок АТМ и в конце несколько 8-цветных родных, для контрасту.
2020.10.13 v1.2
Добавлен формат:
GRF (BLK) ATM 64c (конвертируется в 8 цветов).
ZX 6144,6912,6913 (выводится на экран GMX)
Font 2048 (тоже на экран GMX)
Немного ускорен вывод картинок с палитрой за счёт построения таблицы 256 байт.
Вернулась функция слайд-шоу (упрощеная).
Цвета АТМ имеют диапазон 0-3. При обработке то, что >=2 приранивается к значению цвета 192 (из 255).
Картинки для опытов взяты с сайта nedopc.com.
73704
izzx, возможно, тебе будет это интересно - я добавил в DaDither (https://zx-pk.ru/threads/32400-dadither-eshche-odna-programka-dlya-dither-ga-kartinok.html) конвертацию в твой формат.
https://jpegshare.net/images/f4/17/f417db78d34a62bae7d228810553a838.png
Отлично. Попробовал пару картинок с настройками по умолчанию перегнать, открываются во вьювере хорошо. Получилось заметно симпатичнее, чем через мой конвертер.
Ещё пока не понял есть ли опция сделать пустые рамки изображения чёрными, а не белыми. Ну и прочие опции посмотрю.
Upd. Мощная вещь. Теперь можно быстро настрогать картинок без применения фотошопов.
Ещё пока не понял есть ли опция сделать пустые рамки изображения чёрными, а не белыми
Такого пока нет. Добавлю. Еще хотел спросить о pixel aspect ratio на GMX - оно составляет 1:2 или есть более точные данные? Просто у тебя в документации есть такая строка: "Так как на GMX пиксели не квадратные, при просмотре получится то, что надо, но слегка уже по вертикали на 7-8%." Эти 7-8% откуда?
Еще хотел спросить о pixel aspect ratio на GMX - оно составляет 1:2 или есть более точные данные?
Вообще я думаю должно быть ровно 1:2. Я когда проверял нарисовал на картинке круг или квадрат и мерял линейкой на ЭЛТ телевизоре. Получилось чуть не ровно. А если на эмуляторе запустить, то по-моему чётко высота = ширине на итоговой картинке.
А если на эмуляторе запустить, то по-моему чётко высота = ширине на итоговой картинке.
Ориентироваться на эмулятор на мой взгляд не самая правильная идея. Если у тебя есть возможность, то предлагаю провести эксперимент.
1) Вывести на монитор с твоего GMX обычную картинку 256x192 и произвести замеры рабочей области на физическом мониторе.
2) Вывести на монитор с твоего GMX картинку 640x200 и произвести замеры рабочей области на физическом мониторе.
3) На основании замеров рассчитать правильные размеры пикселя.
NEO SPECTRUMAN
06.12.2020, 17:47
3) На основании замеров рассчитать правильные размеры пикселя.
это лучше просить сфоткать и мерять самому
это так замеряют натянутое на 16:9 без сохранения пропорций :)
По-моему у разных телевизоров "пиксели" разные.
Вот измерил квадрат, который на TFT дисплее в эмуляторе ровный до миллиметра.
А на ЭЛТ телевизоре такой: ширина 127 мм, высота 117 мм.
Весь экран ZX 220*151.
Расширенный экран 275(край обрезан)*158мм.
На современном TFT телевизоре нарисовал круг. Он получился 178*170мм.
Весь экран ZX 383*205.
Расширенный экран 477*214мм.
Оба телевизора в режиме 4:3.
По-моему у разных телевизоров "пиксели" разные.
А нам это и не важно. Для того, что бы определить размер пикселя твоего монитора я и попросил размеры стандартного экрана, для которого нам известны пропорции 4:3.
383/(k*205) = 256/192
k*205 = 383*192/256
k = 383*192/256/205
k = 1,4012
477/(k*214) = 640/400
(k*214) = 477*400/640
k = 477*400/640/214
k = 1,3931
Коэффициенты почти равны, разницу спишем на погрешности измерения, и можно смело считать, что в GMX соотношение между шириной и высотой пикселя действительно 1:2.
Коэффициенты почти равны, разницу спишем на погрешности измерения, и можно смело считать, что в GMX соотношение между шириной и высотой пикселя действительно 1:2.
Хороший метод, теперь теория подтвердилась.
Да, вопрос со "снегом" на расширенном экране решён. Я тут ещё видео выкладывал. Так вот, Evgeny Muchkin раскопал (но пока молчит, наверно выясняет подробности), что если при старте компьютера по кнопке Delete выбрать конфигурацию "1", то "снега" не будет. Нужно сделать один раз, и если не выбирать конфигурацию "2", то не появится даже после включения - выключения.
На моём экземпляре всегда была эта фишка. Теперь никаких помех.
Upd. На самом деле наоборот, кнопки 1 и 2 перепутал.
есть ли опция сделать пустые рамки изображения чёрными, а не белыми
Добавил.
Добавил.
Теперь совсем красиво, спасибо.
Evgeny Muchkin
11.12.2020, 15:02
По поводу снега на расширенном экране. На моих GMX снега после включения питания нет.
Снег появляется после входа в загрузчик и выборе конфигурации '1'
Чистая картинка без всяких помех будет если выбирать конфиг '2' (или 7, что одно и то же).
Снег появляется после входа в загрузчик и выборе конфигурации '1'
Чистая картинка без всяких помех будет если выбирать конфиг '2' (или 7, что одно и то же).
Точно, перепутал я. 1- со снегом, 2 - без.
В GMXCom ещё и через весь экран горизонтальные полосы пролетали. Сейчас чисто, и сразу после включения тоже.
Думаю добавить новый формат картинок для GMX, как для Amstrad CPC mode 0, 160*200*4. То есть копия области атрибутов, как бы 160*200 виртуальных точек, широкие пиксели, цвета стандартные ZX. Предполагается, что область пикселей заполнена числом #0f. Размер файла сделать 16128 байт, заголовок 128 байт, первые символы в заголовке GMX0F, пятый - версия (пока 0), остальные нули.
Вот тут то же написал: https://zx-pk.ru/threads/32400-dadither-eshche-odna-programka-dlya-dither-ga-kartinok.html?p=1128229&viewfull=1#post1128229
Качество будет похуже, конечно, но зато размер файла в два раза меньше.
Есть возражения, предложения?
2021.09.24 v1.2.1
Добавлены форматы:
- GMX #0f - (16128 байт, заголовок 128 байт, в начале заголовка буквы GMX и число #0f, затем копия атрибутов. Предполагается, что страница
пикселей заполнена числом #0f)
- IFL - Multicolor (8*2) (9216 байт, сначала пиксели в формате ZX, потом атрибуты, каждую строку атрибутов нужно удвоить)
- MLT - Multicolor (8*1) (12288 байт, пиксели в формате ZX, затем атрибуты линейно)
- MC - Multicolor (8*1) (12288 байт, пиксели линейно, затем атрибуты линейно)
- MCX - Multicolor (8*1) (24576 байт, точно как .MC, но два экрана один за другим)
Исходные тексты перенесены под sjasm, и почти ни разу не оптимизированы )
Добавлена поддержка 3х буквенных расширений.
Улучшена работа с клавиатурой.
Добавлена подробная информация о файле.
Картинки для примера взяты из разных источников, часть сконвертирована в DaDither.
Для картинок с переключениями экранов (.mcx) в эмуляторе поставить галку Noflic на закладке Video,
иначе будет мерцать. На реальном железе мерцает, но равномерно.
Самые свежие версии тут (https://cloud.mail.ru/public/Nwek/SmSAFUh54)
Или здесь (https://drive.google.com/drive/folders/19-O-MY2XkgRUmUUZ98xZ83juCuaBe32I?usp=sharing)
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot