Цитата Сообщение от jerri Посмотреть сообщение
мне пока нечего туда пихать
да хоть код пихай

Цитата Сообщение от jerri Посмотреть сообщение
ну для горизонтальных и вертикальных линий и диагональных линий я и твое слегка ускорил
смысл был не в этом

Цитата Сообщение от jerri Посмотреть сообщение
у меня и так используются 4 подпрограммы - угол 0-45 45-90 слева направо и столько же справа налево
да при чём тут это? можно сделать ветки, можно код перед входом патчить, дело в другом
у меня в примере обе подветки - части ОДНОГО цикла, рисующего слева направо для dx>dy
они обе в цикле отрабатывают, но в разных пропорциях в зависимости от наклона отрезка
вычитание из ошибки разных чисел в разных подветках избавляет от коррекции ошибки:
Цитата Сообщение от jerri Посмотреть сообщение
add a,c
+ регистр еще при этом освобождает


Цитата Сообщение от jerri Посмотреть сообщение
расчеты сожрут всю выгоду от скорости.
какие расчёты? плюс одна проверка, переход, сдвиг
другое дело, что выгодных отрезков немного будет


Цитата Сообщение от jerri Посмотреть сообщение
текущая версия линии
всё еще 80-94 такта на пиксель (в цикле для лежачих отрезков)

Цитата Сообщение от jerri Посмотреть сообщение
дополнения, предложения есть?
второй недостаток:
Цитата Сообщение от jerri Посмотреть сообщение
rrca
ld e,a
jp nc,line_lrhb
inc h
line_lrhb
dec d
jp nz,line_lrh0
ret
вероятность выхода по завершению заведомо очень низкая
потому вместо jp выгоднее проверять на ноль условным ret
а для этого перенести декремент с проверкой в начало
и переход на него совместить с условным переходом после rrca
(который, напротив, происходит часто - в 7 из 8 случаев)
выигрыш - 5 тактов на каждый пиксель
у меня в примере уже так сделано