GMX Pic View

[NEO SPECTRUMAN]

нужно провести для каждых 8 точек

зачем на каждые 8 точек?

сама адаптация будет быстрой
через жменю табличек
и обрабатываться будет только байт атрибутов

а байт пикселей дублируется на оба экрана как есть


а вот чтоб сделать правильную сортировку для шахматного интерлейса
ТТТТТТТТССССССССТТТТТТТТС ССССССС
ССССССССТТТТТТТТССССССССТ ТТТТТТТ
ТТТТТТТТССССССССТТТТТТТТС ССССССС
ССССССССТТТТТТТТССССССССТ ТТТТТТТ
где
Т - более "темные" 2 байта
С - более "светлые" 2 байа
уйдет достаточно много времени

если прикинуть на глаз думаю будет дето 1...2 секунды в лучшем случае

- - - Добавлено - - -

конечно можно сделать простой черезстрочник
без проверки яркости 8х1 знакоместа
это будет на порядок быстрее
и вполне будет работать

- - - Добавлено - - -

зачем на каждые 8 точек?

другими словами я говорю просто про имитацию палитры средствами гигаскрина
а не про конвертацию картинки

- - - Добавлено - - -

я могу нафотошопить как оно будет выглядеть
чтоб было видно стоит оно того или нет
только мне нужна АТМ-ная 640х200 картинка с пол литрой

вангую что для многих цветов не будет полноценной альтернативы
и что некоторые детали будут съедатсо

[NEO SPECTRUMAN]

вот 640x200 ATM c поллитра
и 640х200 GMX без поллитра рядом

без какой либо сортировки
просто шахматка 8х2
хотя примитивную сортировку можно сделать на уровне самих стаблиц

смотреть со скоростью развертки монитора


ATM

GMX gigascreen


ATM

GMX gigascreen


ATM

GMX gigascreen


- - - Добавлено - - -

ну и конечно альтернативы для всех цветов нет


АТМ


GMX gigascreen


и некоторые цвета лучше подставить в таблицу ручками
тк автоматический результат местами не торт...

ну и есное дело таблицы нужно делать под 2 варианта спековской палитры
alone и pulsar
и переключать их с менюшки

[Dec]

Набор GRF-картинок формата АТМ для экспериментов с вьювером можно взять, например, здесь

Подскажи, а является ли файл 250gto.grf из архива корректным? По моим экспериментам у него не хватает байтов в области атрибутов. А у многих файлов наоборот - есть лишние байты в области атрибутов.

[izzx]

Можно задать для картинок 8 цветов, отдельный стандарт. +9 в заголовке. Например, значение 1. Что ускорит вывод таких картинок, при условии подготовки разных процедур чтения/вывода.

Если в вашем чудо-конвертере будет поддержан такой формат, я могу прикрутить к своему вьюверу.

Второе. Для конвертации цветов действительно может нужна таблица один раз набитая скажем для профи 256*3 размером. И тогда легче пересчитывать цвета в 16. Я ещё не думал как конкретно преобразовывать, может и лишнее.

Третье. Надо ли делать поддержку прокрутки не влезающих по высоте картинок? По ширине так точно думаю показывать максимум 640 точек. Я ещё только прикручиваю ч.б. картинки от профи, а они длинные по высоте.

[NEO SPECTRUMAN]

Третье. Надо ли делать поддержку прокрутки не влезающих по высоте картинок? По ширине так точно думаю показывать максимум 640 точек. Я ещё только прикручиваю ч.б. картинки от профи, а они длинные по высоте.

просматривал виевереы на втрд
и вощем это прикольная функция
вот только бы как то еще информировать что там за пределеами еще что то есть
а то это не вчевидно
может не бегунки а хотя бы стрелки(которые потом исчезают) показывающие что есть продолжение
или хз

[Максагор]

Подскажи, а является ли файл 250gto.grf из архива корректным? По моим экспериментам у него не хватает байтов в области атрибутов. А у многих файлов наоборот - есть лишние байты в области атрибутов

250gto действительно поврежден, причем поврежден еще на дискетах от МикроАРТа. А лишние байты могут быть - редактор GRAF избыточно сохраняет почему-то.

[Advertiser]

[tae1980]

Если в вашем чудо-конвертере будет поддержан такой формат, я могу прикрутить к своему вьюверу.
Второе. Для конвертации цветов действительно может нужна таблица один раз набитая скажем для профи 256*3 размером. И тогда легче пересчитывать цвета в 16. Я ещё не думал как конкретно преобразовывать, может и лишнее.

Функция будет. Но тут оказалось всё сложнее, чем на первый взгляд. Для нормального отображения картинки на реальном железе, стандартные цвета ЗХ в палитры должна идти строго в определенном порядке. Но нет ни каких гарантий, что они в таком порядке идут в исходной BMP. То есть нужно: 1) проверить в цвета в палитре на соответствие стандартным цветам ЗХ. 2) отсортировать их в нужно порядке. 3) внести изменение в загруженный (или уже сконверченный) файл. Так же нужны подпрограммы: удаление цвета из палитры, сортировка палитры (несколько вариантов), приведение цветов в палитре к стандартным цветам ЗХ. А так же подготовить несколько алгоритмов конверсии, скорее всего их будет 2-4. Есть изменении в процедурах формирования GRF, работа с цветом будет разная. Ну и возможно что-то упустил.
Короче, возни оказалось в разы больше чем планировалось изначально, так что всё затягивается.

Третье. Надо ли делать поддержку прокрутки не влезающих по высоте картинок? По ширине так точно думаю показывать максимум 640 точек. Я ещё только прикручиваю ч.б. картинки от профи, а они длинные по высоте.

В моём въювере под CP/M есть верительная прокрутка. Горизонтальная так же планируется, но так как мне она особо не нужна, а других пользователь программы я не знаю, её реализация постоянно откладывается.
Из-за того, что на хранения размеров у меня выделено только 1 байт, размер просматриваемой картинки ограничен 2048х2048. Что на мой взгляд покрывает все возможные потребности.

[Максагор]

Насколько я понял из анализа имеющейся информации, формат 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]

Само собой, таковой формат не будет оптимальным на других машинах с расширенной графикой, где структура расширения несколько иная. Поэтому я совмневаюсь в том, что возможен некий ежиный ОПТИМАЛЬНЫЙ формат. Единый - да, оптимальный - сомневаюсь.

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

[Максагор]

Третье. Надо ли делать поддержку прокрутки не влезающих по высоте картинок? По ширине так точно думаю показывать максимум 640 точек. Я ещё только прикручиваю ч.б. картинки от профи, а они длинные по высоте.

Конечно делать!