Comments 27
Было б хорошо если вы приложите в конце файл с отформатированными функциями. А то отформатированный хаброй код не сильно читаем.
Для тех кто очень сильно хочет разобраться разберется, но почему бы не сделать хоть такую мелочь сделать лучше?
А вообще красота)
Для тех кто очень сильно хочет разобраться разберется, но почему бы не сделать хоть такую мелочь сделать лучше?
А вообще красота)
В перспективе (после отладки) код будет переписан на flat assembler, оформлен в виде динамической библиотеки (по возможности кросс-платформенной), и доступен всем желающим. А оформлением кода на java's_creep я займусь, если будет свободное время.
>кросс-платформенной
>flat assembler
это как?
>flat assembler
это как?
Linux, Windows, Dos и прочие системы. Или это как-то иначе называется?
я не знаю, как это называется, но последние два с половиной раза, когда мне нужно было рисовать буквы руками по голому битмапу, это были совсем не линупсы-виндовсы и вообще не 86ой процессор.
я понимаю, что фигачить на асме — это типа круто, но такая специфическая задача, которую решает ваш код, обычно возникает не в таких намоленых средах, а в диких дебрях непаханого адресного пространства, по которым скачет закрузчик встраиваемой системы с процессором более другого набора инструкций.
оставьте лучше на сишечке.
я понимаю, что фигачить на асме — это типа круто, но такая специфическая задача, которую решает ваш код, обычно возникает не в таких намоленых средах, а в диких дебрях непаханого адресного пространства, по которым скачет закрузчик встраиваемой системы с процессором более другого набора инструкций.
оставьте лучше на сишечке.
Код не настолько сложный, чтобы нельзя было поддерживать две ветви одновременно. Точнее, он совсем несложный.
Если тема еще интересна — есть код (не мой), в Public Domain, отлично работающий с TTF. При этом занимает в бинарном виде сущие килобайты (правда, все же раз в 7 больше, чем мой растеризатор, но это, видимо, из-за парсера ttf).
Очень очень интересно. А можно с этого момента подробнее? На ассемблере, это не страшно, если документируете API.
На каком объекте планируете рисовать? (битмап, видеопамять, etc.)
Почему Kolibri OS? Вы имеете отношение к этому проекту?
И ещё вопрос по числам с плавающей запятой — используете команды математического сопроцессора? К сожалению я не знаком с архитектурой Kolibri — не вызовет ли переключение задач проблем с сопроцессором?
Можно ли рассчитывать не на динамическую библиотеку, а на объектный файл в формате elf? Желательно, чтобы без обращений к другим библиотекам.
И самый последний вопрос — под какой лицензией собираетесь распространять растеризатор?
На каком объекте планируете рисовать? (битмап, видеопамять, etc.)
Почему Kolibri OS? Вы имеете отношение к этому проекту?
И ещё вопрос по числам с плавающей запятой — используете команды математического сопроцессора? К сожалению я не знаком с архитектурой Kolibri — не вызовет ли переключение задач проблем с сопроцессором?
Можно ли рассчитывать не на динамическую библиотеку, а на объектный файл в формате elf? Желательно, чтобы без обращений к другим библиотекам.
И самый последний вопрос — под какой лицензией собираетесь распространять растеризатор?
На ассемблере совсем не страшно. С помощью старших товарищей, конечно.
Планирую отрисовывать в ОЗУ и передавать указатель на битмап.
Колибри потому, что я имею некоторое отношение к проекту (я портировал для Колибри Lua 5.2a и FreeType 2.4.4). Именно результаты портирования FreeType (300-килобайтная библиотека для встраиваемой в ROM BIOS системы подобна смерти) подтолкнули к разработке своего велосипеда.
Первоначально команды сопроцессора я использовал, но в последних версиях свел все вычисления к целочисленным. Кстати, переключение задач в Колибри проблем с сопроцессором не вызывает, насколько я знаю.
Динамическая библиотека для Колибри — это объектный файл в формате COFF. Пока что растеризатор еще не является полноценной библиотекой, к сожалению, но даже если и будет являться, то вряд ли будет зависеть от какого-то стороннего кода.
Собираюсь распространять под LGPL, как только библиотека будет готова.
Планирую отрисовывать в ОЗУ и передавать указатель на битмап.
Колибри потому, что я имею некоторое отношение к проекту (я портировал для Колибри Lua 5.2a и FreeType 2.4.4). Именно результаты портирования FreeType (300-килобайтная библиотека для встраиваемой в ROM BIOS системы подобна смерти) подтолкнули к разработке своего велосипеда.
Первоначально команды сопроцессора я использовал, но в последних версиях свел все вычисления к целочисленным. Кстати, переключение задач в Колибри проблем с сопроцессором не вызывает, насколько я знаю.
Динамическая библиотека для Колибри — это объектный файл в формате COFF. Пока что растеризатор еще не является полноценной библиотекой, к сожалению, но даже если и будет являться, то вряд ли будет зависеть от какого-то стороннего кода.
Собираюсь распространять под LGPL, как только библиотека будет готова.
Используйте тег source и тогда у вас статья влезет в лимит.
крутой чувак! +1
как уроки физики в школе? справляешься?
Помню на пед. практике вел физику — еле дожил :)
Успехов!
Помню на пед. практике вел физику — еле дожил :)
Успехов!
Насчет заливки полигона почитайте про алгоритмы тесселяции ;-)
Слово-то какое страшное! А вообще идея интересная — использовать GPU для растеризации шрифтов. Если вы конечно это имели в виду.
Кроме аппаратной тесселяции с использованием GPU можно реализовать программную. Тут есть ссылки на описания некоторых алгоритмов.
Если не секрет сколько глифов сможет отрисовать данный алгоритм за секунду?
Хм, кажется, я делал замеры когда-то…
Тестовая машина — Celeron 2.4GHz. Бенчмарк FreeType 2.4.4: без сглаживания 10x10 пикселей — 10мс/глиф, 24x24 пиксела — 15 мс/глиф, 600x600 — 275мс/глиф. У моего алгоритма (версия на JS) 10x10 пикселей — около 5 мс/глиф с выводом на экран и менее 1 мс/глиф в ОЗУ. 600x600 — около 250мс/глиф.
Тестовая машина — Celeron 2.4GHz. Бенчмарк FreeType 2.4.4: без сглаживания 10x10 пикселей — 10мс/глиф, 24x24 пиксела — 15 мс/глиф, 600x600 — 275мс/глиф. У моего алгоритма (версия на JS) 10x10 пикселей — около 5 мс/глиф с выводом на экран и менее 1 мс/глиф в ОЗУ. 600x600 — около 250мс/глиф.
Очень хотелось бы сравнения с теплым ламповым маковским растеризатором.
Мне на LCD мониторе больше нравится полутональное сглаживание чем субпиксельное, как ни странно — всё таки цвет по контуру мне бросается в глаза.
Дело вкуса. Я например немного дальтоник, так что мне больше нравится сглаживание по субпикселам.
Может зависить от монитора и его настроек, может от алогоритмов и их настроек, может от шрифтов, например, в Win7 я не смог настроить субпиксельное сглаживание, чтобы не видеть ореол, а в Ubuntu из коробки очень приятные и ровные контуры, в Arch'e стоит полутональное сглаживание, т. к. смотрится приятнее, а шрифты с полутональным сглаживанием из Mac OS X на моем мониторе смотрятся размытыми.
А что, если луч пройдет через угол? Непарное ведь количество точек будет.
UFO just landed and posted this here
Sign up to leave a comment.
Растеризация векторных шрифтов