Вывод текста на экран жк

[AJScorp]

Мне для другой функции потребуется!

А что для Вашей функции не подходит?

У Вас же в любом случае в качестве параметра передается указатель на стринг, так какая разница откуда его брать - из массива или константой?

Писал под Ваш пост #33, "lcd_putstring(x,y,*mass_pamtr[i],WHITE,BLACK,0,1);" должно работать. Если нет - пишите как именно!

[spinach83]

Я со шрифтами дел не имел. Вашу тему почитал и чтото захотелось заняться. Только вопросов парочка мучает. Без углублений в код. Вопросы могу задать глупые, прошу не бить.
Для 8х8 шрифта например получается размер таблицы символов 2 килобайта? Это если 2 цвета (символ - фон) и число символов 256. А 12х12 - уже 4,5 килобайт? Насколько рационально организовать алгоритм "растягивания" шрифта, или всё же разумнее несколько шрифтов сделать для разных размеров?

[omercury]

Прямо на этом и рассмотрим. Сам шрифт "бесцветный" однобитовый. Цвет появляется при печати...

lcd_putstring(x,y,*mass_pamtr[i],WHITE,BLACK,0,1); 

Здесь "WHITE" цвет текста, "BLACK" цвет "бумаги".

[Uragan90]

Да это правильно подмечено! Текст потом окрашивается, при выводе- и делает это функция вывода текста...
В моей функции "0" это ротация (1-текст по вертикали пишется, 0-по горизонтали).
А последняя единичка это как раз "зум" текста.

[spinach83]

А последняя единичка это как раз "зум" текста.

А как насчёт дробного "зума"?

[SasaVitebsk]

Для 8х8 шрифта например получается размер таблицы символов 2 килобайта? Это если 2 цвета (символ - фон) и число символов 256. А 12х12 - уже 4,5 килобайт? Насколько рационально организовать алгоритм "растягивания" шрифта, или всё же разумнее несколько шрифтов сделать для разных размеров?

Обычно несколько ограничивают количество символов. Обычно коды от 0x20 и до 0xff. Хотя это и не принципиально меняет объём занимаемой памяти. Тут надо ещё отметить, что для быстрого пересчёта и удобства распаковки шрифт по горизонтали выравнивают на число точек кратных 8. Ну, то есть символ 6х8 будет реально храниться в памяти как 8х8 только значимых точек будет 6 из 8. Символ 14х14 реально будет занимать 16х14 или 2*14 байта. Таким образом таблица знакогенератора для такого шрифта будет равна 2*14*(256-32) = 6272 байта. Если у вас 10 шрифтов, то сами понимаете. ))
Здесь надо отметить ещё один момент. Реальная ширина символа "Ш" и символа "1" - разная. Появляется понятие моноширинных шрифтов и разноширинных. Если применять разноширинные шрифты, то можно сэкономить память путём прорисовки реального символа с указанием смещения этого символа от начала таблицы (что надо, так как символы в этом случае занимают разное количество байтов). При этом вы можете иметь даже неполную таблицу символов. Так, к примеру у меня есть шрифт 32, но в нём только цифры и некоторые спецсимволы.
Приведу пример.

//символ с кодом 0021
________,
________,
________,
________,
________,
___XX___,
__XXXX__,
__XXXX__,
___XX___,
___XX___,
___XX___,
___XX___,
________,
________,
________,
___XX___,
__XXXX__,
___XX___,
________,
________,
________,
________,


//символ с кодом 0024
________,________,
________,________,
________,________,
________,________,
______X_,________,
______X_,________,
____XXXX,X_______,
__X___X_,XX______,
__X___X_,XXX_____,
_XX___X_,_X______,
_XXXX_X_,________,
__XXXXXX,X_______,
____XXXX,XX______,
______X_,XXX_____,
__X___X_,_XX_____,
_XXX__X_,_X______,
__XX__X_,_X______,
____XXXX,________,
______X_,________,
______X_,________,
______X_,________,
________,________,

[MisterDi]

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

[SasaVitebsk]

Не факт. У меня 10 фонтов. 2 фиксированных 6х8 и 8х8. Остальные разноширинные. Приложение вместе с фонтами на AVR занимает 60к. Скажем фонт 16х16 наклонный занимает 8к прямой 7.
Если использовать TFT с разрешением от 320, то шрифт 8х8 вообще не разберёшь - очень мелкий будет. Так что - необходимость.
Хотя я сейчас работаю с индикатором 128х64 моно, и тоже сделал 3 шрифта 6х8, 8х8 и 13. Правда cortex.

[st_1]

Не факт. У меня 10 фонтов. 2 фиксированных 6х8 и 8х8. Остальные разноширинные. Приложение вместе с фонтами на AVR занимает 60к.

Что не факт???
Было написано...

в условиях системы с ограниченными вычислительными ресурсами лучше нескольких таблиц фиксированного размер пока не придумали.

Все телодвижения с извлечением, раскодировкой и транзакцией отнимают время, превосходящее время выталкивания на TFT... вот это факт... Если камень жирный настолько, что с него течёт сало, тогда конечно... Иначе... чем проще - тем быстрее...

Если использовать TFT с разрешением от 320, то шрифт 8х8 вообще не разберёшь - очень мелкий будет. Так что - необходимость.

Вот это да... есть такое...

[SasaVitebsk]

Что не факт???
Было написано...

Все телодвижения с извлечением, раскодировкой и транзакцией отнимают время, превосходящее время выталкивания на TFT... вот это факт... Если камень жирный настолько, что с него течёт сало, тогда конечно... Иначе... чем проще - тем быстрее...

Вот это и не факт. Понятно, что фонты до 8 точек по горизонтали включительно эффективнее обрабатывать прямой таблицей, а при большем - уже и не факт.
Простой пример. Возьмём фонт 11х13 Courier New. Прямая таблица на 224 символа займёт 224*2*13 = 5824 байта. Реально этот шрифт (с полной таблицей) занимает 3638 байт.
О каких телодвижениях с извлеченим и раскодировкой вы говорите - тоже непонятно. Есть указатель на начало таблицы по нему прямой пересчёт - указатель на нужный символ. Дальше абсолютно идентичный вывод.
То есть для прямого вывода для приведенного шрифта прога выглядит так:
ptr += ch*2*13;
Для разноширинного:
ptr1 = ptr + ch*3;
ptr = *ptr1++;
ptr |= (*ptr1++)‹‹8;
len_sym = *ptr1;

Совершенно очевидно, что это единицы % времени от вывода символа экран.