Destr, да, так и есть, A от 0 до 63.
Вот тебе ещё быстрее:Сообщение от Sinus
не могу не вмешаться
самое быстрое и не пригодное для реальных условий умножение:
итого 7+4+7+11+7 = 36 (причём это наиболее быстрое и наименее пригодное в реальной жизни умножение)Код:; 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)
36 * 9 = 324 такта тольно на умножение
с реальным умножением (пусть оно и умжножает от -128 до 127 по таблице), будет гораздо больше.
так что ни 200 ни 100 точек за фрейм "честно" не повернуть.
----
это будет 7+4+7+8+7= 33 такта :-) экономия однако, итого на 9 точек - 33*9 = 297 тактовКод:; 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)
Однако 64*256 - не самый правильный объём расчётов с точки зрения изображения на экране (одна треть экрана)
Можно сделать 128*192 (по оси X дискретность выше, по Y полный экран; или экран с X=0..191, Y=0..127)
Разместив таблицу последовательно (в каждые 256 байт 128 слов)
будет:
итого: 8+4+4+7+4+7=34 такта, зато считается половина экрана, и свободны DE и A :-)Код:; 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)
В голом остатке получаем 297 тактов * 200 точек = 59400 тактов, т.е. теоретические шансы по "уложиться в фрейм 200 точек" есть, вопрос по производительности прорисовки остаётся актуальным.
Знаешь, очень не хватает встроенной DRAW бейсика в этих диаграммах.
И ещё, ты строишь линии на 256 по X... будет ли меняться характер распределения (и если да, то насколько сильно), если использовать другое количество по X? Например 128, или то самое 10-20? У любой рисовалки есть подготовительная обязательная часть... Тут это станет сильно заметным...
И ещё, подправь наименования графиков (сгруппируй, чтобы удобнее читать было) в верхнем посте, не вижу что показывает второй график...
не тоже самое; добавь-ка мне #40 через set 6,h к, скажем, #6000добавление #40 это тоже самое что set 6,h
а код куда размещать? в ПЗУ?Можно сделать 128*192
кстати,
для H от 64 до 127 будет выдавать неправильные значения.Код:set 6,h - задали адрес откуда начинается таблица - #4000
кстати даЗнаешь, очень не хватает встроенной DRAW бейсика в этих диаграммахтак, чтоб поржать.
Отличная идея. Постараюсь сделать.
Если я правильно помню, я такие графики строил и ничего нового на них не увидел. Выглядят они по-другому, но только из-за того, что при изменении дельты по X незибежно меняются углы наклона, а прямые с одним и тем же углом наклона рисуются за время, пропорциональное их длине за вычетом тех самых подготовительной и финальных частей. Сравнивать такие графики корректно трудно, т.к. только часть линий (0,0)-(127,Y) имеет углы наклона в точности такие же, как линии (0,0)-(255,Y). Плюс к тому, могут быть небольшие отклонения, вызванные тем, что линии разной длины, даже одного и того же угла наклона, строятся по-разному из-за балансирования. (К слову, балансировку тоже, наверное, следовало бы отмечать при сравнении процедур.)
Что касается времени подготовки, наверное, достаточно для каждой процедуры дать время на короткой линии.
Ничего не понял.
Higgins ZX Spectrum Emulator 8.10 alpha 3 available
Please write us to report a bug or request a feature.
Кстати, по поводу быстрых умножений-делений для прорисовки
Нужно быстрое преобразование dx; dy ---> dy1; dy2 для dx=256
причем dy1 - округленное (256*dy)/dx, а dy2 = dy1 + ((256*dy)/dx - dy1)*8
Например, для диагонали dx=255; dy=191 получится dy1=192; dy2=190
Зачем это надо? Чтоб избавиться от лишнего сложения в конструкции sub dy:jrnc:add dx
И тогда семь раз можно вычитать dy1, а на восьмой вычесть dy2, чтобы скорректировать ошибку
Экономия прямая по 4 такта на ступеньку (и вдвое больше косвенная в некоторых вариантах)
Есть вообще-то уже несколько набросков и без того заметно быстрей рассмотренных
но пока что я недоволен, надо еще быстрее (и попутно желательно покороче)
Прихожу без разрешения, сею смерть и разрушение...
У меня получилось от 169946 тактов на (0,0)-(255,0) до 170832 такта на (0,0)-(255,175). Если это вставить в общий график, линии для Expert, Raider и Vitamin практически сольются.
Но: в отличие от названных процедур, бейсик выводит линии в цвете. Получается, полноценного конкурента у него все-таки нет.
Higgins ZX Spectrum Emulator 8.10 alpha 3 available
Please write us to report a bug or request a feature.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Гы, так он же плотами точки ставит по координатам
Причем красит атрибут после каждой точки
Поищи на WoS-форуме, я там как-то видел чье-то альтернативное творчество с окрашиванием
Прихожу без разрешения, сею смерть и разрушение...
У тебя 4 графика, их описание разбросано в посте (что не так важно, но несколько путает), но я не смог описание 2го графика вытащить :-) то ли это следует из дальнейшего обсуждения, то ли я читать разучился :-)
Ничего не понял.
Согласен, моя ошибка... тогда так
Итого конечно на 3 такта больше (37 тактов), зато не используется тем не менее DE (что есть бонус на отсутствии затрат сохранения контекста этого регистра).Код:; BC = A * L ; L от 0 до 127, A от 0 до 191 add a,'MULTABL ld h,a rlc l - получили адрес младшего байта ld c,(hl) inc l ld b,(hl)
Можно в теневое ПЗУ/ОЗУ. А можно сделать ограничения 0..176 точек (вместо 0..192), это около 4КБ даст, туда и код ложить. Однако цепляться вот не надо, у тебя там вообще 128кб надо было под одну таблицу...
Не хочу что то :-)
Построить линию длиной 1-2 точки и дать справочно базовое время работы.
Тем не менее информация интересная.
Кроме того, интересно как она построит (в тактах конечно) минимальной длины линию. Есть некий шанс что она это сделает быстрее указанных процедур. И ещё, Хотя бы 1 график на DRAW можно было бы сделать? Один из графиков (например 1й), уточночнить и добавить туда DRAW. И ещё, можно было бы графики сделать логарифмическими по оси тактов, тогда там лучшее видно будет.
Смысл обоих графиков один и тот же, но на втором показаны только две быстрейшие реализации, чтобы лучше видеть разницу.
Сейчас эти графики слиты в один и в таком виде выложены в первом сообщении темы.
Вот какие еще бродят мысли: сделать гистограммку, в которой для линий разных длин были бы даны минимальное и максимальное времена рисования. Тогда имея на руках сцену, разложенную по линиям с известными длиной и количеством можно было бы прикинуть возможное время построения, причем для любых углов, то есть как бы она ни была повернута.
Ну, на графиках такты все-таки не по экспоненте растут. ;-)
Higgins ZX Spectrum Emulator 8.10 alpha 3 available
Please write us to report a bug or request a feature.
Чтобы вращать совсем быстро, надо использовать таблицу умножения 64(координаты в объекте)*256(рассчитанные координаты осей).
Каждая вершина n разворачивается в процедуру
x=OXx*X[n]+OYx*Y[n]+OZx*Z[n]
y=OXy*X[n]+OYy*Y[n]+OZy*Z[n]
;c=OXx
;e=OYx
;l=Ozx
ld b,X[n]
ld d,Y[n]
ld h,Z[n]
ld a,(bc)
add a,(hl)
exd
add a,(hl)
ld (scrX[n]),a
---
ld b,X[n+1]
ld h,Y[n+1]
ld d,Z[n+1]
ld a,(bc)
add a,(hl)
exd
add a,(hl)
ld (scrX[n+1]),a
...
59 тактов на координату.
Проверено, работает.
---------- Post added at 14:58 ---------- Previous post was at 14:53 ----------
Сейчас тут будут возгласы типа "точность никакая", так вот я отвечу.
1. Во-первых, точность принципиально выше, чем у JtN'а и аналогичных движков, потому что нет умножения умноженного.
2. Таблицы умножения, составленные с округлением вниз, - типичная ошибка, убивающая точность насмерть (JtN её тоже не избежал). Округлять надо правильно. См. исходники The Link.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
[
Ответить с цитированием
