Board.KolibriOS.org

"в этом и заключается преимущество SVG, в любом случае он покажет все графические объекты, которые поддерживает" в алгоритме, описанном мной в постах к Freeman'у было сказано как код парсера может обойти незнакомый элемент, и показать известные ему вещи, не показывая неизвестных.

"То же самое и с HTML. Вы видели хоть раз сообщение: "формат HTML-страницы не поддерживается"?" - не то же самое. Там таких вещей нет так как основные вещи от версии к версии не меняются. Только добавляются новые элементы. То же будет у нас. К тому же, по спецификации HTML браузер _обязан_ в случае ошибки отобразить страницу насколько это возможно. В случае с XHTML (который мне очень симпатичен) ситуация совершенно иная.Да и какая разница как все сделано в HTML, не графику же им описывать, в конце то концов.

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

_________________
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.

konstantin_666, это цвета в формате 0xAARRGGBB, где AA-прозрачность, RR,GG,BB - cоответственно, доли красного, зеленого, и синего цветов. Нули несут полезную нагрузку, доля цвета. А в хтмл это было бы #00FF00, нули остались, только каждый теперь занимает по байту, а не по полбайта, т.к. это - строка, а, ну и еще байт на решеточку

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

ну, с заполнением кодов это понятно. НО КАК мы узнаем на какое расстояние нам нужно перепрыгнуть?
а если один из операндов ASCIIZ-строка?

и как быть с необязательными операндами?

В общем, попусту теряю время, разбирайтесь сами.

_________________
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.

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

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

konstantin_666, "а если один из операндов ASCIIZ-строка?" - тогда надо прочитать черновик спецификации, который вы собираетесь критиковать, прежде чем, собственно, критиковать.
А в нем, а именно на первой странице данной темы, ясно указано, что строки указываются с длиной в начале.

"и как быть с необязательными операндами?" - обработку которых автор выкинул для экономии? ну дыки данные о длинах полей значит не надо выкидывать. хранить их можно весьма компактно - так как всего 4 варианта длинн (1,2,4,8 байт), для каждой битмаски нужно в два раза больше. (на 1 бит - 2 бита длины, байт битмаски - два байта длинн). Впрочем, это хранится не в файле, так что к самому формату отношения не имеет.

"В общем, попусту теряю время" - ага, причем, мое и тех, кто в зафлуженной теме будет искать полезную информацию

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

Прочёл с большим интересом, призадумался.

Первое впечатление: ребятишки очень хорошо и грамотно проработали именно те вопросы, которые в начале темы поставил Gluk.

Чрезвычайно плотный код с исчерпывающей 2D-функциональностью, с простой и цельной концепцией, приятно отличающийся от нудного PDF.
При этом сам байт-код довольно прост и остроумен,- для обычной оконной графики даже внешний компилятор/редактор ресурсов не нужен - можно будет записывать цепочки тегов прямо из приложения в GUI-буфер (с помощью простеньких макросов).

С парсингом тоже не вижу принципиальных проблем (анимацию, SWF4+ и скрипты можно отложить на потом). Надо только продумать обработку интерактивных тегов.

Так что имхуется мне что Asper прав - хотя бы здесь не стоит изобретать очередной велосипед.

____________________________________________________
P.S. ... GUI-движок на флешах - в этом есть некое благородное безумие ...

SVG еще может содержать JavaScript, тогда виджет может быть одним SVG файлом и виджеты будет очень просто создавать
А компилятор JavaScripta все равно нужен для браузера

art_zh
Не спешите. Парсер байт-кода - это такая штука, которую нельзя реализовать "неполностью".
Для реализации флэш необходимо добавить в библиотеку парсера абсолютно все объекты, которые описаны в спецификации.
Самый компактный парсер флэша весит 4 Мб. Библиотека векторных функций для флэша займёт гораздо больше, чем 4 Мб.
Не говоря уже о других библиотеках...

_________________
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.

В векторной подсистеме GUI должен быть реализован парсинг лишь тех байт-кодов, которые будут реально нужны приложению.
Формат этих кодов мы в принципе можем выбрать каким угодно, но здравый смысл подсказывает, что лучше все-таки опираться на какой-нибудь уже опробованный стандарт.
Почему бы не использовать некоторые из флеш-тегов (и, разумеется, реализовать парсинг этого подмножества полностью)

