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