Всякое считал. По две точки эффективно получалось только для компактных процедур с возможностью ксорки, развернуть которые реально только лишь для одной оси, а иначе слишком уж разрастается. И возможно лучше с двух концов в середину.
Для set пока что получается всего перспективней пополам еще разбить сектора, тогда можно пользоваться тем, что сразу после ступеньки проверка не нужна, то есть, например, на косую zx-диагональ их будет нужно только 191, а ведь вместе с каждой выкинутой проверкой не только sub уходит, но и jp. Плюс удобно хвост дорисовывать без счётчика пикселей и без расстановки ловушек просто переходом на нужный адрес (правда, для самых пологих так не получится). И если не гнаться за рекордом, размер цикла такого сектора естественным образом сокращается почти вдвое, хоть и несколько замедляется.
Ты не думал о рисовании 2х точек за каждый тест? Линию Ву обычно рисуют от центральной точки и сразу в 2х направлениях. Как думаешь, можно с двумя наборами регистров сделать это эффективно?
Да это понятно, только на ступеньку, а не на точку. Думал, может, ты к этому еще чего-нибудь накрутил.
Сам сейчас склоняюсь уже к тому, что избавляться выгодней от лишних проверок, а не коррекции. Вопрос только в сокращении размера, но с коротким down это попроще, даже с таблицей. И забавный парадокс еще возникает: при увеличении наклона время отрисовки линии сокращается))
DDP даст -4 такта на точку, примерно как твой старый трюк, но без удвоения памяти.
Но чтобы это было выгодно на линиях хотя бы средней длины, нужно уложить вычисление коэффициента DDP в <100 тактов.
не потерял надежды сделать таблицу для DDP по данным dx и dy
а ты подсчитывал, сколько памяти тогда уйдёт под все циклы всех секторов и сколько цикл для диагонали будет работать?
сейчас тестирую альтернативный метод, позволяющий диагональ построить в цикле за ~8300 и к тому же перспективнее для коротких (правда, код опять разбухнет под 8кб)
парни, я, конечно, всё понимаю. у вас азарт и взаимопонимание с полуслова. но вы бы хоть выкладывали потом результат наработок-то для простых сметрных:)
А можно сделать ремарку «участвовать в компо, но не участвовать в голосовании»?
Для set пока что получается всего перспективней пополам еще разбить сектора, тогда можно пользоваться тем, что сразу после ступеньки проверка не нужна, то есть, например, на косую zx-диагональ их будет нужно только 191, а ведь вместе с каждой выкинутой проверкой не только sub уходит, но и jp. Плюс удобно хвост дорисовывать без счётчика пикселей и без расстановки ловушек просто переходом на нужный адрес (правда, для самых пологих так не получится). И если не гнаться за рекордом, размер цикла такого сектора естественным образом сокращается почти вдвое, хоть и несколько замедляется.
Сам сейчас склоняюсь уже к тому, что избавляться выгодней от лишних проверок, а не коррекции. Вопрос только в сокращении размера, но с коротким down это попроще, даже с таблицей. И забавный парадокс еще возникает: при увеличении наклона время отрисовки линии сокращается))
Но чтобы это было выгодно на линиях хотя бы средней длины, нужно уложить вычисление коэффициента DDP в <100 тактов.
сейчас тестирую альтернативный метод, позволяющий диагональ построить в цикле за ~8300 и к тому же перспективнее для коротких (правда, код опять разбухнет под 8кб)