С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Честно говоря не очень вкурил что как и зачем сравнивается ) . Когда переделывал линзу для BGE, понадобилась прога для линии (встроенная не пришлась по душе )) ), правда скорость была не на первом месте по важности. Отыскал в нете алгоритм брезенхейма и состряпал что-то такое :
Может кому и сгодиться на что-нибудь. Прогу вывода точек не привожу, это не существенно, там разные варианты использовались.Код:LINE ; Bresenham's line algorithm ; de - first pixel , hl - last pixel .lineB call .plot ; вывод начальной точки .lineN push hl or a sbc hl,de ; проверяем на нулевую длину pop hl ret z .noequ ; de - y0x0 , hl - y1x1 ld a,l ld l,#1C ; inc e sub e ;dx x1-x0 jr nc, 1F neg inc l ; l=#1D - dec e : dx<0 (.Xstep) 1 ld b,a ; b = |x1-x0| (.dX) ld a,h ld h,#14 ; inc d sub d ; dy y1-y0 jr nc, 1F neg inc h ; h=#15 - dec d : dy<0 (.Ystep) 1 ld c,a ; c = |y1-y0| (.dY) cp b ; dx > dy ведём линию по X , dy > dx ведём линию по Y jr c,1F ld c,b ; меняем местами X и Y ld b,a ld a,h ld h,l ld l,a ld a,c 1 ld (.dERR),a ld a,b ld (.dM),a ld a,l ld (.Step1),a ld a,h ld (.Step2),a ld hl,0 ; err- проверка ; de - y0x0 .loopln push bc .Step1 inc e ;Xstep x=x+1 / x=x-1 / y=y+1 / y=y-1 ld bc,0 .dERR EQU $-2 ;dERR dY or dX add hl,bc ; err=err+dY or err+dX 1 ld bc,0 .dM EQU $-2 ; dX or dY bit 7,h jr nz,1F push hl add hl,hl or a sbc hl,bc pop hl jr c,1F ; if (err*2 < dM) goto 1F sbc hl,bc ; err = err-dM .Step2 inc d ;Ystep y=y+1 / y=y-1 / x=x+1 / x=x-1 1 call .plot pop bc djnz .loopln ret .plot ; вход de: e=x , d=y push hl,de,bc call PLOT_SNP ; вывод точки меняется от условий .plotADR EQU $-2 pop bc,de,hl ret
ну вот как-то так https://cloud.mail.ru/public/JBi8/MJJP72BQM
можно ставить бряки на call и сразу после (адреса даны в txt)
сейчас дб даже чуть быстрей чем на графике
Прихожу без разрешения, сею смерть и разрушение...
Для элиты бесполезно, 8кб перебор, выигрыш максимум процентов 5, тормозят там совсем не линии.
Думаю интересующиеся помнят что в элите используется dx/dy, для универсальности, ибо клиппинг еще то развлечение. На маленьких линиях это да, тормозит. Точно надо 2 линии сделать DDA и Брезенхэма, вот это ускорит ... наверное.
Почитал на хупе, тоже хотелось бы узнать, как это DDA без деления, дальше начался понос в теме, а в нем ковыряться уже не охота.
при переделке под 128k не так страшно
скорее "минимум процентов 5"
тормозят неслабо и линии, с одним близким кораблём тормозит сильнее, чем с 2-3 вдалеке
Но суть совсем в другом: эта процедура - именно для спектрумовской раскладки (больше для 128k демок, где переключают экраны, для векторных эффектов и анимаций). Элита же сначала долго рисует в буфер, потом в два захода чересстрочно перебрасывает в экран, да еще процедура ксорить должна уметь, и с учётом этого всего во-1 выгоднее изменить алгоритм, во-2 отдачи еще больше будет от смены структуры буфера на другую, при которой процедуры будут и быстрыми, и маленькими. Например, на всё ту же пресловутую раскладку в столбики (можно в два сегмента слева направо) - скорость переброски на zx-экран из которой лишь чуть медленней оригинальной цепочки ldi.
а там и не DDA а такой типа "сдвоенный Хорн": в каждой основной ветке-по-наклону есть две подветки, одна для движения по прямой (по вертикали/горизонтали) и вторая - для диагональных шагов. Между ними и мечется программный счётчик по результатам вычитания из ошибки, причём в каждой подветке вычитаем разные числа с разным типом перехода по переносу: для горизонтально-наклонных линий dy и (dy-dx), для вертикально-наклонных соответственно dx и (dx-dy). Что и позволяет избавиться от коррекции ошибки после ступеньки (а это, между прочим, 16 тактов на ступеньку в оригинальной процедуре spectrum expert) за счёт лишь одного предварительного вычитания. Но код сильно раздувается (в том числе еще из-за отдельной отрисовки хвоста, так как две ловушки уже ставить слишком накладно, да и с одной ловушкой в среднем медленней выходило бы; и еще кое-каких улучшений для коротких отрезков). Хотя в принципе можно этот же приём и без разворачивания использовать.
вот и весь секрет
Прихожу без разрешения, сею смерть и разрушение...
Последний раз редактировалось Totem; 24.11.2018 в 17:17.
Ты слыхал как грузится Flyshark ?! нет, совсем не тот, что на дискете...а Flyshark, тот самый блин Flyshark...тот ,что был когда то на кассете...
zx spectrum 48 issuse 6a, Ленинград-1, zx spectum 128 +2 grey,Пентагон-128, ZXM-Phoenix 5.02 ( assembly)
Возвращаясь к элите есть вполне конкретная задача. Требуется код который строит отрезок на экране x1 (-255,255), y1 (-255,255), x2 (-255,255), y2 (-255,255) с нулем в центре. На ксор можно забить, во первых этот код этого в принципе не сможет, а во вторых ну не видно на фоне солнца нифига и это нормально. Как к этой задаче адаптировать 10 байт этой быстрой линии без конкретного замедления результата мне пока не ясно. Вся эта этюдная софистика хороша максимум для дем к сожалению. Призывы просто поменять саму отрисовку не принимаются, 90% времени когда корабль на экране он состоит из дюжины небольших отрезков, ускорение в этом случае будет пару процентов, это того не стоит.
Я совсем не против быстрой демолинии, просто она лично мне не нужна. В любом случае классно что для интересующихся есть готовое решение. Как кстати она по скорости в сравнении с другими для отрезков в 1-40 пикселей?
- - - Добавлено - - -
И да конечно, говоря про -255,255 имеется ввиду отсечение невидимых частей.
нет, требуется код, который строит отрезок в буфере, а координаты - просто параметры
отсечение - отдельная задача до построения
ну так этот и не надо, сказал же сразу
в будущем, где космические корабли бороздят просторы 8 галактик, фильтров не придумали, тыщитаеш?
к тому же ксорка применяется не только у звезды, но еще для отрисовки эспов емнип; мож еще чего
нифига не понял про "10 байт"
так проблема именно в условных 10% оставшихся, "средняя температура" здесь не прокатит
тормоза могут длиться непрерывные десятки секунд, а не распределяются равномерно
и что еще хуже, тормоза не только графические, а от них страдает и управление
притом обычно в самые критические моменты ближнего боя
следственно, аргумент против смены отрисовки не принимается
повторю, ошибаешься с процентом в несколько раз
например, при отлёте глядя в задний экран время отрисовки станции = 80-90 тыщ тактов
пауза между отрисовками, то есть всё остальное время игрового кадра ~480 тыщ тактов
из которых надо сразу вычесть еще 90 тыщ на очистку и переброску буфера
минус неизвестно сколько на управление и анимацию приборной панели
минус время на вывод "пыли", вывод текста и другие вспомогательные задачи
уже выходит, что из общих временных затрат на объект
при сближении отрисовка может жрать >20% времени
а ведь её реально ускорить вдвое (с тем же размером)
- - - Добавлено - - -
можешь сам замерить, в основном зависит от постоянных накладных расходов на вход
(~330 тактов, что всё же меньше, чем у двух других вариантов с графика)
меньше - от положения "хвоста"; вход, наверно, можно слегка поджать
для анимаций можно сократить проверки, добавить поддержку ломаных итд
Прихожу без разрешения, сею смерть и разрушение...
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)