Board.KolibriOS.org

Добавил описание общего парсинга swf файлов в Kofee. Файл обрабатывается полностью при этом незнакомые теги пропускаются, а на знакомые вызывается функция-обработчик тега, которая производит последующий парсинг этого тега и выполняет всю необходимую работу связанную с данным тегом. В принципе доработка Kofee состоит в том, чтобы добавлять отсутсвующие обработчики тегов, а также сделать нормальные Dictionary и DisplayList.

http://board.kolibrios.org/viewtopic.php?p=28821#p28821

art_zh,
Ну, в таких областях как картография, звездная картография, это так. Для таких случаев формат координат формата SWF действительно экономичней формата координат в моем варианте. (я не говорю что SWF в данной ситуации экономичней моего формата, это надо изучать детальнее, и нужно больше проработать формат, чтобы избавиться от "белых пятен", и спецификацию SWF таки дочитать, ну и, возможно, реализовать оба варианта в файлах (звезды теми же кружками реализовав))

Однако самое большое поле для рисования в КоОС, как мне видится, это рабочий стол, ну 2k*1,8k пикселов, и с десяток-другой объектов. Здесь разница не будет столь существенной. Уж иконки рабочего стола-то врядли будут больше чем 256*256 каждая, однако и для бОльших размеров все будет работать, правда, с дополнительным байтом кое-где. Виджеты - ну 256*2k максимум, опять же, и те же десятки объектов.

Кстати, для картографии этот формат не подойдет еще и по той же причине, как и его прообраз (SVG): для правильного отображения участка изображения следует загрузить все изображение (в т.ч. в память).

Asper,

огромное спасибо за проделанную работу! Осталось найти время на подробное изучение результатов. Надеюсь сделать это скоро

"Кстати в байтовой кодировке этой картинки в твоем формате то ли у тебя ошибки, то ли я чего не так понял" - ошибки не исключены, более того, пример больше не соответствует черновику спецификации ввиду изменения в черновике формата битовых полей параметров. Однако в резервные 50 байт он таки все равно уместится если его подправить) а насчет ошибки - буду благодарен, если мне на нее укажут)

"не зря же существует оптимизаторы флэш файлов"
-было бы здорово, если бы кто-нибудь пропустил этот файл (не на замену, а в копию) через такой оптимизатор, очень жалею что лишен пока что возможности сделать это самостоятельно..

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

Пожалуйста. Интереснее всего было рисовать с помощью hex-редактора и калькулятора.


В байтовом же описании должно быть 1 прямоугольник, 2 круг, чтобы соответствовало словесному описанию. Потом совершенно непонятно, что представляют из себя параметры, ну ладно там цвет интуитивно понятно, но вот остальные можно было бы и поподробнее описать.

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

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

Оно понятно, что пример абстрактный. Но как понять какое число, что значит. Вот я не мог понять пересекаются окружности из примера или нет, потому как не знал, где там координаты центра, величина радиуса и вообще, эти ли параметры используются или, что другое. Потому сделал на своё усмотрение не пересекающимися, со своими координатами.

не в пересечении суть =) а в количестве объектов и их параметров, и как это будет выглядеть байткодово, и сколько займет объема, ну и, конечно как будет читаться парсерами

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

Тогда понятно.
Вобщем лично я готов работать над SWF. На разработку новых стандартов у меня попросту нет времени.

1) 2k пикселей - это 40 тыс. твипсов. Реальный векторный объект (например, страница текста с TTF-шрифтами) вполне может иметь полмиллиона твипсов в длину и столько же - ширину.
Что же касается предыдущего примера, то 400х400 твипс соответствовал размеру небольшой иконки (20х20 pix)

2) загрузить 100кбайт в память - это проблема? (это классическая векторная задача, растровой графике такие задачи вообще не по зубам). Проблема - все это быстро и просто обработать

3) я лишь показал, что для больших векторных файлов (карты, чертежи, длинные многошрифтовые тексты) Gluk-формат так же неудачен, как и для маленьких (иконки, графики, пиктограммы)

