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

[GriV]

2Alone> можно подробнее, что делается? Не понял с набегу.

[alone]

Есть координаты в объекте: -32..31 каждая. В условном масштабе.
Есть координаты реальные: -128..127 каждая. В другом условном масштабе.
Есть оси OX (127,0,0), OY (0,127,0), OZ (0,0,127). В начале кадра мы их вертим и получаем координаты OXx,OXy,OXz, OYx,OYy,OYz, OZx,OZy,OZz.

Потом считаем вершины по три умножения на координату, как показано выше.

[GriV]

А почему ты говоришь про условный масштаб? Или таблица умножения разной может быть?

[alone]

Разумеется!

[GriV]

Т.е. грубость обсчёта кроется только в неравномерности перехода более дальней плоскости обсчёта к более близкой (условном масштабе)? Чем больше страниц на обсчёт, тем качественней? Или иначе?

[alone]

Грубость обсчёта заключается в том, что у суммы трёх чисел с ошибкой +-0.5 пикс. получается ошибка +-1.5 пикс. И число страниц на это не влияет.

[Raider]

Прикольно.
А у линии от Expert большие таблицы или строится в памяти код?

DrBars невольно ввел в заблуждение. У меня не самая быстрая линия, конечно. Если была бы нужна самая быстрая, она была бы написана совсем по-другому, с гигантскими таблицами, с гигантским кодом, выжимая каждый такт. А здесь стояла задача написать и быструю и вместе с тем компактную процедуру линии (для игры).

Sinus тоже ввел в заблуждение. Он что-то попутал. Никаких гигантских таблиц данных и кодов я не строю. Стек не использую.

Я использую "стандартные" для таких дел как установка точки 4 таблицы по 256 байт (то есть в сумме килобайт), чтобы по координатам x,y рассчитать экранный адрес и взять точку. Эти таблицы универсальны - они используются везде: и для того чтобы через plot выставить точку, и для того чтобы рассчитать адрес спрайта.

Размещаются таблицы по адресу выравненному на границу 256 байт и выглядят так:
256 байт - координата x -> начальное положение точки в байте.
256 байт - координата x -> x/8, это x-компонента добавляемая к след.экр. адресу:
256 байт - координата y -> младший байт адреса
256 байт - координата y -> старший байт адреса

В процедуре обращение к таблицам производится один раз, в самом начале, при вычислении экранного адреса по координате x,y (и взятии байта точки).

Таблицы можно или уменьшить до (384 байт экр.адр. + 8 байт сдвинутой точки), или совсем убрать, заменив на чуть более длинный расчет адреса, по типу как это делается процедурой в ROM. Это добавит лишних ~100..200 тактов на линию, но избавит от таблиц вообще.

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

[alone]

можно сэкономить страничку на вертелку, если строить таблицы только для 32 засечек на каждой проекции каждой оси (9 таблиц):
ld hl,0
ld (OXxMUL),hl
ld (OXyMUL),hl
ld (OXzMUL),hl
ld (OYxMUL),hl
ld (OYyMUL),hl
ld (OYzMUL),hl
ld (OZxMUL),hl
ld (OZyMUL),hl
ld (OZzMUL),hl
...
macro zasec
add hl,de
ld (\0MUL+\1),hl
endm
macro tzasec
ld hl,(\0)
ld d,h,e,l
ld (\0MUL+2),hl
_=2
dup 30
_=_+2
zasec \0,_
edup
endm
tzasec OXx
tzasec OXy
tzasec OXz
tzasec OYx
tzasec OYy
tzasec OYz
tzasec OZx
tzasec OZy
tzasec OZz
(это 7700 тактов на кадр),

а координаты считать через
ld hl,(OXxMULx)
[xor a:sub l:ld l,a:sbc a,h:sub l:ld h,a]
ld de,(OYxMULx)
add/sbc hl,de
ld de,(OZxMULx)
add/sbc hl,de
:94*3

для 16-битных координат:
ld hl,(OXxMULX)
[xor a:sub l:ld l,a:sbc a,h:sub l:ld h,a]
ld de,(OXxMULx)
add/sbc hl,de
ld de,(OYxMULX)
add/sbc hl,de
ld de,(OYxMULx)
add/sbc hl,de
ld de,(OZxMULX)
add/sbc hl,de
ld de,(OZxMULx)
add/sbc hl,de
:193*3
Разделение на X и x - биты пополам
16 бит - 18 таблиц по 128 элементов (62208 t)
14 бит - 18 таблиц по 64 элемента (31104 t)
12 бит - 18 таблиц по 32 элемента (15552 t)

На практике 16-битные координаты внутри объекта не нужны.
Лучше с 16-битной точностью считать только координаты всего объекта, а сами вершины относительно объекта с 8-битной точностью.

[Cheburashka]

Не прошло и 100 лет...
Вот моё "творчество" в виде быстрой и компактной процедуры рисования линий.
Пробовал более быстрые варианты, но предварительные расчеты в процедуре сжирают всю выгоду для небольших линий.

[alone]

Неплохо! Я насчитал 244 такта на вход, не считая CALL. Но пока что по скорости обвязки ещё никто не переплюнул линию в Dies Irae (#9F6A) - там 192/227 тактов вход-выход.