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

[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х точек намного быстрее отрисовки линии, как не крути.

[GriV]

Originally Posted by Sinus

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

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

; 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 байт. Может где то обманул??? У тебя там вижу всё в основную память падает + смещение по базовому адресу таблицы.

[GriV]

Originally Posted by Sinus

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

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

; 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 точек за фрейм "честно" не повернуть.

----

Вот тебе ещё быстрее:

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

add a,'MULTBL
ld h,a
ld c,(hl)
; add hl,de - добавление #40 это тоже самое что set 6,h
set 6,h
ld b,(hl)

это будет 7+4+7+8+7= 33 такта :-) экономия однако, итого на 9 точек - 33*9 = 297 тактов

Однако 64*256 - не самый правильный объём расчётов с точки зрения изображения на экране (одна треть экрана)

Можно сделать 128*192 (по оси X дискретность выше, по Y полный экран; или экран с X=0..191, Y=0..127)
Разместив таблицу последовательно (в каждые 256 байт 128 слов)
будет:

; BC = H * L
; L от 0 до 127, H от 0 до 191

set 6,h       - задали адрес откуда начинается таблица - #4000
; тут возможен вариант set 7,h - #8000, но тогда будет 0..127*0..127
rlc l           - получили адрес младшего байта
ld c,(hl)
inc l
ld b,(hl)

итого: 8+4+4+7+4+7=34 такта, зато считается половина экрана, и свободны DE и A :-)

В голом остатке получаем 297 тактов * 200 точек = 59400 тактов, т.е. теоретические шансы по "уложиться в фрейм 200 точек" есть, вопрос по производительности прорисовки остаётся актуальным.

Originally Posted by Higgins

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

Знаешь, очень не хватает встроенной DRAW бейсика в этих диаграммах.

И ещё, ты строишь линии на 256 по X... будет ли меняться характер распределения (и если да, то насколько сильно), если использовать другое количество по X? Например 128, или то самое 10-20? У любой рисовалки есть подготовительная обязательная часть... Тут это станет сильно заметным...

И ещё, подправь наименования графиков (сгруппируй, чтобы удобнее читать было) в верхнем посте, не вижу что показывает второй график...

[Higgins]

Originally Posted by Sinus

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

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

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

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

[Sinus]

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

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

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

----

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

[alone]

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

[Titus]

Originally Posted by alone

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

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

[Sinus]

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

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

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

[Lethargeek]

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

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

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

[Higgins]

Originally Posted by Lethargeek

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

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

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

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

Originally Posted by Lethargeek

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

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

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

Originally Posted by Lethargeek

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

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

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

Originally Posted by Lethargeek

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

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

Originally Posted by Lethargeek

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