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

[Sinus]

Умножение вектора на матрицу преобразования емнип 16 умножений, 12 сложений с нужной точностью.

не могу не вмешаться

9 умножений и 9 сложений на точку. если пренебречь дрожащими вершинами, то точность не важна.

и единоразово (на всю сцену) рассчёт матрицы - 25 умножений и 6 сложений/вычитаний.

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

----

самое быстрое и не пригодное для реальных условий умножение:

; BC = A * L
; A от 0 до 255, L от 0 до 255
; DE должно быть == #4000

add a,'MULTBL
ld h,a
ld c,(hl)
add hl,de
ld b,(hl)

итого 7+4+7+11+7 = 36 (причём это наиболее быстрое и наименее пригодное в реальной жизни умножение)
36 * 9 = 324 такта тольно на умножение

с реальным умножением (пусть оно и умжножает от -128 до 127 по таблице), будет гораздо больше.
так что ни 200 ни 100 точек за фрейм "честно" не повернуть.

----

с другой стороны в 3D игре важно не насколько оно фреймово, а просто насколько быстро.
и вот тут есть разница - поворот 2х точек намного быстрее отрисовки линии, как не крути.

[Advertiser]

[Higgins]

9 умножений и 9 сложений на точку. если пренебречь дрожащими вершинами, то точность не важна.

Есть хитрости. Во-первых, координату глубины можно считать, когда и если ее вообще нужно считать, не для каждой вершины, а для всего объекта. То есть три из этих девяти умножений могут быть опущены.

Во-вторых, если шаг координатной сетки велик (т.е. количество делений на каждой из осей небольшое), можно сначала посчитать проекции радиус-векторов до всех точек осей, а затем получить координаты вершин простыми сложениями.

Наверное, можно и еще что-нибудь выдумать.

[Sinus]

это "честный" поворот.

Во-первых, координату глубины можно считать, когда и если ее вообще нужно считать, не для каждой вершины, а для всего объекта. То есть три из этих девяти умножений могут быть опущены.

мм. и изомерическая проекция? нафих.

----

а если делать прекальк до для не сложных объектов можно обойтись от 4х до 6ти умножений (про это писалось в каком-то Spectrum Expert). но эти хитрости для демок больше, а тут разговор про игры идёт.

[alone]

Качаем сорцы The Link и в эффекте с ёжиком смотрим вертелку JTN'а. Оставляем 2 оси из 3, как раз будет около 350 тактов. Есть также аналогичная вертелка Vitamin'а.

[Titus]

Качаем сорцы The Link и в эффекте с ёжиком смотрим вертелку JTN'а. Оставляем 2 оси из 3, как раз будет около 350 тактов. Есть также аналогичная вертелка Vitamin'а.

Прикольная дема, жаль, практически под абстрактное железо - пентагон 1024кб с 110000 тактами и GS. Вот сделать это же под обычный пентагон 128кб ;-)

[Sinus]

Оставляем 2 оси из 3

про что и говорилось изначально (начиная с поста #25).

в деме можно и 2 оси оставить, и одну, и прекальк сделать, и т.д.
а в игрушке низзя

[Lethargeek]

Higgins, есть вопросы:

1) Мерил целиком, или только основной цикл (от первой поставленной точки до последней)?
2) Точки только ставились, или можно было ксорить заменой нескольких кодов?
3) Сколько процедурки жрут памяти именно в рабочем состоянии?

Тут, возможно, скоро будет новый кандидат на тестирование
13000 на диагональ многовато...

[Higgins]

1) Мерил целиком, или только основной цикл (от первой поставленной точки до последней)?

Измерялась разница значений счетчика тактов непосредственно до исполнения инструкции CALL, вызывающей процедуру рисования линии и сразу после возврата управления из этой процедуры.

Код, устанавливающий значения регистров и все прочие приготовления не учитывались.

Задержки по памяти и портам не учитывались тоже.

) Точки только ставились, или можно было ксорить заменой нескольких кодов?

Это определяется реализацией. Понятно, что при использовании SET быстрой ксорки не будет.

Возможно, для каждой реализации следует делать пометку о том, может ли она ксорить.

3) Сколько процедурки жрут памяти именно в рабочем состоянии?

Ох, надо покопать архив.

Да, и может быть это тоже следует указывать при сравнении.

Тут, возможно, скоро будет новый кандидат на тестирование

Было бы отлично. Штука-то фундаментальная.

13000 на диагональ многовато...

[GriV]

не могу не вмешаться

самое быстрое и не пригодное для реальных условий умножение:

; BC = A * L
; A от 0 до 255, L от 0 до 255
; DE должно быть == #4000

add a,'MULTBL
ld h,a
ld c,(hl)
add hl,de
ld b,(hl)

итого 7+4+7+11+7 = 36 (причём это наиболее быстрое и наименее пригодное в реальной жизни умножение)
36 * 9 = 324 такта тольно на умножение

с реальным умножением (пусть оно и умжножает от -128 до 127 по таблице), будет гораздо больше.
так что ни 200 ни 100 точек за фрейм "честно" не повернуть.

Читаю код... не понимаю... объясни? Если правильно понимаю, то 255*255 = около 65025.
При умножении 255*255 тебе надо две таблицы - одна с младшим байтом, другая с старшим, количество значений - 65025 на старший и столько же на младший байт, итого 130050 байт. Может где то обманул??? У тебя там вижу всё в основную память падает + смещение по базовому адресу таблицы.

[Destr]

Похоже что на входе А от 0 до 63:
Тогда да, памяти хватит (16384 байт на старший байт и столько-же на младший ).
Я такое умножение в DotsElka делал.
А если А от 0 до 255 то получается что ВСЯ память (включая ПЗУ) занята под табличку (причём только одного полуслова)