А вот представьте себе орга пати.
Ему присылают бмп ИЛИ ему присылают схг?
Отлично себе представляю :) Точно такой же «гемор», как если бы ему прислали файлы $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'ки сохраняет! Почему?
для коллекций- самое то (можно еще всякую метаинформацию пихать).
Кстати, да, что-то я упустил такой момент. Ведь для музыкальных модулей есть такое понятие, как название трека и автор, а вот у картинок почему-то это упущено.
Если все нельзя сделать идеально (а так будет всегда), это же не означает, что вообще не нужно стараться делать хорошо.
Ну это-то да. Тут больше вопрос стоит в том, какую цель человек преследует. Получить в максимально короткий срок конкретный результат или же получать удовольствие от процесса создания «велосипедов» (:
Ну как не трудно догадаться, файл в данном формате является частью системы CLI. Каждый файл начинается с описателя #7f и трёх символов расширения. Далее следует заголовок который описывает структуру данных.
На данный момент ещё не все файлы приведены к данной структуре (например fnt пока просто бинарь), но в ближайшем будущем всё будет приведено в порядок.
Зачем, спрашивается?;)
Конечно же, что бы иметь возможность расширения header'а, теми же метаданными к примеру :)
При использовании готовых решений снимается серьезная часть проблем, связанных с поддержкой и применением.
Возможно, но стоит учитывать, что эти решения требуют далеко не 8-битного железа для реализации. Например, использование того же FAT/FAT32. Да это даёт совместимость с виндой, но сильно проигрывает в скорости, и рентабельности используемого пространства. На спектруме файлы достаточно малого размера и их много и использование FAT32 для этой задачи не самое лучшее решение.
сказать, что самый кошмар- это обычные спектрумовские экраны.
А шрифты? а упакованные данные? Раньше время было другое, экономили каждый байт, как в памяти, так и на ленте/дискете. И вообще «джентльменам верили на слово» :) Сказал, что я экран, значит экран ;)
Не ставилась самоцель найти все недостатки, я лишь привёл пару примеров, чем мне не нравится данный формат.
Писал бмп-вьювер для пентевы и могу сказать, что…
Проблема не в сложности реализации, а в востребованности. Можно реализовать хоть SVG и рисовать «процессуальную графику», но! если же это опять кому-нибудь будет нужно. И он действительно захочет оторвать свою пятую точку и наконец что-то зарелизит :)
Ну наверное по той же причине, «почему не использовать TGA/GIF/PCX/ETC?»
а) очень распространенный
Не ставилась самоцель использовать самый распространённый peecee формат.
б) очень гибкий по своей структуре
Опять же цель была использовать как можно проще, гибкость тут не нужна.
Второе свойство позволяет использовать его в качестве контейнера.
в IFF тоже можно использовать контейнеры для разных типов. Но это не облегчает задачу, а лишь запутывает и делает реализацию формата на Z80 только сложнее. Ибо куда уже проще планарных данных которые тупо копируются с носителя в память без дополнительных поисков, преобразований, пересчётов итд.
В любом случае никто не запрещает хранить графику в том формате, в котором кодер считает нужным, хоть в RAW. Вопрос лишь в том, что будет ли это что-то реализовано на практике или же так и останется в комментариях.
В большинстве случаев открываю ссылки колесом, автоматом в новом табе, но иногда хочу открыть ссылку в этом же, и честно признаюсь жутко раздраже когда открывают новый таб или упаси божи новое окно.
Ооо! Зер гӱт, сам давно хотел написать что-то подобное, но всё руки не доходили. Но зато тепер с чистой душой можно рассказать о создании своей интры ;)
Ну отчего же, спектрумисты тоже ставили рекорды. И если мне не изменяет память, 800-stars эффект от E-mage так никто и не побил?
Тоесть вариант, PhotoShop->Save as…->SXG + Wild Commander Plugin решат задачу?
Отлично себе представляю :) Точно такой же «гемор», как если бы ему прислали файлы $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'ки сохраняет! Почему?
Кстати, да, что-то я упустил такой момент. Ведь для музыкальных модулей есть такое понятие, как название трека и автор, а вот у картинок почему-то это упущено.
Всё в мире относительно (:
Согласен ;)
Ну это-то да. Тут больше вопрос стоит в том, какую цель человек преследует. Получить в максимально короткий срок конкретный результат или же получать удовольствие от процесса создания «велосипедов» (:
Ну как не трудно догадаться, файл в данном формате является частью системы CLI. Каждый файл начинается с описателя #7f и трёх символов расширения. Далее следует заголовок который описывает структуру данных.
На данный момент ещё не все файлы приведены к данной структуре (например fnt пока просто бинарь), но в ближайшем будущем всё будет приведено в порядок.
Конечно же, что бы иметь возможность расширения header'а, теми же метаданными к примеру :)
Возможно, но стоит учитывать, что эти решения требуют далеко не 8-битного железа для реализации. Например, использование того же FAT/FAT32. Да это даёт совместимость с виндой, но сильно проигрывает в скорости, и рентабельности используемого пространства. На спектруме файлы достаточно малого размера и их много и использование FAT32 для этой задачи не самое лучшее решение.
А шрифты? а упакованные данные? Раньше время было другое, экономили каждый байт, как в памяти, так и на ленте/дискете. И вообще «джентльменам верили на слово» :) Сказал, что я экран, значит экран ;)
Не ставилась самоцель найти все недостатки, я лишь привёл пару примеров, чем мне не нравится данный формат.
Проблема не в сложности реализации, а в востребованности. Можно реализовать хоть SVG и рисовать «процессуальную графику», но! если же это опять кому-нибудь будет нужно. И он действительно захочет оторвать свою пятую точку и наконец что-то зарелизит :)
Не ставилась самоцель использовать самый распространённый peecee формат.
Опять же цель была использовать как можно проще, гибкость тут не нужна.
в IFF тоже можно использовать контейнеры для разных типов. Но это не облегчает задачу, а лишь запутывает и делает реализацию формата на Z80 только сложнее. Ибо куда уже проще планарных данных которые тупо копируются с носителя в память без дополнительных поисков, преобразований, пересчётов итд.
В любом случае никто не запрещает хранить графику в том формате, в котором кодер считает нужным, хоть в RAW. Вопрос лишь в том, что будет ли это что-то реализовано на практике или же так и останется в комментариях.
гы гы :) напомнило,…
А у тебя сомнения? ;) Конечно интересны. На мой взгляд тут всё интересно, кроме публицистики и тем о хайпе (:
Ох, как это я пропустил такую чудо-карусель!? (:
:)