Всякое считал. По две точки эффективно получалось только для компактных процедур с возможностью ксорки, развернуть которые реально только лишь для одной оси, а иначе слишком уж разрастается. И возможно лучше с двух концов в середину.

Для set пока что получается всего перспективней пополам еще разбить сектора, тогда можно пользоваться тем, что сразу после ступеньки проверка не нужна, то есть, например, на косую zx-диагональ их будет нужно только 191, а ведь вместе с каждой выкинутой проверкой не только sub уходит, но и jp. Плюс удобно хвост дорисовывать без счётчика пикселей и без расстановки ловушек просто переходом на нужный адрес (правда, для самых пологих так не получится). И если не гнаться за рекордом, размер цикла такого сектора естественным образом сокращается почти вдвое, хоть и несколько замедляется.
Ты не думал о рисовании 2х точек за каждый тест? Линию Ву обычно рисуют от центральной точки и сразу в 2х направлениях. Как думаешь, можно с двумя наборами регистров сделать это эффективно?
Да это понятно, только на ступеньку, а не на точку. Думал, может, ты к этому еще чего-нибудь накрутил.

Сам сейчас склоняюсь уже к тому, что избавляться выгодней от лишних проверок, а не коррекции. Вопрос только в сокращении размера, но с коротким down это попроще, даже с таблицей. И забавный парадокс еще возникает: при увеличении наклона время отрисовки линии сокращается))
DDP даст -4 такта на точку, примерно как твой старый трюк, но без удвоения памяти.
Но чтобы это было выгодно на линиях хотя бы средней длины, нужно уложить вычисление коэффициента DDP в <100 тактов.
  • avatar nyuk
  • 1
Tiny MP3 меньше часа. Можно и потерпеть :-)
  • avatar TmK
  • 0
надо ехать ;)
  • avatar sq
  • 0
А конкурсы, конкурсы-то ты видел? Тини мп3 убрать, и вообще будет идеальный набор!
Хороший, удобный выбор даты посреди майских праздников. Вполне можно успеть приехать/уехать без отпуска и отгулов.
не потерял надежды сделать таблицу для DDP по данным dx и dy
а ты подсчитывал, сколько памяти тогда уйдёт под все циклы всех секторов и сколько цикл для диагонали будет работать?
сейчас тестирую альтернативный метод, позволяющий диагональ построить в цикле за ~8300 и к тому же перспективнее для коротких (правда, код опять разбухнет под 8кб)
Отлично!
  • avatar sq
  • 0
Олежа, а где там пакер-плеер-то? )
Так у обоих недоделки. У меня так вообще одни только черновики — не класть же их.
прошлую выкладывал на zxpk демкой в снапе (а с сырцами правильно не торопился, выходит, раз переделывать))
  • avatar bfox
  • 0
парни, я, конечно, всё понимаю. у вас азарт и взаимопонимание с полуслова. но вы бы хоть выкладывали потом результат наработок-то для простых сметрных:)
Вот, теперь даже я дочитал до конца :)))
так там и нет в ступеньках djnz:
Для развёрнутых процедур DOWN_HL будет соответственно «inc h» или «add sp:ld h,(hl)»
В длинной ты всегда знаешь где именно в знакоместе ты находишься, поэтому там DJNZ — это, наоборот, провал.
почему? и длинную тоже, в цикле на диагональ теперь уходит почти ровно 9000 тактов, на 500+ меньше прошлой
По сути, ты ускорил не длинную линию а короткую. У меня короткая линия до 30 пикселов обгоняет линию эксперта, а с этим трюком можно наверное и до 35-40 дотянуть.
Эх, это не та табличка! :) Я не потерял надежды сделать таблицу для DDP по данным dx и dy.

Ну т.е. конечно в компактном случае повеселее, и сама возможность гнать сразу две точки…
Ммм..., это конечно далеко от того, где я думал, но тоже довольно сексуально выглядит.