О рисовании прямых

[Higgins]

Ну значит только первую часть- вертикально ориентированные.

Да, постараюсь сделать.

Какой же я невнимательный. Очевидно фрагменты - это и есть точки)

В общем да, длина линии в точках разбивается на горизонтальные фрагменты соответственно протяженности линии по вертикали (DY). Для любой линии количество фрагментов равно (DY + 1). Длина фрагментов колеблется между значениями [DX/DY] и [DX/DY + 1]. И все линии, по которым составлены графики длиной 256 точек независимо от количества фрагментов, на которые они разбиты. Поэтому для линии с заданной геометрией можно легко оценить количество тактов на точку. Значит, и для любого набора линий с заданной геометрией можно сделать такую оценку.

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

В этом один из главных принципов, на которых стоит модель процедуры рисования линии, для которой этот тест собственно и придуман.

[Higgins]

В первом сообщении добавлены графики для вертикально ориентированных.

[Vitamin]

Очень интересная картина для SE: видно, что меняется тангенс, но резкого скачка нет.

[Higgins]

Очень интересная картина для SE: видно, что меняется тангенс, но резкого скачка нет.

Да, в купе с подозрительно гладкой кривой в целом дает пищу для подозрений в том, что есть еще куда стремиться. Все-таки такую пилу логичнее ожидать внизу графика, а не наверху.

[Lethargeek]

Да, в купе с подозрительно гладкой кривой в целом дает пищу для подозрений в том, что есть еще куда стремиться. Все-таки такую пилу логичнее ожидать внизу графика, а не наверху.

У меня когда-то были мысли сыграть на периодичности
Чтобы чем длиннее, тем больше выигрыш

[alone]

Типичная линия в более-менее культурном проволочном 3D будет не 256 пикселей, а порядка 10. Этот случай и надо оптимизировать.

[Advertiser]

[Lethargeek]

Типичная линия в более-менее культурном проволочном 3D будет не 256 пикселей, а порядка 10. Этот случай и надо оптимизировать.

Нет на Спеке типичных линий. Как всегда придется процедуру подгонять под задачу.

10 пикселей это очень мало, разве что объект довольно далеко.
И зачем оптимизировать его отрисовку, если тормоза начнутся ближе?

[Higgins]

У меня когда-то были мысли сыграть на периодичности
Чтобы чем длиннее, тем больше выигрыш

Вообще, любая прямая в растре будет регулярной 1) на уровне точек, которые складываются в прогоны и 2) на уровне прогонов, которые точно так же регулярно складываются в, скажем так, части линии.

О прогонах уже говорили. А вот на эти части можно посмотреть так. Пусть требуется построить в растре некоторую горизонтально ориентированную прямую с [DX/DY] = 1. Теперь представим себе в том же растре соответствующую диагональ (с соотношением DX/DY точно равным единице, т.е. DX = DY). Так вот искомую прямую можно получить заменив в диагонали часть точек на горизонтальные прогоны длиной в две точки (помним, что прогоны в такой линии у нас могут быть только длиной в одну или две точки). Таким образом каждый такой прогон в две точки будет увеличивать DX диагонали на одну точку. То есть для искомой прямой нужно добавить (DX-DY) таких прогонов. При этом, чтобы прямая была похожа на прямую, все эти длиные прогоны должны быть расположены, насколько позволяет шаг растра, на одинаковом расстоянии. Сбалансированная линия, в терминах таких частей линий, означает одинаковое, опять же, насколько это позволяет растр, отстояние длинных прогонов от концов линии. Так вот последовательность коротких прогонов в купе с одним длинным дает одну часть линии.

Арифметика получается такая. Всего в горизонтально ориентированной линии с геометрией R = [DX/DY] = 1 будет N = (DX - DY) частей. Размер части по вертикали будет равен PY = (DY / N). Если отношение PY нецелое, тогда линия будет составлена из частей двух размеров, а именно [PY] и [PY] + 1. Большая часть (размером [PY] + 1) -- это малая часть плюс один короткий прогон. Размер части по горизонтали в любом случае будет равен PX = PY + 1.

Типичная линия в более-менее культурном проволочном 3D будет не 256 пикселей, а порядка 10. Этот случай и надо оптимизировать.

Даже если так, что специального может сделать процедура рисования прямой для линий из десяти точек?

[Lethargeek]

Не, я не о том. Вот смотри, периодичность может возникнуть по трем параметрам:
- по укладыванию в знакоместную строку по вертикали
- по укладыванию в байт по горизонтали
- по длине фрагментов

Может даже по всем трем сразу, причем порядок вложенности любой
Так что сначала выбираем подходящую процедуру

Фокус в том, чтобы честно отрисовать только один период
одновременно запоминая последовательность операций
(конкретно как это сделать - вопрос отдельный)
чтобы потом по порядку печатать байты-фрагменты
без сопутствующих расчетов и проверок

[alone]

Нет на Спеке типичных линий. Как всегда придется процедуру подгонять под задачу.

10 пикселей это очень мало, разве что объект довольно далеко.
И зачем оптимизировать его отрисовку, если тормоза начнутся ближе?

10 пикселей - нормально для объекта приличной сложности (я не говорю про всякий примитив типа кубика или там тетраэдра).
Чем ближе, тем больше деталей должно показываться на объекте, соответственно больше линий, но всё равно мелких.
Ещё надо оптимизировать отсечение линий по границам экрана.