art_zh,
"так же неудачен, как и для маленьких" - а вот это что-то новенькое, есть аргументация? пока по объему я вижу у SWF проигрыш, по сложности - отсутствие выигрыша.
кстати, какое из утверждений верно, "SWF свободно масштабируем" или "1 твипс=1/20 пиксела"?
И разве свободно масштабируемый формат не лучше (гибче)?

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

Gluck

http://board.kolibrios.org/viewtopic.php?f=4&t=1489&start=72

1-й пример (прямоугольник на малом поле): SWF-код компактнее в среднем на 25%,

2-й (много отдельных точек на широком поле) - на 40%.

Можно привести и другие примеры, только зачем - Вы их все равно не читаете, а другим все и так ясно.
Лучше было внять совету мудрого Mario и не затевать пустопорожних дискуссий.

_________________
Евангелие от Иоанна: стих 1

Code:

; В начале было Слово:
B32:        mov     ax, os_stack       ; Selector for os

art_zho,
"1-й пример (прямоугольник на малом поле): SWF-код компактнее в среднем на 25%," - там шла речь о способе задания координат. И во втором примере тоже. Ни капли не код компактнее, а координаты компактнее. В спецификации SWF идет пример с ОДНИМ объектом, на семьдесят с лишним байт. Я предложил пример с четыремя объектами на пятьдесят байт (даже с учетом сигнатуры в 3-4 байта в начале файла, и длины файла на столько же, будет менее 60 байт). Файл с одним объектом в моем варианте займет менее 22 байт, плюс только что описанный заголовок до 8 байт, итого 30 байт. И это несмотря на "плохой" способ задания координат, который кстати можно и изменить (формат то в разработке), только врядли на точно такой же как в SWF (софтверные патенты, и все такое)

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

Asper, еще раз спасибо, я сделаю в своих проектах поддержку формата SWF если Колибри-реализация его будет достаточно развита на тот момент (и не будет слишком "тяжелой").
Свой формат буду доделывать, так как я уже потратил на него больше времени чем планировал. Придумал еще интересные вещи, опубликую с первой версией формата (в которой хотя бы самые базовые элементы и свойства будут описаны). Некоторые из них, надеюсь, будут довольно интересны, однако дальнейшего усложнения формата не планируется (по крайней мере такого уровня, какого произошли с битовыми полями). И да, код реализации by me таки будет, но после публикации и обсуждения спецификации, по несколько раз переделывать его не очень хочется. Да и время надо будет найти.
Таки еще предложения по форматам приветствуются (доработка моего варианта/другие варианты).

Gluk
Я искренне рад, что ты не забросил дело, а то на форуме какое-то мертвое затишье опять наблюдается (ну не считая моей деятельности).

возник вопрос по поводу границ объектов. Допустим, у некоего квадрата есть некая граница, некой толщины. Так вот, я вижу несколько вариантов рисования такого прямоугольника:
1) рисуется квадрат с центром в той же точке что задана, но с длиной стороны, на толщину обводки меньшей чем заданная. Затем вокруг него впритык рисуется граница заданной толщины.
2) рисуется квадрат заданных изначально размеров, затем вокруг него рисуется граница толщиной с границу.
3) рисуется квадрат с длиной стороны, меньшей чем заданная на две толщины границы, затем, вокруг него, сама граница.

В SVG используется первый вариант, но он мне не нравится по той причине, что при толщине обводки, большей чем два пиксела ни один из получившихся квадратов (ни внутренний, ни внешний) не совпадает с заданными размерами.

Второй и третий вариант лишены этой проблемы, размеры обоих квадратов предсказуемы, однако из-за этого такие варианты лишены хорошей совместимости с SVG, при конвертации придется пересчитывать различные размеры.

Если мы решим использовать таки первый вариант, нужно будет определиться с одним небольшим ньюансом: при нечетной толщине границы в пикселах, "лишний" пиксел будет:
а) снаружи объекта
б) внутри объекта
(во втором и третьем варианте такой вопрос не стоит)

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

А если реализовать все?