Если выводить в лоб через DOSовское 21h прерывание, то программа занимает 35 байт. А ту же Баше можно уместить байт эдак в 20 для процессора Z80, я уверен.
Хороший вопрос, я однажды об него споткнулся.
Алгоритм ищет пересечения прямых и луча. Угол, как вы понимаете, прямой не является. Так что непарного количества точек не будет.
Спасибо за интересный перевод. Широко шагает прогресс! Как наивен я был лет десять назад, когда думал, что удобнее WinAmp плейеров не бывает. Впрочем, не каждый mp3-плейер заработает на 486м с 8Мб ОЗУ.
Насколько мне известно, мак не использует хинтинг, так что результаты будут примерно одинаковые. У меня, к сожалению, мака нет. Если у вас есть, покажите пожалуйста миру результаты.
Те, кто делает анимацию в Maya, могут позволить себе делать и 60, и 120 кадров в секунду. А те, кто по-старинке рисует карандашом или кистями, не могут себе такую роскошь позволить.
15 кадров в секунду — это половина от 30 кадров для NTSC, 12 — половина от PAL.
И верно, я погорячился. 14 fps незачем.
Наверное, все слышали про 25 кадров в секунду (этого достаточно для кинематографа). Но аниме раньше рисовали вручную, например, карандашами. Чем меньше кадров в секунду — тем меньше рисунков, очевидно.
Кусок текста с одного из случайных сайтов: С технической точки зрения "Акира" для конца 1980-х был настоящим аниме-совершенством. Это было первое аниме с частотой 24 кадра в секунду (промышленный аниме-стандарт - 12-15 кадров в секунду).
Тестовая машина — Celeron 2.4GHz. Бенчмарк FreeType 2.4.4: без сглаживания 10x10 пикселей — 10мс/глиф, 24x24 пиксела — 15 мс/глиф, 600x600 — 275мс/глиф. У моего алгоритма (версия на JS) 10x10 пикселей — около 5 мс/глиф с выводом на экран и менее 1 мс/глиф в ОЗУ. 600x600 — около 250мс/глиф.
На ассемблере совсем не страшно. С помощью старших товарищей, конечно.
Планирую отрисовывать в ОЗУ и передавать указатель на битмап.
Колибри потому, что я имею некоторое отношение к проекту (я портировал для Колибри Lua 5.2a и FreeType 2.4.4). Именно результаты портирования FreeType (300-килобайтная библиотека для встраиваемой в ROM BIOS системы подобна смерти) подтолкнули к разработке своего велосипеда.
Первоначально команды сопроцессора я использовал, но в последних версиях свел все вычисления к целочисленным. Кстати, переключение задач в Колибри проблем с сопроцессором не вызывает, насколько я знаю.
Динамическая библиотека для Колибри — это объектный файл в формате COFF. Пока что растеризатор еще не является полноценной библиотекой, к сожалению, но даже если и будет являться, то вряд ли будет зависеть от какого-то стороннего кода.
Собираюсь распространять под LGPL, как только библиотека будет готова.
В перспективе (после отладки) код будет переписан на flat assembler, оформлен в виде динамической библиотеки (по возможности кросс-платформенной), и доступен всем желающим. А оформлением кода на java's_creep я займусь, если будет свободное время.
Алгоритм ищет пересечения прямых и луча. Угол, как вы понимаете, прямой не является. Так что непарного количества точек не будет.
15 кадров в секунду — это половина от 30 кадров для NTSC, 12 — половина от PAL.
И верно, я погорячился. 14 fps незачем.
Кусок текста с одного из случайных сайтов:
С технической точки зрения "Акира" для конца 1980-х был настоящим аниме-совершенством. Это было первое аниме с частотой 24 кадра в секунду (промышленный аниме-стандарт - 12-15 кадров в секунду).Возможно, я и ошибаюсь.
Тестовая машина — Celeron 2.4GHz. Бенчмарк FreeType 2.4.4: без сглаживания 10x10 пикселей — 10мс/глиф, 24x24 пиксела — 15 мс/глиф, 600x600 — 275мс/глиф. У моего алгоритма (версия на JS) 10x10 пикселей — около 5 мс/глиф с выводом на экран и менее 1 мс/глиф в ОЗУ. 600x600 — около 250мс/глиф.
Планирую отрисовывать в ОЗУ и передавать указатель на битмап.
Колибри потому, что я имею некоторое отношение к проекту (я портировал для Колибри Lua 5.2a и FreeType 2.4.4). Именно результаты портирования FreeType (300-килобайтная библиотека для встраиваемой в ROM BIOS системы подобна смерти) подтолкнули к разработке своего велосипеда.
Первоначально команды сопроцессора я использовал, но в последних версиях свел все вычисления к целочисленным. Кстати, переключение задач в Колибри проблем с сопроцессором не вызывает, насколько я знаю.
Динамическая библиотека для Колибри — это объектный файл в формате COFF. Пока что растеризатор еще не является полноценной библиотекой, к сожалению, но даже если и будет являться, то вряд ли будет зависеть от какого-то стороннего кода.
Собираюсь распространять под LGPL, как только библиотека будет готова.