Сообщение от
Grand
Обычно количество строк заранее неизвестно; его можно узнать, произведя предварительное форматирование текста. "К счастью", длина файла в TR-DOS ограничена 255-ю секторами, но в 48K длинный файл "перелопачивать" придется долго.
В
TR-DOS Navigator'е ничего этого не делается. Текст разбивается на строки в процессе вывода, какими бы длинными они не были (хоть весь текст одна строка!). Считаются именно байты, и результат не плохой.
Я собственно нигде и не спорю, что считать по байтам можно, тем более что это самый простой способ. Я просто утверждал, что единственный способ добиться плавности изменения счетчика - это считать именно строки, потому что скроллинг осуществляется именно по строкам (а не по байтам). Разбивка строк, разные разделители строк, скорость подсчета и прочее - все это решаемо. Например, посмотрите QC 3.11...
Сообщение от
Grand
Вот какая "процентная" формула там используется:
процентная_величина_прокру ченного_текста=
адрес_в_тексте_на_котором_о� �тановился_вывод/(
длина_текста_в_байтах/100)
На ассемблере это выглядит так:
Код:
LD BC,адрес_в_тексте_на_котором_остановился_вывод
CALL 11563;значение из BC на стек калькулятора (СК)
LD BC,длина_текста_в_байтах
CALL 11563;значение из BC на СК
RST 40
DB #A4;значение 10 на СК
DB #A4;значение 10 на СК
DB 4;умножение
DB 5;деление
DB 5;деление
DB 56;конец
CALL 11733;значение с СК в A с округлением его
;до ближайшего целого
Счетчик показывает величину прокрученного текста, и принудительное значение "100%" никогда не выставляется.
Я обычно использую собственную процедуру деления для этого расчета:
Код:
LD DE,55 ; текущая строка
PERCDIV LD BC,0 ; делитель (заранее высчитанный исходя из числа строк)
CALL DIVIS
[...]
DIVIS LD A,B
OR C
RET Z
LD A,#10
LD HL,0
DIVIS2 RL E,D,L,H
SBC HL,BC
JR NC,$+3
ADD HL,BC
CCF
DEC A
JR NZ,DIVIS2
RL E,D
RET
Сообщение от
Grand
Можно было бы пофиксить эти ошибки самому, и опубликовать только эту информацию.
Если кому нужно та дока - напишите мне и я ее вышлю. Просто в таком (необработанном) виде не хочется выкладывать на всеобщее обозрение.
Сообщение от
Grand
Если модули организованы как в Real Commander'е, то идея действительно плохая. А вот если сделать динамическую подгрузку оверлеев в зависимости от выполняемой функции, то идея хорошая. Недостаток - нужно держать в дисководе "системный" диск, но и он обходится, если оверлейный файл будет на RAM-диске (в 128K).
Проблема модулей (оверлеев, плагинов) на спектруме (не только касательно коммандеров) в том, что их пишет только автор программы и все. В том-же RC была изумительно документированная система работы с модулями, куча примеров, поддержка автора и тем не менее количество написанных модулей (сторонними авторами) совсем не впечатляет (несколько штук). За время, пока Pawel писал все эти доки, он возможно сам бы написал эти несколько модулей.