Потом можно будет добавлять новые теги по мере надобности - на совместимости GUI-версий "снизу вверх" это не скажется.

Зачем?
В спецификации SWF3 не было скриптов, стековой арифметики и многих других прибамбасов, появившихся в поздних версиях (я уж не говорю о до сих пор не включенных в стандарт 3D-примочках), и ничего, на большинстве мультяшек работает.
У нас же об анимации (по крайней мере сейчас) вообще разговор не идёт, хотя бы векторные шрифты до ума довести!


Я буду сильно разочарован, если парсер байт-кода векторной подсистемы Колибри потянет больше чем на 4Kb.

Библиотека векторных функций приложению вообще не нужна - только набор примитивных макросов, формирующих конкретные байт-коды и запихивающих их в GUI-буфер.

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

Code:

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

konstantin_666, "Following the header is a series of tagged data blocks. All tags share a common format, so any program parsing a SWF file can skip over blocks it does not understand.", это раздел SWF file structure спецификации SWF версии 9. Вы опять бросаетесь обсуждать формат, не читая его спецификации.

UPD01: Кстати, тут принципиальное отличие от предлагаемого мной формата. Однако, его можно доработать (для этого всего лишь нужна либо длина всех данных тэга, либо двойной битмаск длинн параметров. И в том и в другом случае от 2х байт на тэг. Интересно, как это сделано в SWF, мб дочитаю, если раньше не остановлюсь).
UPD02: во, страничку перелистнул и готово) "Each tag begins with a tag type and a lenght" // кстати, вариант с двойными битфилдами не спасет при строках, однако это решабельно убиранием длины в 8 байт и добавлением вместо этого "см длину в позиции параметра". В конце концов, 8 байт это уже вполне себе строка. Или таки длину указывать..
UPD03: нет, двойной битфилд лучше тем, что парсер может тогда знать тэг, но не знать какой-либо его параметр, и спокойно обработать все кроме параметра незнакомого (так можно без проблем в обновлениях спецификации спокойно добавлять новые параметры к имеющимся тэгам)
UPD04: к тому же, такие битфилды позволят задавать длину и для программ, знакомых с этим параметром и тэгом. Например, для задавания местоположения иногда можно будет использовать 1 байт вместо двух (даже в примере использовалось 2 байта, хотя числа помещались в один), таким образом можно как раз выгадать место для этих самых битфилдов. Я думаю что включу их в черновик, если никто не против (принятие SWF в качестве основного формта векторной графики в КоОС таки далеко не решенный вопрос, так что до принятия решения предлагаю продолжать разработку и этого формата).
UPD05: а! так битфилд длинн в файле же не обязан содержать длины отсутствующих параметров! тогда он может быть не то что не длиннее битмаски параметров, а может быть и короче. Так тем более он не хуже длины (т.к. часто может быть однобайтовым).

Я только начал читать спецификацию SWF, но могу не осилить, т.к. много текста на неродном языке. Так что по-прежнему жду пока Asper отпишется по моей просьбе насчет размера, файла, и вывода при парсинге.

(на случай, если у кого-то сообщения прилетают по RSS и изменения постов не видны) предыдущий пост в середине дополнен

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

тогда предлагаю так изменить формат битфилда параметров: 0 - нет параметра этого. ну, на нет и суда нет. 1 - есть параметр, и следующие 2 бита означают длину параметра.
При этом если на 7м бите указывается единица параметра, то длина указана в первых двух битах следующего байта, 8й при этом выполняет роль 8го бита следующего байта битфилда, освобождая тот 8й бит от его специального значения.
Если на 6м бите указывается единица параметра, то следующие 2 бита показывают, сколько впереди еще байт битфилда кроме одного (т.е. 00 если только один, 11 если 4), и тогда во всех остальных байтах битфилда, кроме 4го дополнительного (ну, если было 11, в послденем из них) 8й бит ничего не значит специального, и они обрабатываются как обычно.
Во всех остальных случаях 8й бит установлен в 1 если есть продолжение битмапа в следующем байте, в 0 - если битмап окончен, а во всех оставшихся параметрах, если таковые возможны, нули.

сложно, но вроде достаточно эффективно в плане объема упаковано. Читать программно нетрудно, разбирая каждый байт побитово так: копируя, сдвигая влево, сдвигая вправо, анализируя, при необходимости повторить. Можно еще битовые сравнения использовать, но я не знаю как это можно сделать удобнее.

