Это правда что в Spectrum Expert (1, 2) была самая быстрая процедура рисования линии?
Если у кого-нибудь есть быстрее, то поделитесь кодом плиз.
(естественно, что установка точки включается в рисование линии)
Вид для печати
Это правда что в Spectrum Expert (1, 2) была самая быстрая процедура рисования линии?
Если у кого-нибудь есть быстрее, то поделитесь кодом плиз.
(естественно, что установка точки включается в рисование линии)
Самая быстрая процедура линии написана Alex Raider'ом. Исходники лежат в архиве ZX Open Source http://opensourcezx.untergrund.net/e..._misc_src.htmlЦитата:
Сообщение от Sinus
Кстати вот, линии Alex Raider'a и которая в Spectrum Expert'e по скорости и алгоритму работа почти одинаковые (около 9 линий во фрейм), однако та которая в Expert-e меньше размером.
ээээ! ты что, в экспертовской генерится огромная процедура отрисовки! а у рэйдера нет. правда, у него чуть медленнее, самую малость.
ну, учитывая что я час назад сделал две тестовые проги и посчитал их размер (размер самих процедур отрисовки и генерации табличек + размер данных которые эти генерилки генерят) + сделал приблизительный замер скорости (по бордюру), то я уверен в том что говорю.
могу отправить SCL файл с этим всем добром
ELPH - ну не такая уж и огромная...
вопрос по теме, каких линий?Цитата:
Сообщение от Sinus
У нас КИМ написал процедуру, которая, если мне память не изменяет, рисовала 7,5 диагоналей спектрума во фрейм...
Нашел процедуру авторства Unwinder. Юзаю сам. Весьма быстро и хорошо. Требует 4кб памяти под таблицу и вызов MAK_PLO перед рисованием (заполнение таблицы)
Код:;-----------------------------------------
LINE_R LD (STACK+1),SP ;ПРОЦЕДУРА РИСОВАНИЯ ЛИНИИ
DI
LD A,L ;В HL И DE НАХОДЯТСЯ КООРДИНАТЫ ТОЧЕК
CP E
JR NC,NO_EXCH
EX DE,HL
LD A,L
NO_EXCH: SUB E
LD C,A
LD A,H
SUB D
JR C,DOWN_UP
UP_DOWN: LD B,A ;РИСУЕМ ЛИНИЮ СВЕРХУ ВНИЗ
LD H,58 ;LIN_ARR/512+2
LD L,D
JP MISS
;-----------------------------------------
DOWN_UP: NEG ;РИСУЕМ ЛИНИЮ СНИЗУ ВВЕРХ
LD B,A
LD H,59 ;LIN_ARR/512+3
LD A,191
SUB D
LD L,A
MISS: ADD HL,HL
LD SP,HL
LD H,'LIN_ARR
LD L,D
LD A,(HL)
INC H
LD D,(HL)
INC H
LD L,E
ADD A,(HL)
LD E,A
INC H
LD L,(HL)
EX DE,HL
LD A,B
CP C
JR NC,VERTIC
HORIZON: DEFB 221 ;ГОРИЗОНТАЛЬНАЯ ЛИНИЯ (DX>DY)
LD L,A
DEFB 221
LD H,C
LD B,C
LD C,E
LD A,B
SRL A
JR Z,END_LIN
EX AF,AF'
HORIZ0: LD A,(HL)
OR C
LD (HL),A
EX AF,AF'
DEFB 221
SUB L
JR NC,HORIZ2
DEFB 221
ADD A,H
POP DE
ADD HL,DE
HORIZ2: EX AF,AF'
RRC C
JR NC,HORIZ1
INC L
HORIZ1: DJNZ HORIZ0
END_LIN: LD A,(HL)
OR C
LD (HL),A
STACK: LD SP,0
EI
RET
;-----------------------------------------
VERTIC: DEFB 221 ;ВЕРТИКАЛЬНАЯ ЛИНИЯ (DY>DX)
LD H,A
DEFB 221
LD L,C
LD C,E
SRL A
JR Z,END_LIN
EX AF,AF'
VERT0: LD A,(HL)
OR C
LD (HL),A
EX AF,AF'
DEFB 221
SUB L
JR NC,VERT1
DEFB 221
ADD A,H
RRC C
JR NC,VERT1
INC L
VERT1: EX AF,AF'
POP DE
ADD HL,DE
DJNZ VERT0
JP END_LIN
;-----------------------------------------
DEFB " * MEGA FAST LINE V1.0 BY UNWINDER'95
;-----------------------------------------
NEXT_DE: INC D
LD A,D
AND 7
RET NZ
LD A,E
ADD A,32
LD E,A
RET C
LD A,D
SUB 8
LD D,A
RET
;-----------------------------------------
MAK_PLO: LD HL,LIN_ARR
LD DE,16384+32768
LD B,192
MAK_PL0: LD (HL),E
INC H
LD (HL),D
DEC H
INC L
CALL NEXT_DE
DJNZ MAK_PL0
LD HL,LIN_ARR+1023
LD A,1
MAK_PL1: LD (HL),A
RLCA
DEC L
DJNZ MAK_PL1
DEC H
LD A,31
MAK_PL2: LD B,8
MAK_PL3: LD (HL),A
DEC L
DJNZ MAK_PL3
DEC A
JP P,MAK_PL2
MAK_LIN: LD IX,LIN_ARR+1024
LD HL,16384+32768
LD B,191
MAK_LI0: LD E,L
LD D,H
EX DE,HL
CALL NEXT_DE
EX DE,HL
AND A
SBC HL,DE
LD (IX),L
INC IX
LD (IX),H
INC IX
ADD HL,DE
DJNZ MAK_LI0
LD IX,LIN_ARR+1024+512
LD HL,22528-31+32768
LD B,191
MAK_LI1: LD E,L
LD D,H
CALL PREV_HL
AND A
SBC HL,DE
LD (IX),L
INC IX
LD (IX),H
INC IX
ADD HL,DE
DJNZ MAK_LI1
RET
;-----------------------------------------
PREV_HL: DEC H
LD A,H
AND 7
CP 7
RET NZ
LD A,L
SUB 32
LD L,A
RET C
LD A,H
ADD A,8
LD H,A
RET
;-----------------------------------------
LIN_ARR EQU 32768-4096
himik, рандомных :) в начале фрейма рандомайзер инитится одинаковым числом, чтоб линии не прыгали.
Vitamin, сенькс, вставлю в тестилку и посмотрю по скорости.
дык это на мой взгляд не корректный тест... В диагоналях то точнее будет, ведь она:Цитата:
Сообщение от Sinus
1. самая длинная линия
2. самая сложная в рисовании
Добавлено через 3 минуты
ой сдается мне, что по нынешним меркам это мега тормозная процедура...Цитата:
Сообщение от Vitamin
"весьма быстро" относительно чего?
Давайте приводить тесты в у.е. :) т.е. в диагоналях. Сколько диагоналей за фрейм успевает нарисовать.
Также можно приводить пример вертикали, горизонтали и т.п.
На такие мысли навел год в строке копирайта?Цитата:
Сообщение от himik
Я вот жду результатов тестирования тов. Sinus
Не очень верноЦитата:
Сообщение от himik
Оффтоп, но может кто забыл какие глюки были в 3dMark'03? Там использовался простой подгон под тест и в результате бенчмарк вырастал за ни за что в 1,5 раза %)
Это я к чему: если в процедуре прорисовки будет отдельная процедура которая рисует диагональные линии то такой способ вызовет эээ не совсем адекватную оценку. Там что Sinus правильно говорит, надо делать рандомный тест. Я ещё более объективно быть может использовать такой тест - в течение скажем секунды рандомные линии, потом в течении секунды вертикали, потом горизонтали, потом диагонали. В конце выводить результаты по всем четырём тестам, в принципе вполне возможно рисовать вертикальные/горизонтальные линии отдельной процедурой (так же как диагонали на 45 градусов и/или на весь экран). Принципиально тест не изменится, а вот результат станет более точным.
ну я выше где-то и написал, что давайте проведем тесты по нескольким критериям, вертикаль, горизонталь, диагональ, ну и рандом.
Просто интересно узнать результат.
Додумал сейчас... надо бы ещё проверять качество линии %) мало ли какая ушлебанская процедура попадётся :-D она быть может просто будет делать RET зато будет как быстро работать!!! :-)
хотя может быть и логичнее было-бы взять для основы теста некую готовую таблицу координат, в которой уже прорисованы несколько готовых линий, используя все направления и длины. Вот тогда и можно просто вычеслить, какая процедура рисования обрабатывает это быстрее, т.е. занимает меньше времени на вывод полной картинки из координат.
ИМХО логичнее, и рэндомность исключаем.
Вот ещё что подумал, там ведь дробночисленная арифметика используется - я имею в виду приращения по X и по Y для прорисовки линий. В таболичном методе, которыми очевидно пользуются быстрые процедуры очевидно это арифметика присутствует, хоть и в неявном виде. И в зависимости от того как работает счётчик переполнения будет меняться алгоритм увеличения координаты по X и по Y - это может быть округление в сторону меньшего целого, в сторону большего целого и классическое округление (от 0,5). В зависимости от этого форма линии в целом может меняться!!!
Потому имхо если уж делать тест, то самой точной должна быть признана линия, которая использует последний критерий переполнения (классическое округление). И ещё, встречались некоторые процедуры, которые в целях увеличения быстродействия рисовали линии с пустыми местами (т.е. линия имела разрыв, как пунктир).
ну, я думаю тестировать необходимо полноценные процедуры, которые рисуют сплошные линии :)
еще корректнее наверно будет считать не сколько линий за фрейм - а рисовать скажем с сотню линий и считать количество затраченных фреймов...
Просто надо "среднее количество тактов на пиксель в основном цикле" проинтегрировать по всем возможным углам :v2_finge:Цитата:
Сообщение от himik
ну есть стандартные критерии оценки производительности графической подсистемы %) например в килопикселях или в мегалиниях :-) шутко :-) количество линий - вот главная оценка.
Оценивать естественно надо не за фрейм а за больший промежуток времени
кроме того, я уже выше написал что на самом деле две линии нарисованные разными процедурами могут весьма отличаться, потому обязательно надо проверять качество.
Достаточно поменять начальное приращение, проверки в цикле все равно выгоднее делать по переполнению.Цитата:
Сообщение от GriV
ПИКСЕЛЕЙ!! :mad: Что такое "количество линий"? Что такое "линия"?Цитата:
Сообщение от GriV
Хотя маньяки могут начать подсчитывать прямо сейчас: на спектрумовском экране возможны всего-то (256x192)*(256x192)=2415919104 различных комбинаций координат концов отрезка... выбрали критерий округления - и вперед, с песней! :v2_laugh: Особо продвинутые могут добавить предварительные проверки для отбрасывания симметричных и сдвинутых отрезков. :v2_lol:
В два раза больше. Ибо от перемены координат отрезка различаются такты на рисование линии (проверка-перестановка требует тактов)Цитата:
Сообщение от Lethargeek
Не "в два раза больше", а именно столько, сколько я написал, как раз с учетом проверки-перестановки (а то было бы в два раза меньше).Цитата:
Сообщение от Vitamin
А, точно. Каждый конец линии же по всему экрану проходит. Ну все равно дофига. Даже если под эмулем под супертурбой мерять много времени уйдетЦитата:
Сообщение от Lethargeek
Дык я предлагал исключительно для маньяков. ;)Цитата:
Сообщение от Vitamin
Хотя, если "эмуль" ничего, кроме Z80, не делает...
сферические кони в вакууме.
Что именно?Цитата:
Сообщение от moroz1999
Единица измерения бенчмарка - типа производительность 250 вакумных лошадок :DЦитата:
Сообщение от Lethargeek
А что не так? Единица измерения - количество тактов Z80 на выполнение теста. Причем выборка для теста даже не просто "репрезентативная", а вообще стопроцентная. :pЦитата:
Сообщение от heroy
В принципе количество отрезков даже в полном тесте можно сократить до разумных пределов - сдвинуть один из концов в ноль и просчитать в каждом квадранте (итого 256x192x4), причем весовой коэффициент - площадь прямоугольника с диагональю от конца отрезка до дальнего угла квадранта. Для полной точности еще внести коррективы на пересечение четного либо нечетного количества знакомест по горизонтали (x2) и вертикали (x2) с возможным пересечением одного или обоих сегментов (x1...x3), с соотв-ей разбивкой весов. Итого понадобится менее 2,4 млн отрезков. ;)
про сферических коней я упомянул потому, что на 99% уверен, что после двух страниц обсуждений методик тестирования до самого тестирования дело так и не дойдет :)
угу.
Дарк настрочил процедуру (которая в эксперте), но у него небыло времени ее вылизать. Там можно было еще тактов отбить чутка.
Тестить бесполезно т.к. линии до 45 градусов и после 45 градусов рисуются разными процедурками и жрут разное число тактов. Надо брать ту, которая лучше и проще в прогу страивается и ставить. А так если по неделе рассуждать, никакого кода так и не будет :)
Почему "бесполезно"? ;) Ежу понятно, что "разные процедурки" (вообще-то это разные ветки одной процедуры), ну дык интересует средневзвешенная эффективность в общем случае. Которая однозначно определяется тестом.Цитата:
Сообщение от research
давайте еще на 4 страницы минимум устроим выяснение критериев тестирования объективного теста, а так же теста при условиях приближенных к реальным ;-)
Поделитесь,пожалуйста, асмовской процедурой рисования линии.
---------- Post added at 16:14 ---------- Previous post was at 14:46 ----------
Всё, спасибо за внимание.
Нашёл тут http://zxpress.ru/article.php?id=7388
---------- Post added at 16:16 ---------- Previous post was at 16:14 ----------
Ещё интересен момент, как векторную анимацию обновлять без мерцания ?
---------- Post added at 16:28 ---------- Previous post was at 16:16 ----------
Хммм.... та процедура по скорости мало чем отличается от бэйсикового DRAW
Используй буфер. Что замедлит работу еще больше... на 128-к с этим не так печально.Цитата:
Сообщение от ALKO
Я так полагаю нужно изменить процедуру GET_ADRЦитата:
Сообщение от newart
LD A,#BF - это типа старший разряд указателя на адрес ?
Что конкретно изменить, что б отрисовывало например по адресу 40000 ?
Адрес делай кратным 256.Цитата:
Сообщение от ALKO
Чё-та она у меня не работает, почему-то таблицу заполняет на 1917 байт только (число-то ого-го какое, Великий Октябрь!) вместо 4к. Что я не так сделал? (см.файл)Цитата:
Сообщение от Vitamin
Зачем тебе такие адреса?Цитата:
Сообщение от Andrew771
LD DE,16384+32768