SysFn 4

Kernel-side graphics support
  • Идею всецело поддерживаю.
    Из хаоса в космос
  • Как сказал в чате:
    Зачем функция, рисующая текст, должна возвращать его длину? Размер у надписи будет, даже если её не выводить.
    ИМХО размер и вывод на экран - вещи не связанные. Что, у нас номера функций закончились?
  • Функции имеют/будут иметь общий код. 4я и 74я функции - это будет очень и очень логично.
  • Мне тоже непонятно зачем? Хотелось бы более подробного изложения всей идеи.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • SoUrcerer wrote:74я функции
    Занято сетевым бранчем:

    Code: Select all

          dd blit_32                 ; 73-blitter;
          dd undefined_syscall       ; 74-reserved for new stack
          dd undefined_syscall       ; 75-reserved for new stack
          dd undefined_syscall       ; 76-reserved for new stack
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Сейчас везде моноширинный шрифт, потому что его размеры "известны" программисту. Это плохо, потому что дает ужасный результат с вашими любимыми большими и красивыми шрифтами.
  • SoUrcerer wrote:Это плохо, потому что дает ужасный результат с вашими любимыми большими и красивыми шрифтами.
    Я все равно не понимаю. Честно. Ты половину как минимум не договариваешь вслух.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Перевожу с русского на русский. Большинство программ работает сейчас так:
    У нас размер буквы 5x9 точек, с интервалом 1 точку между буквами. У нас надпись в 5 букв, так что сделаем кнопку в 5*(5+1)+2 = 32 пикселя шириной и 9+2=11 пикселей высотой.
    Так вот это нихера не работает, когда размер шрифта НЕ 5x9, не говоря уже о том, что шрифт может быть НЕ моноширинным. Нужно знать точный размер надписи. Без этого ВООБЩЕ никакого смысла нет работать над шрифтами в системе.
  • Зачем знать длинну выводимой строки?
    Eolite (имена файлов), HTMLv (страница), Liza (текст письма) для отображения текста использует моноширный шрифт, т.к. я знаю сколько максимально символов поместится в окно. С немоноширным я этого не могу знать. Хотя немоноширный по размеру больше и легче для чтения.
    Из хаоса в космос
  • SoUrcerer wrote:Перевожу с русского на русский. Большинство программ работает сейчас так:
    У нас размер буквы 5x9 точек, с интервалом 1 точку между буквами. У нас надпись в 5 букв, так что сделаем кнопку в 5*(5+1)+2 = 32 пикселя шириной и 9+2=11 пикселей высотой.
    Так вот это нихера не работает, когда размер шрифта НЕ 5x9, не говоря уже о том, что шрифт может быть НЕ моноширинным. Нужно знать точный размер надписи. Без этого ВООБЩЕ никакого смысла нет работать над шрифтами в системе.
    Так ты вообще-то говоришь о принципиально разных вещах. Ф.4 ориентирована на 2 существующих системных шрифта и все. Если уж на то пошло зачем вообще внедрять новые шрифты в ядро? Алексей Теплов замечательно продемонстрировал какой можно применить подход. Напоминаю, что Box_Lib тоже был изначально написан как демонстрация того что можно сделать по простому и это будет работать - что собственно и наблюдаем.

    Зачем все пихать в ядро? Да, даже если и пихать, то делать нужно полностью в другую функцию. Не надо оглядываться на существующую ф.4. В любом случае придется переделывать весь код программ использующих новые шрифты.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Заманчивость модификации функции 4 в том, что она используется везде. Я ради интереса модифицировал её для загрузки шрифтов 12x8 - хотя можно использовать и шрифты шириной до 16 пикселей по умолчанию.
    Image
    А ведь растровые шрифты чуть побольше по умолчанию, минимальные правки в софте - и счастье и радость на долгие годы. Даже в Windows по-прежнему растровые шрифты используются.
    (На картинке - пример, как прекрасно могут читаться растровые шрифты высотой в 12/16 пикселей).

    Векторные шрифты в наше время использовать можно только в одном случае - затирая фон (спасибо, оконная подсистема!). Если считывать область экрана, затем рисовать поверх, и записывать - получаются дикие тормоза. Если НЕ считывать эту область экрана, а рисовать без анти-алиасинга - мало того, что буквы выглядят так, будто их жевал лабрадор Кони; так еще придется вызывать стопятьсот раз функцию 1. Нет, реально, для небольшого окна с текстом придется раз 100500 или больше сделать int 0x40 только для вывода текста.
  • Вопрос разделился на два.

    1. По поводу функции: получение размера надписи в любом случае нужно реализовать - это даст возможность сделать часть программ более читабельными за счёт немоноширных шрифтов.

    2. Добавление новых шрифтов в ядро: спорный вопрос. С одной стороны - это возможность уже сейчас сделать программы Колибри более читабельными, с другой некрасивая реализация. Тут я за добавление, хотя и не буду особо настаивать. Хотя бы получение размера запилить.
    Из хаоса в космос
  • SoUrcerer
    Я уже рассматривал эту идею и даже высказывался на форуме в одной из тем, но реакция была нулевая.

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

    В общем случае это хорошо может сработать для моноширинных шрифтов. Для шрифтов с переменной шириной надо думать и ломать голову над наилучшим подходом.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • SysFn4, что самое паршивое, считает размеры этой самой выводимой строки. Это обидно. Считать-считает, а вывести некуда. Или затирать данные.
  • Who is online

    Users browsing this forum: No registered users and 4 guests