sXg: Spectrum eXtended Graphics
Давным-давно, кажется в прошлую пятницу,… нет, не медвежонок. Мы общались с moroz1999 на предмет в каком формате хранить графику для расширенных режимов ZX Spectrum. На сегодняшний день у нас есть несколько ZX Spectrum-совместимых компьютеров, которые могут отображать 16 или более цветов, без клешенга атрибутов, это ATM (Turbo), Profi, Scorpion+GMX, Sprinter, Pentagon SL 2.2 и конечно же любимец публики PentEvo, он же ZX Evolution от команды NedoPC.
Вот о последнем мне бы и хотелось поговорить подробнее.
В оригинальной (BaseConf) прошивке от NedoPC, так же как и у ATM на экране может быть отображено только 16 цветов из 64 жестко заданных в палитре.
Понятно, что в былые годы, когда создался АТМ, никто из разработчиков не советовался с художниками, как мол лучше реализовать расширенный графический режим. Да и была ли такая возможность, повлиять на архитектуру, мы уже не узнаем. В прочем да не суть. Как художнику такое ограничение было не по душе, это как «видит око да зуб неймёт». Мало того в цветовой палитре АТМ достаточно не просто рисовать, так и ещё ограничение видимой области всего-лишь 320x200 точек.
К счастью в своё время появился такой человек как tsl , и несколько «раздвинул» границы возможностей PentEvo. Добавив нормальную, линейную структуру видеопамяти, расширив отображаемую область до 360x288 точек и самое главное сделав возможным отображение одновременно 64 цветов на экране.
Но и на этом работа не была закончена. Последняя прошивка (TS-Conf) на обычном ZX Evolution (без доработок железа и не смотря на ограничения в 6 bit) позволяет одновременно отображать до 15625 оттенков (по 25 градаций на каждый из основных цветов) за счёт видео-ШИМ.
С помощью ШИМ достигается большее количество оттенков путем создания мелкой текстуры из соседних градаций. (Размер суб-пикселя текстуры равен 1/8 размера спектрумского пикселя.) Это неплохо отображается на CRT-дисплеях (трубках), но на LCD, из-за оцифровки видеосигнала, происходит интерференция между суб-пикселями текстуры и частотой видео-АЦП; суб-пиксели превращаются в жирные линии.
Поэтому прошлым летом (2014) TSL была выпущена отдельная плата VideoDAC, которая вставляется вместо IDE (да пришлось чем-то пожертвовать).
Данная плата позволяет отображать 15625 цветов на любом мониторе без искажений, а также использовать полный диапазон палитрового ОЗУ 5 бит на компоненту — 32768 цветов.
Вот! Вот онарыба графика моей мечты. Но я немного отвлёкся вернёмся к нашим другим ZX Spectrum — совместимым компьютерам.
По причине скудной информации, да и вообще малой активности в данных направлениях (расширенная графика), отсутствия софта использующего данные режимы, Трудно сделать обзор остальных ZX Spectrum-cовместимых компьютеров. Исключение составляет, разве что Sprinter (ну он изначально был PeeCee-ориентирован) поэтому там графика VGA и Pentagon SL 2.2 с расширенным графическим режимом 256x192, где каждая точка может быть своим цветом. Разработке 16с и активному продвижению данного режима, мы обязаны не без известному Alone Coder'у. Хотя надо отдать должное, в своё время DDp доработал Pentagon SL 2.2 и сделал возможным задавать палитру. Жаль что это так и не пошло в массы.
Про Scorpion'овский GMX вообще сложно что-либо сказать вразумительное, ну а по поводу графических режимов Profi тоже оставляет желать лучшего. Да и собственно графических работ для этих платформ я так и не нашел.
Но вернёмся к собственно к теме разговора — «sXg: Spectrum eXtended Graphics». Итак получается, что потенциальными «клиентами» кому мог бы понадобится новый формат, или если хотите стандарт, это ATM и PentEvo. Поскольку в ATM очень хитро устроена структура видеопамяти, да и в добавок он имеет ограничение по цветам. Я решил смотреть в сторону TS-Conf и линейной адресации памяти.
В результате чего получилась такая структура файла:
Как видите ничего сверх естественного нет, но пытливый ум уже точит сомнения, для чего было «изобретать велосипед», когда есть замечательный формат BMP. Ну начнём с того, что это чудо-формат был изобретён дядей Биллом(?) ещё чёрти когда для PeeCee. У это формата есть ряд странностей, таких как, выравнивание отступов кратных четырём (например если у вас картинка шириной 26px, то внутри bmp каждая строка будет дополнена нулями до 32px), так же изображение хранится по умолчанию вверх ногами (конечно можно задать флаг и перевернуть изображение, но это опять же излишние телодвижения), ну и самое главное это формат в котом хранится палитра. Которая так же может быть дополнена нулевыми значениями (по усмотрению создающей программы). Вот и выходит, что для того что бы отобразить BMP на ZX Spectrum машинного времени потребуется гораздо больше, а мы, если вы ещё не забыли, на Z80.
Ну и в дополнение, ещё скажу, что по сути sXg это формат дампа видеопамяти, данные не требуют дополнительной обработки, то существенно сокращает их чтение с диска с последующим размещением в видеопамяти.
И ещё небольшой бонус. Поскольку изображение могут быть гораздо меньшего размера (не на весь экран) логично было бы задать цвет фона (перед очисткой). Для этого служит 5й байт, в котором хранится предпочтительный цвет фона изображения. Конечно программ отображающая картинку может смело игнорировать это и вместо этого сделать чёрный фон, например.
Итак формат готов, осталось как-то получить данные в этом формате. Для этого была написана небольшая консольная утилита для PeeCee — bmp2sxg:
Утилита проста в использовании. На вход задаётся имя файла в формате BMP(да да, никуда нам от него не деться) и на выходе получаем файл в формате SXG. Поддерживаются любые картинки в формате не больше 8бит (256ц) и размером не более 512x512.
При желании картинку можно ограничить палитрой ATM (64 цвета без шим) задав соответствующий ключ --64. По умолчанию цвет фона выставляется, как 0й цвет из палитры (это может быть не обязательно чёрный цвет), но можно задать его принудительно с помощью ключа --bg nn, где nn — соответственно номер из палитры файла.
Понятно, что все мы не идеальны и вполне возможно могут случаться ошибки преобразования. Для этих целей служит ключ --debug. Если задан этот ключ, то в консоль или в файл будет выгружена отладочная информация как и что было преобразовано:
Как видно из скриншота, некоторые программы на PeeCee могут так же «растягивать» палитру дополняя её не используемыми цветами, тем самым увеличивая его размер.
Не смотря на то, у sxg уже вторая версия header'а, это скорее пока прототип, нежели законченная версия, поэтому с радостью выслушаю пожелания предложения по улучшению данного формата.
Ну и осталось самое сладкое. Всё это хорошо и замечательно, но как нам всё это увидеть на реальном железе?
Как вы уже возможно знаете, одним из моих проектов является Command Line Interface (сокращенно CLI), поэтому именно под эту систему и была написана небольшая утилита loadsxg.
Данная утилита позволяет загружать в видеопамять файл в формате sxg, «центровать» (если изображение меньше), выставлять цвет фона, а так же можно включить режим вьёвера и скроллировать картинку если она больше чем 360x288 и не помещается на экран.
В качестве бонуса я приготовил вам артпак из 36 картинок в формате sxg:
Для просмотра на реальном железе вам понадобится распаковать архив в корень SD-карты. Прописать в wc.ini строчку в разделе [PLUGINS]:
или же можете просто переписать поверху файлы. Далее запускаем WildCommander (не ниже версии 0.62) и нажав F10 выбираем пункт CLI2:
Если вы сделали всё правильно, то после запуска вас встретит приглашение «1>».
Далее набираем строчку:
После enter запустится скрипт, который и проиграет слайдшоу «Bramble». А если у вас есть карта NeoGS (или просто General Sound), то вы ещё и отличную мелодию послушаете.
Ну и на всякий случай я записал ещё видео с слайдшоу:
Ну и в заключении ссылка на сам архив «Cli2+Bramble.zip».
И утилиту для PeeCee «bmp2sxg.zip». Внутри архива вы найдёте саму утилиту, а так же бонусом bat-file create. При запуске он сканирует директорию на наличие bmp файлов и автоматически преобразует их все в sxg-формат.
На этом всё. Творите больше хорошего и разного. А я в свою очередь постараюсь и дальше развивать как данный формат, так и постараюсь обеспечить его поддержку на других ZX Spectum-совместимых компьютерах.
UPD: Сделал сборку настроенного Unreal с образом диска. Достаточно нажать F10 в Wild Commander и далее по тексту. Ссылка на архив «unreal.dev.zip»
Вот о последнем мне бы и хотелось поговорить подробнее.
В оригинальной (BaseConf) прошивке от NedoPC, так же как и у ATM на экране может быть отображено только 16 цветов из 64 жестко заданных в палитре.
Понятно, что в былые годы, когда создался АТМ, никто из разработчиков не советовался с художниками, как мол лучше реализовать расширенный графический режим. Да и была ли такая возможность, повлиять на архитектуру, мы уже не узнаем. В прочем да не суть. Как художнику такое ограничение было не по душе, это как «видит око да зуб неймёт». Мало того в цветовой палитре АТМ достаточно не просто рисовать, так и ещё ограничение видимой области всего-лишь 320x200 точек.
К счастью в своё время появился такой человек как tsl , и несколько «раздвинул» границы возможностей PentEvo. Добавив нормальную, линейную структуру видеопамяти, расширив отображаемую область до 360x288 точек и самое главное сделав возможным отображение одновременно 64 цветов на экране.
Но и на этом работа не была закончена. Последняя прошивка (TS-Conf) на обычном ZX Evolution (без доработок железа и не смотря на ограничения в 6 bit) позволяет одновременно отображать до 15625 оттенков (по 25 градаций на каждый из основных цветов) за счёт видео-ШИМ.
С помощью ШИМ достигается большее количество оттенков путем создания мелкой текстуры из соседних градаций. (Размер суб-пикселя текстуры равен 1/8 размера спектрумского пикселя.) Это неплохо отображается на CRT-дисплеях (трубках), но на LCD, из-за оцифровки видеосигнала, происходит интерференция между суб-пикселями текстуры и частотой видео-АЦП; суб-пиксели превращаются в жирные линии.
Поэтому прошлым летом (2014) TSL была выпущена отдельная плата VideoDAC, которая вставляется вместо IDE (да пришлось чем-то пожертвовать).
Данная плата позволяет отображать 15625 цветов на любом мониторе без искажений, а также использовать полный диапазон палитрового ОЗУ 5 бит на компоненту — 32768 цветов.
Вот! Вот она
По причине скудной информации, да и вообще малой активности в данных направлениях (расширенная графика), отсутствия софта использующего данные режимы, Трудно сделать обзор остальных ZX Spectrum-cовместимых компьютеров. Исключение составляет, разве что Sprinter (ну он изначально был PeeCee-ориентирован) поэтому там графика VGA и Pentagon SL 2.2 с расширенным графическим режимом 256x192, где каждая точка может быть своим цветом. Разработке 16с и активному продвижению данного режима, мы обязаны не без известному Alone Coder'у. Хотя надо отдать должное, в своё время DDp доработал Pentagon SL 2.2 и сделал возможным задавать палитру. Жаль что это так и не пошло в массы.
Про Scorpion'овский GMX вообще сложно что-либо сказать вразумительное, ну а по поводу графических режимов Profi тоже оставляет желать лучшего. Да и собственно графических работ для этих платформ я так и не нашел.
Но вернёмся к собственно к теме разговора — «sXg: Spectrum eXtended Graphics». Итак получается, что потенциальными «клиентами» кому мог бы понадобится новый формат, или если хотите стандарт, это ATM и PentEvo. Поскольку в ATM очень хитро устроена структура видеопамяти, да и в добавок он имеет ограничение по цветам. Я решил смотреть в сторону TS-Conf и линейной адресации памяти.
В результате чего получилась такая структура файла:
+#0000 #04 #7f+"SXG" - 4 байта сигнатура, что это формат файла SXG
+#0004 #01 1 байт версия формата
+#0005 #01 1 байт цвет фона (используется для очистки)
+#0006 #01 1 байт тип упаковки данных (#00 - данные не пакованы)
+#0007 #01 1 байт формат изображения (1 - 16ц, 2 - 256ц)
+#0008 #02 2 байта ширина изображения
+#000a #02 2 байта высота изображения
(далее указываются смещения, для того, что бы можно было расширить заголовок)
+#000c #02 смещение от текущего адреса до начала данных палитры
+#000e #02 смещение от текущего адреса до начала данных битмап
Собственно начало данных палитры
+#0010 #0200 512 байт палитра
и начало данных битмап
+#0210 #xxxx данные битмап
Как видите ничего сверх естественного нет, но пытливый ум уже точит сомнения, для чего было «изобретать велосипед», когда есть замечательный формат BMP. Ну начнём с того, что это чудо-формат был изобретён дядей Биллом(?) ещё чёрти когда для PeeCee. У это формата есть ряд странностей, таких как, выравнивание отступов кратных четырём (например если у вас картинка шириной 26px, то внутри bmp каждая строка будет дополнена нулями до 32px), так же изображение хранится по умолчанию вверх ногами (конечно можно задать флаг и перевернуть изображение, но это опять же излишние телодвижения), ну и самое главное это формат в котом хранится палитра. Которая так же может быть дополнена нулевыми значениями (по усмотрению создающей программы). Вот и выходит, что для того что бы отобразить BMP на ZX Spectrum машинного времени потребуется гораздо больше, а мы, если вы ещё не забыли, на Z80.
Ну и в дополнение, ещё скажу, что по сути sXg это формат дампа видеопамяти, данные не требуют дополнительной обработки, то существенно сокращает их чтение с диска с последующим размещением в видеопамяти.
И ещё небольшой бонус. Поскольку изображение могут быть гораздо меньшего размера (не на весь экран) логично было бы задать цвет фона (перед очисткой). Для этого служит 5й байт, в котором хранится предпочтительный цвет фона изображения. Конечно программ отображающая картинку может смело игнорировать это и вместо этого сделать чёрный фон, например.
Итак формат готов, осталось как-то получить данные в этом формате. Для этого была написана небольшая консольная утилита для PeeCee — bmp2sxg:
Утилита проста в использовании. На вход задаётся имя файла в формате BMP(да да, никуда нам от него не деться) и на выходе получаем файл в формате SXG. Поддерживаются любые картинки в формате не больше 8бит (256ц) и размером не более 512x512.
При желании картинку можно ограничить палитрой ATM (64 цвета без шим) задав соответствующий ключ --64. По умолчанию цвет фона выставляется, как 0й цвет из палитры (это может быть не обязательно чёрный цвет), но можно задать его принудительно с помощью ключа --bg nn, где nn — соответственно номер из палитры файла.
Понятно, что все мы не идеальны и вполне возможно могут случаться ошибки преобразования. Для этих целей служит ключ --debug. Если задан этот ключ, то в консоль или в файл будет выгружена отладочная информация как и что было преобразовано:
Как видно из скриншота, некоторые программы на PeeCee могут так же «растягивать» палитру дополняя её не используемыми цветами, тем самым увеличивая его размер.
Не смотря на то, у sxg уже вторая версия header'а, это скорее пока прототип, нежели законченная версия, поэтому с радостью выслушаю пожелания предложения по улучшению данного формата.
Ну и осталось самое сладкое. Всё это хорошо и замечательно, но как нам всё это увидеть на реальном железе?
Как вы уже возможно знаете, одним из моих проектов является Command Line Interface (сокращенно CLI), поэтому именно под эту систему и была написана небольшая утилита loadsxg.
Данная утилита позволяет загружать в видеопамять файл в формате sxg, «центровать» (если изображение меньше), выставлять цвет фона, а так же можно включить режим вьёвера и скроллировать картинку если она больше чем 360x288 и не помещается на экран.
В качестве бонуса я приготовил вам артпак из 36 картинок в формате sxg:
Для просмотра на реальном железе вам понадобится распаковать архив в корень SD-карты. Прописать в wc.ini строчку в разделе [PLUGINS]:
CLI2 .WMF
или же можете просто переписать поверху файлы. Далее запускаем WildCommander (не ниже версии 0.62) и нажав F10 выбираем пункт CLI2:
Если вы сделали всё правильно, то после запуска вас встретит приглашение «1>».
Далее набираем строчку:
sh /demo/bramble/run.sh
После enter запустится скрипт, который и проиграет слайдшоу «Bramble». А если у вас есть карта NeoGS (или просто General Sound), то вы ещё и отличную мелодию послушаете.
Ну и на всякий случай я записал ещё видео с слайдшоу:
Ну и в заключении ссылка на сам архив «Cli2+Bramble.zip».
И утилиту для PeeCee «bmp2sxg.zip». Внутри архива вы найдёте саму утилиту, а так же бонусом bat-file create. При запуске он сканирует директорию на наличие bmp файлов и автоматически преобразует их все в sxg-формат.
На этом всё. Творите больше хорошего и разного. А я в свою очередь постараюсь и дальше развивать как данный формат, так и постараюсь обеспечить его поддержку на других ZX Spectum-совместимых компьютерах.
UPD: Сделал сборку настроенного Unreal с образом диска. Достаточно нажать F10 в Wild Commander и далее по тексту. Ссылка на архив «unreal.dev.zip»
49 комментариев
+#0010 #0200 512 байт палитра
а не слишком избыточно к примеру для 16c картинок?
2) Тебе нужно настроить в конфиге запуск boot.$c с SD-карты
3) Распаковать архив с Wild Commander на карту SD (брать тут)
4) Убедиться, что Wild Commander запускается.
5) Распаковать архив «Cli2+Bramble.zip» в корень SD-карты переписав файлы поверх.
6) Запустить Wild Commader и нажать F10.
7) В выпадающем меню выбрать пункт «Command Line Interface² (Loader)»
8) Если всё сделано правильно, появится приглашение 1>
9) Набрать sh /demo/bramble/run.sh и нажать enter
10) Наслаждаемся просмотром ;)
Как видно ничего сложного нет.
В принципе я могу подготовить полную сборку Unreal + образ SD-карты.
Кстати, кому-нибудь нужен PHP конвертер zx-скринов в PNG/GIF, умеющий бордер, повороты, разные форматы, гигаскрин-мерцание, флэш? Могу выложить на гитхаб, если вдруг нужно.
а) очень распространенный
б) очень гибкий по своей структуре
Второе свойство позволяет использовать его в качестве контейнера. Можно завести свой кастомный чанк и класть туда данные в формате видеопамяти (возможно, сжатые любым спековским компрессором). Имхо, для коллекций- самое то (можно еще всякую метаинформацию пихать).
И ещё. Писал бмп-вьювер для пентевы и могу сказать, что после того, как формат бмп становится ясен из гугления, вьювер пишется на автомате, почти без напряга. Если у кого-то не так…
Не ставилась самоцель найти все недостатки, я лишь привёл пару примеров, чем мне не нравится данный формат.
Проблема не в сложности реализации, а в востребованности. Можно реализовать хоть SVG и рисовать «процессуальную графику», но! если же это опять кому-нибудь будет нужно. И он действительно захочет оторвать свою пятую точку и наконец что-то зарелизит :)
Ему присылают бмп ИЛИ ему присылают схг?
В случае бмп он просто берёт и смотрит на пц, прикидывает, что и как будет показывать. В случае схг он посмотреть их сможет с большим гемором.
Представьте себе человека, решившего из какой-нибудь онлайн-коллекции скачать картинки, чтоб позаимствовать их в дему. Он скачивает оригиналы 16ц в бмп и далее свободно делает что хочет (на пц). ИЛИ он скачивает схг и ничего уже не может сделать.
Схг — это путь в один конец, в котором картинки даже посмотреть нормально никак нельзя (ага, записать их на трд, перенести в эмуляторе на образ фат-диска? Или замонтировать сначала в пц образ фат-диска, потом в эмуляторе смотреть?).
Отлично себе представляю :) Точно такой же «гемор», как если бы ему прислали файлы $c или scr. Что это? куда это? как это посмотреть? Поэтому участники давно присылают работы в двух форматах нативном спектрумовском и на всякий случай для PeeCee.
Точно так же как если бы он решил позаимствовать шрифты, музыку или другие данные, ему придётся разбираться в каком формате они хранятся. Кто хочет разобраться найдёт способ, кто не хочет найдёт 1000 и 1 причину не делать этого (:
Не надо кидаться абстрактными фразами. Опять же возвращаясь к нативным ZX-форматам: pt3 в Windows Media Player не послушать, надо выкинуть его к чертям и писать сразу mp3! Проводник или windos-просмотрщик картинок не может отобразить файлы $c, а в случае scr вообще попробует запустить скринсейвер. Нафиг! Сразу хранить в BMP! Ведь это удобно! Туда же шрифты -> ttf и так далее и тому подобное!
Это всё замечательно и прекрасно! но есть маленькое но, для чего всё это? Это формат файла для PeeCee? Нет, это не для него. Хотите смотреть файлы на нём? Никто не мешает написать плагины для XnView, Total Commander, PhotoShop или ещё каких других программ.
Так что в корне не согласен. А нужен ли ещё один формат данных или нет, время покажет. На сегодняшний день к ZX подключили и HDD, и CD, и даже SD-карты, а народ по старинке клепает релизы в trd/scl, а то и вовсе в tap'ки сохраняет! Почему?
1. Позаботиться о поддержке в «онлайн-коллекциях» — это я сделаю.
2. Позаботиться о поддержке в эмулях как формате сохранения скриншотов — это надо договариваться с авторами эмуляторов.
3. Позаботиться о нативном софте. Тут уже кое-что есть.
4. Позаботиться о конвертере. Вроде как тоже есть.
5. Позаботиться о работах. Тоже есть — минимум часть из работ в других форматах недоступно.
Я не хочу ввязываться в спор sXg vs BMP vs PNG, мне важно, что:
1. Есть оригинальные (разработанные специально для платформы) работы в этом формате,
2. Есть нативный софт для просмотра.
3. Нет альтернативы.
Всё это достаточное основание, чтобы я подсуетился и запилил саппорт на zx-art. Все те же причины, что и у BMP были.
Конкретный пример — IVP'14, где у некоторых работ была неточная палитра, что на некоторых экземплярах приводило к отличимым на глаз цветам. То есть, бмп от этого не очень страхует, а какой-нибудь нативный формат подстраховал бы.
Лично для меня проблема только одна, не отсутствие узкоспецализированного редактора (тут ведь вообще цвет на точку, обычная пиксельная графика), а отсутствие утилит для получения запускаемого на реальном железе файла, то бишь вьювер+картинка.
Тоесть вариант, PhotoShop->Save as…->SXG + Wild Commander Plugin решат задачу?
в статье упоминается *.bmp формат, но не написано что его можно чем-то посмотреть, без лишних танцев с бубном.
Не ставилась самоцель использовать самый распространённый peecee формат.
Опять же цель была использовать как можно проще, гибкость тут не нужна.
в IFF тоже можно использовать контейнеры для разных типов. Но это не облегчает задачу, а лишь запутывает и делает реализацию формата на Z80 только сложнее. Ибо куда уже проще планарных данных которые тупо копируются с носителя в память без дополнительных поисков, преобразований, пересчётов итд.
В любом случае никто не запрещает хранить графику в том формате, в котором кодер считает нужным, хоть в RAW. Вопрос лишь в том, что будет ли это что-то реализовано на практике или же так и останется в комментариях.
С претензиями к BMP соглашусь. Добавлю еще неудобное хранение строк снизу вверх и отсутствие метаинформации без костылей.
Как показывает практика, подобная непредусмотрительность очень часто выходит боком… Тем более, что даже в свой формат ты заложил возможность расширения и какую-то гибкость. Зачем, спрашивается?;)
К сожалению, даже в твоем формате без поисков, преобразований и пересчетов не обойтись. Такова цена за удобство передачи информации.
При использовании готовых решений снимается серьезная часть проблем, связанных с поддержкой и применением.
Я уже давно занимаюсь проблемой поиска и извлечения всякой полезной информации из спектрумовского наследия. Могу сказать, что самый кошмар- это обычные спектрумовские экраны. Фигпойми как за разумное время определить, что конкретный блок данных длиной 6912 или 6144 байта- картинка, а не код или текст с раскраской. Такая же проблема и у других форматов, авторы которой не предусмотрели никаких опознавательных признаков, но это уже другая история.
Ну как не трудно догадаться, файл в данном формате является частью системы CLI. Каждый файл начинается с описателя #7f и трёх символов расширения. Далее следует заголовок который описывает структуру данных.
На данный момент ещё не все файлы приведены к данной структуре (например fnt пока просто бинарь), но в ближайшем будущем всё будет приведено в порядок.
Конечно же, что бы иметь возможность расширения header'а, теми же метаданными к примеру :)
Возможно, но стоит учитывать, что эти решения требуют далеко не 8-битного железа для реализации. Например, использование того же FAT/FAT32. Да это даёт совместимость с виндой, но сильно проигрывает в скорости, и рентабельности используемого пространства. На спектруме файлы достаточно малого размера и их много и использование FAT32 для этой задачи не самое лучшее решение.
А шрифты? а упакованные данные? Раньше время было другое, экономили каждый байт, как в памяти, так и на ленте/дискете. И вообще «джентльменам верили на слово» :) Сказал, что я экран, значит экран ;)
Философский вопрос. Если все нельзя сделать идеально (а так будет всегда), это же не означает, что вообще не нужно стараться делать хорошо.
Абсолютно та же проблема
С ними как раз гораздо проще. К упакованным данным обычно приклеивается распаковщик, де-факто являющийся сигнатурой. Если нет распаковщика, обычно есть некие заголовки с сигнатурами (MsPack,Hrust). ИЧСХ, созданы они были как раз в те времена, когда «экономили каждый байт». А вот у современного MegaLZ, рожденного в эпоху широких каналов и толстых носителей, этих сигнатур нет.
Опять парадокс. С упакованными экранами, облегчающими проблему экономии байт, так же проблем нет.
Так что разруха- она в головах…
Всё в мире относительно (:
Согласен ;)
Ну это-то да. Тут больше вопрос стоит в том, какую цель человек преследует. Получить в максимально короткий срок конкретный результат или же получать удовольствие от процесса создания «велосипедов» (:
Кстати, да, что-то я упустил такой момент. Ведь для музыкальных модулей есть такое понятие, как название трека и автор, а вот у картинок почему-то это упущено.