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

[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]

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

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

----

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

; 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 точек" есть, вопрос по производительности прорисовки остаётся актуальным.

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

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

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

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