я просто хочу протестировать наколенную реализацию вытесняющей многопоточности и для этого нужно выполнить требования выше — чтобы два потока могли исполнять один и тот же код синхронно. а всё что гуглится либо для скорости оптимизировано до нарушающих многопоточные принципы оптимизаций либо не гуглится вовсе.

давно делал и компактные варианты, можно поискать в закромах

P.S. пункт (г) не означает что режим записи должен быть входным параметром в алгоритм — можно добиваться этого просто модификацией кода или созданием трёх разных процедур. главное сама принципиальная возможность — почему это вообще важно, потому что уже упомянутый fast divide & conquer line часто пишет пиксель по два раза и поэтому на инвертированную линию без серьёзных модификаций просто не способен. тут важная сама принципиальная способность делать это точечными изменениями кода.

Господа, тут такое оживлённое было обусждение сверхбыстрого алгоритма рисования линии, что осмелюсь тут спросить: ни у кого не завалялся исходный код рисующий линию по брезенхему удовлетворяющий следующим условиям:
а) рисует линию от начала до конца (а не легко гуглящийся fast divide & conquer)
б) не использует глобальных переменных кроме констант типа предрассчитанных таблиц
в) на самом деле то же самое что и (б) — не использует самомодификацию кода
г) способен писать как 0 так и 1 так и инверсию
д) легко скопипастить в другую программу
Суперскорость не особо нужна, думал легко найду, но ни на русском ни на английском гугл как ни мучаю — ничего подходящего не вижу…

В статье упоминается, что Zilog сперва хотела продвигать другую архитектуру — дело в том, что в 1979 (всего через год после выхода в продажу Intel 8086) году фирма выпускает еще один процессор Z8000 уже несовместимый с Z80 с продвинутой 16–битной архитектурой: 16 регистров общего назначения, множество режимов адресации и до 8 Мб сегментированной памяти. Интересно, что когда IBM захотела покусится на нишу персональных компьютеров и создала IBM PC Z8000 уже был на рынке и гипотетически мог быть выбран в качестве сердца новой машины, но IBM выбрала процессор Intel и если верить википедии:

Федерико Фаджин, тогда исполнительный директор Zilog, считает, что причиной тому было то, что владельцем Zilog преимущественно был один инвестор — Exxon Enterprises, фирма которая имела амбиции конкурировать с IBM. Поэтому когда IBM начала проект PC она рассматривала Zilog как конкурента и выбрала Intel 8088, а не Z8000 потому что не видела в Intel конкурента на рынке компьютеров.

Позднее Z8000 обзаводится 32–битным наследником Z80000, но это уже не помогает — звезда Zilog на рынке персональных компьютеров закатилась окончательно и сейчас фирма занимается микроконтроллерами.
Интересно каким был бы современный мир домашних компьютеров если тогда давным давно IBM сделал бы выбор в пользу Z8000. :)

Естественно, что никто в здравом уме не будет показывать демо вместе с Tiny MP3. Все-таки новое качественное демо на спектруме не часто случается. И если это случится, наоборот нужно как-то это акцентировать. Как-то наиболее выгодно показать.

Я хочу донести мысль, что внеконкурсная работа не имеет никакого отношение к конкурсной программе. На пати вне конкурса проходят самые разные движухи: семинары, выступления музыкантов, капоэйра в конце концов. Но никто же не требует, чтобы его капоэйра была обозначена в правилах конкурсов.

Хочешь свою капоэйру? Не вопрос. Предлагай, согласуем, как это лучше показать. Но просить внести дополнения в правила конкурсов по своей капоэйре на мой взгляд дико.

с нюком не все могут быть иногда согласны но нюк всегда прав :)

Андрей, ну в общем конечно понятно, что Денис тебя провоцирует, и что сознательное смешивание маринования с внеконкурсом — как бы аргумент дохлый. Но, тем не менее, ответ немного странный. Поясни пожалуйста, из каких примерно соображений внеконкурсная работа может попасть в Tiny MP3? Потому что у меня в голове не укладывается. ОК, кто-то может захотеть хакнуть правила и заслать вне конкурса нечто неудобоваримое, что не вписывается в демокомпо? Но почему тогда не бороться с этом преселектом? Совсем чётко: какой вообще может быть резон держать внеконкурсные работы вот прямо настолько второсортными?

Я.

А кто будет отвечать за показ?

Ну т.е. демо-маринады можно показывать в одном компо с демами, а те что вне компо «не гарантирую». Понятно, спасибо

Можно.

Я не могу гарантировать, что работа не будет показана первой. Или девятой. Или во время Tiny MP3 compo. Это уж как решит человек, отвечающий за показ.

Но показана будет. Голосования не будет. Места не будет. В паке работ будет. Или не будет, как решит автор.

Можно снять на видео, как ты публично отказываешься от участия в компо и голосовании.
И выставить его в вайлд!

Ничем

А чем это будет от внеконкурсного показа отличаться?

Добавлена ремарка, позволяющая автору не публиковать работу после пати (marinade™)

А можно сделать ремарку «участвовать в компо, но не участвовать в голосовании»?

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

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

Ты не думал о рисовании 2х точек за каждый тест? Линию Ву обычно рисуют от центральной точки и сразу в 2х направлениях. Как думаешь, можно с двумя наборами регистров сделать это эффективно?

Да это понятно, только на ступеньку, а не на точку. Думал, может, ты к этому еще чего-нибудь накрутил.

Сам сейчас склоняюсь уже к тому, что избавляться выгодней от лишних проверок, а не коррекции. Вопрос только в сокращении размера, но с коротким down это попроще, даже с таблицей. И забавный парадокс еще возникает: при увеличении наклона время отрисовки линии сокращается))

DDP даст -4 такта на точку, примерно как твой старый трюк, но без удвоения памяти.
Но чтобы это было выгодно на линиях хотя бы средней длины, нужно уложить вычисление коэффициента DDP в <100 тактов.