Вид для печати
по координатам x,y вычислить адрес верхнего байта знакоместа, (*) взять код символа, по коду символа и адресу фонта найти адрес первого из 8и байт графики символа. взять байт символа, положить в экранный адрес, перейти к следующему байту символа и адресу в экране на пиксел ниже, и так 8 раз. перейти к экранному адресу для следущего символа, повторять все это, начиная с (*), до тех пор, пока строка не закончится.Цитата:
Сообщение от mig'95
Построчно будет быстрей. Т.е. вначале верхняя строка всей строки, потом вторая и т.п.
Каждый символ в ПЗУ занимает 8 байт. Шрифт начинается с символа пробела. Его код - 32. Значит реальное начало шрифта, то есть символа с кодом 0, находится по адресу 15616-32*8. Чтобы получить адрес буквы "Н" в шрифте очевидно нужно сделать так: (15616-32*8)+(72*8). Следующие за этим адресом 8 байт и будут составляющие символа Н.Цитата:
Сообщение от mig'95
Что же касается TR-DOS, то контроллер Beta Disk устроен так, что при попытке перехода на определённую область адресов ПЗУ, в которую как раз и входит упомянутый адрес 15616, включается ПЗУ TR-DOS, которое заменяет собой стандартное ПЗУ с Бейсиком. А в ПЗУ TR-DOS по этим адресам находтся уже не шрифт, а код программы работы с дисководом.
Общий принцип такой:
Физический адрес видеопамяти:
Адрес=16384+2048*I+32*J+256*K+X,
где:
I=0...2 - номер трети экрана (сверху вниз);
J=0...7 - номер строки символов в трети (сверху вниз);
K=0...7 - номе линии (байта) в символе (сверху вниз);
X=0...31 - номер знакоместа в строке (слева направо).
интересно, это как? кто нить подскажет как такое могет быть?Цитата:
Построчно будет быстрей. Т.е. вначале верхняя строка всей строки, потом вторая и т.п.
Когда работаешь со стандартным набором - 8 бит в ширину и точность вывода 1 знакоместа разницу заметить трудно. Когда же делаешь точность печатания до пиксела + нестандартная длина, действительно удобнее..
я поясню, когда надо вывести чисто текст, длина которого от одной строки к другой меняется, да ещё эскейп последовательности, то почему то мне в голову приходит что вариант вывода построчно отпадает. т.е. если вести речи о драйвере, то вапще отпадает...
вобще то все проста как мандарин. если нет заморочек со шрифтом 42 в строке (тут придется юзать сдвиги), то,
1) считать код символа
2) найти его в таблице знакогенератора
3) перебросить в последнее свободное знакоместо
4) если не конец строки, то исх адрес +1
4a) если конец строки, то DOWN HL и HL-32
4b) если конец экрана, то scroll
грубо, но в целом так....
Добавлено через 2 минуты
чуть не забыл, HL подразумеваю адрес назначения доставки символа из знакогенератора
это немного не то...это не строчный вывод символов, а обычный посимовльный.Цитата:
перебросить в последнее свободное знакоместо
Легко + более рационально.Цитата:
Сообщение от Sayman
Сначала "печатаем" в линейный буфер, по коду CR перекидываем буфер на экран.
общий алгоритм такой:
есть переменные х,у,с (где с-цвет)
есть внутренняя переменная ф (флаг текущей операции)
есть процедура типа рст№10
есть буфер на 256 байт (8х32)
изначально переменные = 0
на вход процедуры последовательно начинаем пихать коды символов и управляющие, где, например: 13 - вывести буфер на экран, 14 - установить цвет (после этого кода идет код цвета), 15 - установить координаты (следом два байта координат).
надеюсь понятно выразил свои мысли ;)Код:Процедура Печать(код)
Если ф = 0 Тогда
Если код = 13 Тогда
ВывестиБуферНаЭкран()
ИначеЕсли код = 14 Тогда
ф = 1
ИначеЕсли код = 15 Тогда
ф = 2
Иначе
ПереписатьОбразСимволаВБуфер(код)
КонецЕсли
ИначеЕсли ф = 1 Тогда
с = код
ф = 0
ИначеЕсли ф = 2 Тогда
х = код
ф = 3
ИначеЕсли ф = 3 Тогда
у = код
ф = 0
Иначе
АбнормалПрограммТерминатион() // :-D
КонецЕсли
Возврат
КонецПроцедуры
Построчный вывод текста имеет смысл только в случае, если используется шрифт с числом символов в строке, не кратным 32 (обычно 42, 51 или 64). Данный способ позволяет ускорить работу процедуры за счет того, что можно исключить некоторые операции считывания из видеопамяти и/или логические операции (AND/OR). Но при выводе 32 символов в строке все эти проблемы все равно не возникают.
Построчный вывод, насколько мне известно, впервые был реализован Andrew Strikes Code в его музыкальном редакторе ASM.
Есть специфические случаи при которых построчный вывод практически единственный возможный. Например пропорциональная печать или печать в окнах.
А зачем юзать RST, если можно свою процедуру написать. Оно и быстрее и к переменным непривязано.
Я лично делал процедуру печати символов в окнах, работающую посимвольно, а не построчно. На 42 символа в строке. Не вижу также никаких проблем в том, чтобы посимвольно реализовать печать пропорциональным шрифтом (то есть когда ширина букв различается).Цитата:
Сообщение от James DiGreze
Может быть, если речь идет о выравнивании правого края - тогда да, только построчно. Потому что до того, как строка закончится, неизвестно, какие делать промежутки между словами. Но и тут не обязательно печатать сначала в буфер, а потом переносить изображение на экран. Это неэффективно. Лучше запоминать в буфере символы, а потом выводить их на экран за раз.
Я совершенно согласен с Barmaley_m. Вообще не понимаю, какой смысл так тормозить процедуру вывода. К примеру можно даже универсальную процедуру печати сделать - на любую ширину символа - по сути принцип работы будет тот же - берется строчка из экрана, смещается в нужную позицию символ и делается XOR/AND/XOR этого символа для двух или одного знакоместа. Нафига тут огород городить мне лично непонятно...
А что, промежутки между словами обязательно в реалтайме высчитывать?Цитата:
Сообщение от Barmaley_m
У меня в QHTS реализована посимвольная печать пропорциональным шрифтом. Сначала в буфер, ибо строки могут быть очень длинными, а дополнительные проверки на переполнение займут больше времени, нежели переброска. А насчет выравнивания- прекомпиляция со вставкой пробелов нужной длины (с точностью до пиксела) плюс автоматическая расстановка переносов:)
Если содержимое текста, который выводится, заранее неизвестно - то да, только в реалтайме.Цитата:
Сообщение от Vitamin
Если это текст из файла, и промежутки в нем заранее рассчитаны и сохранены вместе с текстом - тогда можно сэкономить.
Я имею в виду в реалтайма во время печатиЦитата:
Сообщение от Barmaley_m
Объясни подробнее, а то мне что-то непонятно, чем различаются мои и твои представления о "реалтайме".Цитата:
Сообщение от Vitamin
В какой момент ты расстанавливаешь пробелы для выравнивания? Во время печати или до?Цитата:
Сообщение от Barmaley_m
Я даже не представляю, как можно расставлять пробелы во время печати в случае выравнивания правого края.
Разумеется, до. Когда сформировалась полная строка, тогда только становится ясно, какой ширины должны быть пробелы.
Как говорится: на вкус и цвет...Цитата:
Сообщение от Barmaley_m
Ты лучше скажи, чем "твой" подход удобнее "моего", так сказать для конечного потребителя, т.е. печатающей программы? Явных преимуществ "твоего" я не вижу. Может быть быстродействие выше, но тоже не факт, особенно с учетом конечной отрисовки на экране. А в целом, оба подхода имеют право на жизнь, просто в каких-то применениях будет удобнее более простой "твой" подход, в более сложных случаях - "мой". Так что... не вижу смысла спорить. ;)
Вот я тоже хочу пропорциональную печать. Знаю у Витамина в QHT была. Но там какой-то аласм на трд-дискетке, чет я пока не хочу туда копаться.
А еще кто делал?
Первый раз узнал о пропорциональной печати из пакета программ "Instruments v 4.01", потом оттуда же и выдрал процедуру печати. Правда это было лет 15 назад - поэтому скорее всего та процедура не особо оптимизирована.Цитата:
Сообщение от Shadow Maker
Ну зачем такую древность, наверное кто-то писал уже что-то более адекватное за эти годы.
Делал лет 15 назад, но сейчас наверно только в бумажном виде сохранилось.
В принципе повторить не сложно, но нужно хотя бы в общих чертах представлять область применения.
Я не понял. Процедура для печати в любом месте экрана (можно по Y прибитому к знакоместам, по X в любом месте).
Была и есть. С обработкой (жирно/наклонно/подчеркивание/зачеркивание) и цветом. Весьма быстрая.Цитата:
Сообщение от Shadow Maker
А еще аж джве процедуры были в ZX-Ревю.
При чем здесь то, какой подход лучше? Я просто возразил тому, что твой подход является единственно возможным. Ты сказал ранее:Цитата:
Сообщение от James DiGreze
А на самом деле можно в обоих вышеприведенных случаях печатать и посимвольно.Цитата:
Сообщение от James DiGreze
Преимущества того или иного подхода - это отдельный вопрос, и я в его обсуждение пока не включался.
---------- Post added at 01:13 ---------- Previous post was at 01:09 ----------
А вообще предлагаю объявить конкурс на самую быструю процедуру печати шрифтами по 32, 42, 51 символов в строке, или пропорциональным шрифтом. Аналогично тому, как вылизывали процедуры для синуса в соответствующей теме. Ведь получились умопомрачительно гениальные варианты!