Вид для печати
Я посмотрел, пока возражений нету. Дело это сложное и ответственное. Думаю дату лучше в формате 8 байт, так проще и высчитывать ничего не надо потом.Цитата:
Сообщение от tae1980
Расширение в заголовке тоже полезное дело.
Код машины - вот тут скользкая тема. Так можно наплодить вариантов. Модификаций машин же много бывает. Может достаточно версии самого формата картинки.
Я сейчас глянул на текущие методы сжатия в bmp и обнаружил, что помимо BI_JPEG и BI_PNG, о которых я знал, добавились BI_CMYK, BI_CMYKRLE8, BI_CMYKRLE4. Откроет ли такие файлы условный Фотошоп? Сомневаюсь. Обратная совместимость - это когда старые форматы открываются в новом ПО, а не когда новые форматы открываются в старом ПО.Цитата:
Сообщение от tae1980
На самом деле я ни чего не предлагаю. Я лишь критикую текущие решения.Цитата:
Сообщение от tae1980
Т.е. создание некого универсального формата, основанного на grf? Старое ПО сможет с ним работать?Цитата:
Сообщение от tae1980
Данный пункт относиться к формату SCR, который представляет собой просто кусок экранной памяти. Предположительно будут такие форматы:Цитата:
Сообщение от izzx
* стандартный экран ZX.
* расширенный экран Профи.
* экран GMX.
Ну и другие машины со своими экранами. Можно кончено для каждого случая использовать своё расширение (как вариант: szx, spr, sgm) и вообще отказаться от заголовка. Но смысловая нагрузка тут одинаковая, а мой опыт показывает, что такую информацию лучше объединять.
- - - Добавлено - - -
Старое ПО будет работать с соответствующими версиями файлов, а новый версии могут быть открыты с частичной потерей информации. Например: без проблем будут открываться много палитровые файлы, но только с первой палитрой или в много страничных файлах, будет открыта только первая страница и т.п.Цитата:
Сообщение от Dec
Подобные проблемы есть и под виндой, например далеко не все вьюверы знаю,что tiff может быть много страничным и содержать геоинформацию.
Нужно это или нет? Я думаю, что нужно, особенно на начальном этапе. Да и внедрять новое проще (и правельнее) постепенно, чем переписывать "всё и сразу".
Простой пример. Есть на Профи редактор музыки SM, у него есть возможность загрузить картинку на рабочий стол, но во внутреннем формате. Для перевода картинок во внутренний формат есть специальная утилита, которая в качестве источника использует черно-белые GRF.
А для профи разве достаточно копии экранной памяти? А палитру загрузить? Или в заголовке будет?Цитата:
Сообщение от tae1980
А для чего вообще пихать дампы памяти в какой-то контейнер? Ты так много говоришь о совместимости, но при этом заставляешь читателя файла знать о подробностях устройства каких-то конкретных машин. Все, что нужно знать читателю - как кодируется цвет в файле.Цитата:
Сообщение от tae1980
Вот только твой эволюционный путь от текущего grf формата к некому идеальному формату приведет к тому, что этот формат будет набором костылей. Я тебя спросил "А как мне различить, что файл создан для 8 цветной (общая яркость + мигание) или 16 цветной (яркость раздельная, мигания нет) машины?". Твой ответ - "Ни как. GRF это не предусматривает. Назначаем для "+9" новое значение и различаем по нему." Т.е. просто берем и добавляем еще один маленький костылек. И в конце развития твой формат превратиться в кучу этих костылей.Цитата:
Сообщение от tae1980
Если все равно новые возможности формата не будут доступны на старом ПО, то для чего так упорно держаться исходного формата. Создай нормальный продуманный формат.
Замечание. Вычислять что нибуть нужно будет при любой форме хранения. Например, для сравнения двух дат, в случае с 3 байтным хранением, идёт простое сравнение двух чисел, в случае с 8 байтным довольно сложная процедура. То же самое с вычисление разницы между датами и т.п. Единственный плюс 8 битного хранения быстрая подготовка к выводу.Цитата:
Сообщение от izzx
- - - Добавлено - - -
Да, точно, совсем забыл про палитру. То есть заголовок нужен.Цитата:
Сообщение от izzx
к которому по моему тоже пришлепывают палитрыЦитата:
Сообщение от tae1980
только уже сзади а не в заголовках
и детектитсо все по длине размерамЦитата:
A 6912 byte .SCR file contains a standard Spectrum screen.
A 6976 byte .SCR file contains a standard Spectrum screen followed by 64 colour registers.
A 12288 byte .SCR file contains a Timex hi-colour screen.
A 12352 byte .SCR file contains a Timex hi-colour screen followed by 64 colour registers.
A 12289 byte .SCR file contains a Timex hi-res screen.
A 12353 byte .SCR file contains a Timex hi-res screen followed by the hi-res colour information that was dumped from port 255, followed by 64 colour registers.
- - - Добавлено - - -
так что может можно хранить *****е экраны от профей и гмх-ов в обычном scr и не морочить голову
(ну кроме тех неотличимых вариантов с 8\16 цветами)
Как напомнили мне выше, как минимум для того что бы разместить в нем палитру. Ну и за одно кучу информации о которой я писал выше. Так и хочется спросить, ты чужие сообщения вообще читаешь?Цитата:
Сообщение от Dec
Не "читателя", а "программиста". И много я говоря не просто про эфемерную "совместимость", а про совместимость "среды ZX" в целом. При чём прозрачно для пользователя.Цитата:
Сообщение от Dec
Примером этого служит возможность просмотра картинок подготовленных для Профи на GMX и на оборот. Или возможность просмотра картинок под стандартный экран на расширенном экране Профи. Не понимаю почему это плохо. Для формата SCR на "не родных" машинах/режимах, нужно всего лишь написать разбор перед выводом. Чем это отличается от вывода BMP формата?
Ты бредишь! "+9" это признак не стандартного формата, то есть расширения. Это же в инструкции написано "черным по белому". Ты понял, что заголовок у GRF может быть любой длины, а не только 128 байт? У тебя не возникло вопроса "а за чем это понадобилось?", при столь "лаконичном" заголовке?Цитата:
Сообщение от Dec
Что за двойные стандарты? Ты в курсе, что BMP может содержать упакованные данные? Но ни где это не использоваться. Наличие такой возможности - это костыль?
И создать из BMP уродца, которого не сможет прочитать ни одна из существующая программ, ни на одной плат форме - это не "использовать костыли"?
Подобный образ мысли преобладает у группы "НЕДО"что угодно. Из-за чего итоговый результат их работ "немножко с душком".
- - - Добавлено - - -
Заголовок - это больше чем просто наличие палитры. Различать файлы исключительно через их размер - каменный век.Цитата:
Сообщение от NEO SPECTRUMAN
Не нравиться - не пользуйся. Только вот ты в теме про программу для формования подобных экранов.Цитата:
Сообщение от NEO SPECTRUMAN
Я думаю для начала можно добавить метку стандартных цветов ZX. Которые с общей яркостью. Чтобы как выше писали, отличалось от 16 цветов. Такое и на гмх можно будет просто открыть и на стандартном экране.
upd. Но правда не решён вопрос с разными пропорциями пикселей.
NEO SPECTRUMAN описал ULAPlus файлы. Какую палитру ты хочешь добавлять к стандартным SCR файлам?Цитата:
Сообщение от tae1980
Под читателем я подразумевал программиста, который будет писать код для поддержки твоего формата для своей платформы.Цитата:
Сообщение от tae1980
А я где-то говорил, что это плохо? Просто ты хочешь заставить программиста знать специфику хранения данных на всех платформах, вместо того, что бы просто описать единый конкретный алгоритм декодирования цвета в файле.Цитата:
Сообщение от tae1980
Тем, что для bmp не нужно знать аппаратных особенностей той платформы, на которой он был создан.Цитата:
Сообщение от tae1980
Ок, позиция ясна.Цитата:
Сообщение от tae1980
То, что ты или условный фотошоп не используют сжатие в bmp не обозначает, что эта возможность нигде не используется.Цитата:
Сообщение от tae1980
Что так привязался к bmp? Я ведь тебе пишу "cоздай нормальный продуманный формат", а не "непременно используй bmp". "Так и хочется спросить, ты чужие сообщения вообще читаешь?"Цитата:
Сообщение от tae1980
Твой новый формат (точнее планируемое тобой расширение) точно также не сможет прочитать ни одна из существующая программ.
А каков на данный момент алгоритм, позволяющий отличить grf файл от случайного набора байт?Цитата:
Сообщение от tae1980
Можно просто добавитьЦитата:
Сообщение от izzx
еще один костыльдополнительный флаг в файл.