Board.KolibriOS.org

Решил я тут немного расширить возможности вывода обычного шрифта и начал делать масштабирование, но встретился с такой проблемой: если окно находится в координатах 0:0, то все отлично, но стоит сдвинуть окно, как шрифт начинает все дальше уползать от нужного месторасположения. Выкладываю тут скрины и то, что я переделал в font.inc. Кто знает в чем проблема?


Смещаем окно:

Код(из 0530):
http://knikolenko.narod.ru/kolibri/font.inc

Координаты окна 2 раза прибавляются к глобальным координатам строки текста.

А может drawbar рисуется от оконых координат, а putpixel-экранных?

Попробывал делить координаты Х и У на 2 не помогло

Все сделал. Спасибо всем кто помогал.
Размер передается вместе с цветом например 0x02000000 выведется текст черного цвета в два раза больше обычного размера. Пока что сделан только моноширинный шрифт.
Вот код процедур измененнных в font.inc

Предлагаю в качестве расширения системных шрифтов использовать следующий подход:
Я пишу библиотеку, которая позволяет выводить шрифт с таким интерфейсом:
- кидаем в стек указатель на строку, указываем цвета фона и текста, указываем куда выводить.
Пользоваться можно будет как из ассеблерных программ,так и из С. либа будет поддерживать такие вызовы.
пример использования шрифта 8х16 приведен во вложении. Для вывода ширифта используется 65 функция.

Как раз последние два дня думаю чтобы такое сделать со шрифтами в Колибри чтобы они стали больше
Да... 1. Можно будет испольовать только этот шрифт или любой?
2. Как там со скоростью вывода шрифтов? Намного медленнее, чем обычных?

_________________
Звиздеть не мешки ворочать

Leency
Re:
1. Можно будет использовать любой шрифт который будет в библиотеке.
2. Кто-нибудь жаловался на скорость отрисовки kfar или console? Подход один и тот же.
Чем больше нужно будет отображить на экране текстовой информации, тем этот подход будет быстрее работать чем вывод 2 системных шрифтов. Т.е. при выводе картинки - выводиться она только 1 раз и сразу заполняет область канвы приложения. Системные шрифты обрабатывают каждый символ в отдельности, чем больше букв, тем медленнее работают системные втроенные в ядро шрифты.

Еще у меня вопрос, как много людей хотят или планируют использовать такой подход при написании/переписывании приложений?

Рад буду изменить для этого Tinypad, однако нужно будет ещё две функции, возвращающие ширину и высоту заданного текста. Плюс, возможность рисовать без заливки фона (м?), хотя это не особо обязательно (не помню уже, как там у меня было реализовано).

_________________
in code we trust

Хотелось бы иметь возможность указывать свои шрифты. А так же возможность передать библиотеке callback функцию для создания изображения (глифа) символа, которая вызывается библиотекой при необходимости. Если библиотека будет брать шрифты по именам из некой общей системной директории, будет замечательно. Перенос слов. Расчет размера области вывода с учетом переноса. Вывод текста на bitmap (в память). Области обрезания отрисовки (clipping). Прозрачный фон. Прозрачные символы. Градиент вместо цвета. Callback вместо цвета. И т.д.
Библиотека безусловна нужна, но если её делать, то пусть она будет функционально совершенна :-). А сделать просто вывод битового шрифта каждый может и сам в своём проекте, это не так уж сложно. Хотя, конечно, не всё сразу.

..bw

безусловно, буду использовать

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

mike.dld
Поскольку изображение формируется в озу то это можно будет сделать.
Рисование без заливки фона с этим сложнее т.к. для этого нужно иметь как минимум 2 копии области куда будет рисовататься, что бы применить наложение (у меня есть примеры использования mmx команд). Т.е. наложение будет возможно только если вывод будет полностью управляться библиотекой.

bw
Да, это будет сделано, шрифты можно будет выбирать, как по размеру, так и по типу. Папка FONT уже существует. Конечно шрифты должны быть специально для этого подготовлены. Можно сделать функцию которая будет возвращать указатель на глиф.
На счет переноса слов, эм.. имхо этим должна заниматься не библиотека шрифтов. Допустим будет написана функция которая будет грамотно переносить слова и разделять общий текст на строчки спец символами. Если это будет сделано, можно отобразить корректно текст в при динамическом изменении окна. Хм. вывод текства в память ? Фактически он уже в памяти - можно возращать указатель на начало блока и размер блока т.е. текст преобразован в глифы и имеет массив. На счет прозрачности, я уже писал выше, только при наличии полного управления выводом. Т.е. если раньше что-то было на канве приложения и это не формировалось либой, оно будет затерто. Градиент, то же возможно реализовать, но не сразу.

Callback вместо цвета

О_о это как это *?

За всю истрорию Коос, это сделали единицы, и только для своих проектов. к примеру kfar.
Конечно может Serge или кто -то еще и прикрутит шрифты от иксов, но я думаю без аппаратной акселерации это будет медленно.
Фактически это простой способ получить конечному приложению возможность управлять шрифтами. Этот подход не лишен недостатков, т.к. потребности в ОЗУ значительно возрастают. К примеру шрифт 8х16 после обработки у меня занимает 4096 байт. При реализации хотя бы 50 % от озвученного потребуется области ОЗУ ~300 -900 кб. И такая картина будет для каждого приложения которое будет использовать эту библиотеку.
При рациональном использовании можно сократить объем используемого ОЗУ до 20 -50 Кб.

> Т.е. наложение будет возможно только если вывод будет полностью управляться библиотекой.

Ну а почему не выводить глиф, в таком случае, попиксельно. Я полагаю что ты планируешь его отрисовывать целиком?

>> Callback вместо цвета
> О_о это как это *?

При выводе (x, y) точки глифа, вызывается пользовательская функция для получения цвета. Это избавит тебя от, скажем, реализации градиента, а пользователю твоей библиотеки позволит реализовавывать разнообразные эффекты. Этот callback может вызываться каждый раз при выводе глифа, тогда решится проблема с прозрачность, в том числе с альфой :-). Или он будет вызываться только при построении глифа, а дальше используется только этот кешированный результат.

p.s. Прозрачность нужна обязательно.

..bw

Может быть реализовать как-то более чем просто библиотеку? Может быть на функцию ядра? Так было бы и проще и быстрее.
Использовать, конечно, буду

_________________
Звиздеть не мешки ворочать

Уже давно согласились, что функции GUI в ядре, это не хорошо. А ты предлагаешь вернуться к тому, от чего пытаемся отойти.

..bw

Функция 65 заточена на вывод целиком изображения, сейчас попиксельно выводиться системные шрифты, как ты знаешь на больших объемах это тормоза. А ты предлагаешь венуться, к тому от чего хочется уйти.
Теперь представим ситуацию, к примеру в глиф 8х16 - итого 128 точек для каждой точки ты предлагаешь вызывать callback для получения цвета пикселя. на 1 символ 128 вызовов.
для вывода текста длинной 200 символов тебе потребуется 200х128=25600 раз вызвать функцию для получения цвета. На машинах ниже PIII это будет видно глазу. И кто будет использовать это? Т.е. если это и реализовывать то только при аппаратной акселерации.
Далее при формировании градиента возможны тормоза при выводе, или увеличению использования ОЗУ(градиент будет сформирован для всего изображения в ОЗУ). Формирование прозрачности и наложения, конечно можно реализовать через прямой доступ к видеобуферу, но этот способ аппаратно зависим. Т.е. при появлении драйверов к видеокарточке может и не работать. Т.е. лучше иметь доступ к буферу через метод реализуемый драйвером.