Масштабируемые шрифты

Kernel-side graphics support
  • Координаты окна 2 раза прибавляются к глобальным координатам строки текста.
  • А может drawbar рисуется от оконых координат, а putpixel-экранных?

    Попробывал делить координаты Х и У на 2 не помогло
  • Все сделал. Спасибо всем кто помогал.
    Размер передается вместе с цветом например 0x02000000 выведется текст черного цвета в два раза больше обычного размера. Пока что сделан только моноширинный шрифт.
    Вот код процедур измененнных в font.inc
    SizeFont dd 1
    align 4
    mydrawbox:
    pusha
    mov esi,[SizeFont]
    mov edi,[SizeFont]
    .drpix:
    call [putpixel]
    inc eax
    dec edi
    jnz .drpix
    sub eax,[SizeFont]
    inc ebx
    mov edi,[SizeFont]
    dec esi
    jnz .drpix
    popa
    ret

    align 4
    dtext: ; Text String Output (rw by Johnny_B[john@kolibrios.org])
    ; eax x & y
    ; ebx font ( 0xX0000000 ) & color ( 0x00RRGGBB )
    ; ecx start of text
    ; edx length
    ; edi 1 force

    pushad

    mov esi,edx ;esi=length
    mov ebp,ecx ;ebp=ptr to text
    mov ecx,ebx ;ecx=color
    movzx ebx,ax ;ebx=y
    shr eax,16 ;eax=x
    and esi, 0xFF ;limit of text = 255 symbols

    push ecx
    shr ecx,24
    and ecx,0x0F
    test ecx,ecx
    jne .dalee
    mov ecx,1
    .dalee:
    mov [SizeFont],ecx
    pop ecx

    dtext.lnew:
    test esi, esi ; zero length ?
    jnz @f
    jmp dtext.output_end
    @@:

    movzx edx,byte [ebp] ;edx=ascii code
    test edx,edx
    jz dtext.output_end
    test ecx,0x10000000
    jnz dtext.letnew2

    align 4
    .letnew:

    drawletter: ;output char of type 1(monotype)
    ;eax - x
    ;ebx - y
    ;ecx - color
    ;edx - ascii code
    pushad
    call [disable_mouse]
    mov esi,9
    lea ebp,[0x3F600+8*edx+edx]
    .symloop:
    push esi
    mov dl,byte [ebp]
    mov esi,8
    .pixloop:
    test dl,1
    jz .nopix
    call mydrawbox
    .nopix:
    shr dl,1
    add eax,[SizeFont]
    dec esi
    jnz .pixloop
    push ebx
    mov ebx,8
    imul ebx,[SizeFont]
    sub eax,ebx
    pop ebx
    add ebx,[SizeFont]
    inc ebp
    pop esi
    dec esi
    jnz .symloop
    popad

    push ebx
    mov ebx,6
    imul ebx,[SizeFont]
    add eax,ebx
    pop ebx

    inc ebp ;ptr to text
    dec esi ;length
    jnz dtext.lnew

    jmp dtext.output_end


    dtext.letnew2:
  • Предлагаю в качестве расширения системных шрифтов использовать следующий подход:
    Я пишу библиотеку, которая позволяет выводить шрифт с таким интерфейсом:
    - кидаем в стек указатель на строку, указываем цвета фона и текста, указываем куда выводить.
    Пользоваться можно будет как из ассеблерных программ,так и из С. либа будет поддерживать такие вызовы.
    пример использования шрифта 8х16 приведен во вложении. Для вывода ширифта используется 65 функция.
    Attachments
    Пример использования шрифта 8х16.
    Example_font_8x16.png (10.79 KiB)
    Пример использования шрифта 8х16. Viewed 12503 times
  • Как раз последние два дня думаю чтобы такое сделать со шрифтами в Колибри чтобы они стали больше :)
    Да... 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 уже существует. Конечно шрифты должны быть специально для этого подготовлены. Можно сделать функцию которая будет возвращать указатель на глиф.
    На счет переноса слов, эм.. имхо этим должна заниматься не библиотека шрифтов. Допустим будет написана функция которая будет грамотно переносить слова и разделять общий текст на строчки спец символами. Если это будет сделано, можно отобразить корректно текст в при динамическом изменении окна. Хм. вывод текства в память ? Фактически он уже в памяти - можно возращать указатель на начало блока и размер блока т.е. текст преобразован в глифы и имеет массив. На счет прозрачности, я уже писал выше, только при наличии полного управления выводом. Т.е. если раньше что-то было на канве приложения и это не формировалось либой, оно будет затерто. Градиент, то же возможно реализовать, но не сразу.

    Code: Select all

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

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

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

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

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

    ..bw
  • Может быть реализовать как-то более чем просто библиотеку? Может быть на функцию ядра? Так было бы и проще и быстрее.
    Использовать, конечно, буду :)
    Из хаоса в космос
  • Уже давно согласились, что функции GUI в ядре, это не хорошо. А ты предлагаешь вернуться к тому, от чего пытаемся отойти.

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

    Users browsing this forum: No registered users and 5 guests