Идеология BMP - описываем один пиксель, от 1 до 4 байт. Может и есть что-то внутри, но это уже костыль. И не факт что при использовании этого костыля, сохраниться обратная совместимость.Сообщение от Dec
На самом деле на спектруме два формата с которым я имел дело в 99.9%? это grf и файлы в формате стандартного экрана (в CP/M - *.ctr). Был ещё pcx, как первый источник для формирования grf.
Как уже писал выше, общая особенность grf и ctr, изначально байтная ориентированность на хранение данных. Но если ctr это просто сохранный кусок памяти и данные в нём железо-зависимые, то в grf данные уже расположены во внутренней системе, что позволят выводить их на любом железе.
Использование форматов с иных машин (с того же IBM PC), так же упирается в то что в своей основе они организованы с оглядкой на пиксельное хранение данных. Так же не стоит забывать про то что у нас железные ограничения значительно выше чем на других машинах, как по объёму памяти и работе с ней, так и по скорости проца. А значит прямой перенос готовых решений как правило невозможен. Тот же bmp при прочих равных, будет грузиться у нас в 2-4 раза дольше. Вернёмся к этому вопросу когда у нас появится видеокарта.
Я планирую использовать следующие форматы:
grf - для хранения одиночных картинок. Но возможны множественные палитры.
scr - данные в формате физических экранов. Так же планируется заголовок по которому можно будет определить для какой машины этот файл. Для Профи 32кб.
xx1 - формат похожий на gif, но способный хранить несколько картинок. Возможно тут можно использовать grf с хитрым заголовком.
xx2 - формат открытки. Интерактивный формат. Отличие от xx1 в том что тут уже может быть музыкальное оформление и минимальное взаимодействие с пользователем (например, ожидание нажатия любой клавиши). Возможно это стоит объединить с xx1 или даже grf.
Пока окончательных решений у меня нет. Думаю оно появится на базе практики. Но желательно, что бы у всех форматов начало заголовков должно быть одинаковым. Так как grf был первым, придется взять его за основу, но поля можно будет пропускать (хотя их наличие будет обязательным).
Предлагаю подумать о дополнительных опциях и полях заголовком, что бы они были во всех форматах. Для начала давайте просто составим список таких полей, потом будем думать как их реализовать.
Предлагаю следующие:
уточнение формата - 3 байта - содержит расширение, во избежании.
целевое железо - 3 байта - для какой машины создавался файл, будет иметь значение для железо-зависимых данных, для остальных информационное.
дата создания - 8 байт - формат ддммгггг.
время создания - 6 байт - формат ссммчч.
дата редактирования - 8 байт - формат ддммгггг.
время редактирования- 6 байт - формат ссммчч.
автор - 16 байт - текст
примечание - 32-64 байт - текст, комментарии и т.п.
Или так, единое поле автор.примечание - 32-64 - разделитель "0". Снимает ограничение на длину поля "автор", правда за счёт длины поля "примечание". Минус 1 байт на разделитель.
Даты можно хранить в 3 байтах и сохранять сколько прошло дней с Рождества Христова, на сегодня это 737763 дней. Или выбрать иную дату, поближе, тогда можно уложиться в 2 байта, их хватит примерно на период в 179 лет.
Время так же можно хранить в 3 байтах и сохранять число секунд прошедших с полуночи, максимальное значение 86400.
Эти форматы удобны тем, что для переход между дата/временем, нужно просто прибавить или вычесть нужное значение. Нет проблемы высокостных годов, месяцев 30 или 31 день (про февраль, вообще молчим), переходом между часами/минутами и прочее.
Ответить с цитированием