Gluck
Никто не навязывает SWF-формат. Asper всего лишь посоветовал ознакомиться с идеями, которые там заложены.
Лично мне кое-что очень понравилось. Вот некоторые фишки (до конца еще не дочитал):

1) С самого начала, с заголовка, определяется размер фрейма (в мультиках=кадра; в нашем случае = окна) и частота его обновления. Это дает парсеру возможность заранее оценить объем требуемых ресурсов, а ядру - организовать эффективную отрисовку перекрытых окон.

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

3) Координаты задаются в твипсах (1twips = 1/20 pix), что избавляет от необходимости использовать вещественные координаты для рассчета полутонов. Глифы определяются сплайнами 2-го порядка, не требующими сложной математики.

4) Скупердяйски-плотный байт-код. В приложении А (стр.265) приведен пример описания простейшего фрейма с нарисованным в нем прямоугольником заданного размера, цвета, стиля линии и штриховки. Всего 79 байт (из них 21 байт занимает SWF-заголовок).

5) Понравилась идея уплотнения координат, в частности - формат структуры RECT (стр.36). В самом деле, зачем хранить координаты в 32-битных полях (16 бит для полноэкранной графики не хватит, однозначно), если размер объекта (например, глифа) - всего 250х250twips?

6) Тут выше были вопросы - хватит ли одного байта для номера объекта? И еще один, очень важный: как определить размер блока параметров? В SWF всё упаковано в 1 WORD заголовка тега: старшие 10 бит - номер (код) тега, младшие 6 - размер блока параметров в байтах. (Если этот размер равен 0x03F, значит параметры занимают больше 62 байт, и их размер содежит следующий DWORD).

Грамотно и красиво. Сколько бы мы тут спорили, прежде чем изобрести подобный велосипед?

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

Code:

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

art_zh,
"Никто не навязывает SWF-формат. Asper всего лишь посоветовал ознакомиться с идеями, которые там заложены."
- я обратного не утверждал, более того, сам ознакамливаюсь. К тому же я сам и предолжил либо разработать новый формат, либо выбрать существующий.

"1) С самого начала, с заголовка, определяется размер фрейма (кадра, или, в нашем случае - окна) и частота его обновления. Это дает парсеру возможность заранее оценить объем требуемых ресурсов."
-в предлагаемом формате размер _и_форма_ рисунка задается первым графическим объектом, который описан в файле, частота обновления не задается, так как не требуется для статики.

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

"3) Координаты задаются в твипсах (1twips = 1/20 pix), что избавляет от необходимости использовать вещественные координаты для рассчета полутонов. Глифы определяются сплайнами 2-го порядка (как в TTF-шрифтах), не требующими сложной математики."
-интересно, до этого еще не дочитал

"4) Скупердяйски-плотный байт-код. В приложении А (стр.265) приведен пример описания простейшего фрейма с нарисованным в нем прямоугольником заданного размера, цвета, стиля линии и штриховки. Всего 79 байт (из них 21 байт занимает SWF-заголовок)."
-мой вариант без учета заголовка чуть ли не в два раза компактней будет, впрочем, дождемся результатов, обещанных Asper'ом

"5) Понравилась идея уплотнения координат, в частности - формат структуры RECT (стр.36). В самом деле, зачем хранить координаты в 32-битных полях (16 бит для полноэкранной графики не хватит, однозначно), если размер окошка (например, глифа) - всего 256х256twips?"
-я в предыдущих постах двух предложил указывать размер данных в битовом поле, от 1 до 4 байт, или, в случае огромных полей для рисования, строкой координаты указать можно. А так до этого еще не дочитал)

"6) Тут выше были вопросы - хватит ли одного байта для номера объекта? И еще один, очень важный: как определить размер блока параметров? В SWF всё упаковано в 1 WORD заголовка тега: старшие 10 бит - номер (код) тега, младшие 6 - размер блока параметров в байтах. (Если этот размер равен 0x03F, значит параметры занимают больше 62 байт, и их размер содежит следующий DWORD). "
-а вот это читал. Тут 1024 типа объектов зарезервировано. Как определять размер блока параметров я предложил в предыдущих двух постах (придется разбирать только битфилд, и этого будет достаточно и для совершенно незнакомых тэгов).