Элита для Специалиста

Цитата:

Сообщение от jerri

мне пока нечего туда пихать

да хоть код пихай

Цитата:

Сообщение от jerri

ну для горизонтальных и вертикальных линий и диагональных линий я и твое слегка ускорил

смысл был не в этом

Цитата:

Сообщение от jerri

у меня и так используются 4 подпрограммы - угол 0-45 45-90 слева направо и столько же справа налево

да при чём тут это? можно сделать ветки, можно код перед входом патчить, дело в другом
у меня в примере обе подветки - части ОДНОГО цикла, рисующего слева направо для dx>dy
они обе в цикле отрабатывают, но в разных пропорциях в зависимости от наклона отрезка
вычитание из ошибки разных чисел в разных подветках избавляет от коррекции ошибки:

Цитата:

Сообщение от jerri

add a,c

+ регистр еще при этом освобождает

Цитата:

Сообщение от jerri

расчеты сожрут всю выгоду от скорости.

какие расчёты? плюс одна проверка, переход, сдвиг
другое дело, что выгодных отрезков немного будет

Цитата:

Сообщение от jerri

текущая версия линии

всё еще 80-94 такта на пиксель (в цикле для лежачих отрезков)

Цитата:

Сообщение от jerri

дополнения, предложения есть?

второй недостаток:

Цитата:

Сообщение от jerri

rrca
ld e,a
jp nc,line_lrhb
inc h
line_lrhb
dec d
jp nz,line_lrh0
ret

вероятность выхода по завершению заведомо очень низкая
потому вместо jp выгоднее проверять на ноль условным ret
а для этого перенести декремент с проверкой в начало
и переход на него совместить с условным переходом после rrca
(который, напротив, происходит часто - в 7 из 8 случаев)
выигрыш - 5 тактов на каждый пиксель
у меня в примере уже так сделано

Цитата:

Сообщение от Lethargeek

да хоть код пихай

зачем?

Цитата:

да при чём тут это? можно сделать ветки, можно код перед входом патчить, дело в другом
у меня в примере обе подветки - части ОДНОГО цикла, рисующего слева направо для dx>dy
они обе в цикле отрабатывают, но в разных пропорциях в зависимости от наклона отрезка
вычитание из ошибки разных чисел в разных подветках избавляет от коррекции ошибки:

у тебя ошибка в коде
сделай нормальную линию

Цитата:

какие расчёты? плюс одна проверка, переход, сдвиг
другое дело, что выгодных отрезков немного будет

о чем и речь

Цитата:

всё еще 80-94 такта на пиксель (в цикле для лежачих отрезков)

второй недостаток:

вероятность выхода по завершению заведомо очень низкая
потому вместо jp выгоднее проверять на ноль условным ret
а для этого перенести декремент с проверкой в начало
и переход на него совместить с условным переходом после rrca
(который, напротив, происходит часто - в 7 из 8 случаев)
выигрыш - 5 тактов на каждый пиксель
у меня в примере уже так сделано

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

- - - Добавлено - - -

Lethargeek
смотри что скажешь?

Код:

bitstream db #80,#40,#20,#10,#08,#04,#02,#01 ;в DE - yx начала ;в HL - yx конца line00 ld a,h sub d ;h<d? jp nc,line1 ;h>d ex de,hl cpl inc a line1 ld b,a ;b=vertical cntr DY ld a,l sub e ;a=DX ;e<l? jp nc,line_lr ;e>l line_rl cpl inc a ld c,a ;c=horizontal cntr cp b ;c?b jp c,line_rlv ;c>b or b jp nz,line_rlh inc c line_rlh ;right left horizontal call de_coo ld a,b ld (line_rlhb0),a ld d,c ld a,e line_rlh0 xor (hl) ld (hl),a dec d ret z line_rlh2 ld a,b sub 0 ;b line_rlhb0 equ $-1 jp nc,line_rlh1 add a,c inc l line_rlh1 ld b,a ld a,e rlca ld e,a jp nc,line_rlh0 dec h xor (hl) ld (hl),a dec d jp nz,line_rlh2 ret line_rlv ;right left vertical or b jp nz,line_rlv2 inc b line_rlv2 call de_coo ld a,c ld (line_rlvb0),a ld d,b line_rlv0 ld a,(hl) xor e ld (hl),a dec d ret z line_rlv1 inc l ;движение по вертикали ld a,c sub 0 ;c line_rlvb0 equ $-1 ld c,a jp nc,line_rlv0 ;движение по горизонтали add a,b ld c,a ld a,e or a rlca ld e,a jp nc,line_rlv3 dec h line_rlv3 xor (hl) ld (hl),a dec d jp nz,line_rlv1 ret line_lr ld c,a cp b ;c?b jp c,line_lrv ;c>b or b jp nz,line_lrh inc c line_lrh ;left right horizontal call de_coo ld a,b ld (line_lrhb0),a ld d,c ld a,e line_lrh0 xor (hl) ld (hl),a dec d ret z line_lrh2 ld a,b sub 0 ;b line_lrhb0 equ $-1 jp nc,line_lrh1 ;движение по вертикали add a,c inc l line_lrh1 ld b,a ld a,e rrca ld e,a jp nc,line_lrh0 inc h xor (hl) ld (hl),a dec d jp nz,line_lrh2 ret line_lrv or b jp nz,line_lrv2 inc b line_lrv2 ;left right vertical call de_coo ld a,c ld (line_lrvb0),a ld d,b line_lrv0 ld a,(hl) xor e ld (hl),a dec d ret z line_lrv1 inc l ld a,c sub 0 ;c line_lrvb0 equ $-1 ld c,a jp nc,line_lrv0 add a,b ld c,a ld a,e rrca ld e,a jp nc,line_lrv3 inc h line_lrv3 xor (hl) ld (hl),a dec d jp nz,line_lrv1 ret de_coo ;de=source ld a,e rra rra rra and #1f add a,#98 ld h,a ld l,d ld a,e ex de,hl and #07 ld hl,bitstream add a,l ld l,a ld l,(hl) ex de,hl ;hl=addr ;e=bitstream ret

https://www.dropbox.com/s/bmlq6jzh75...eline.rks?dl=0 в работе

Цитата:

Сообщение от jerri

зачем?

чтобы место не пропадало (у тебя на буфер же не хватало)
ну и суй на боковушки редкоизменяемые данные или код

Цитата:

Сообщение от jerri

у тебя ошибка в коде

где конкретно? это адаптация со спека, там же работало

Цитата:

Сообщение от jerri

сделай нормальную линию

что значит "нормальную"? медленней? :v2_laugh:

Цитата:

Сообщение от jerri

смотри что скажешь?

лучше, но ~5 тактов для лежачих линий всё так же лишние (для стоячих кабы не еще больше)

буфер не предусмотрен
и к тому же он сожрет всю скорость специалиста

так что вариант только один - рисовать достаточно быстро

Цитата:

Сообщение от Lethargeek

где конкретно? это адаптация со спека, там же работало

ты отнимаешь DX а DY не прибавляешь

Цитата:

лучше, но ~5 тактов для лежачих линий всё так же лишние (для стоячих кабы не еще больше)

выигрыш не ощущается
я не дему с лежачими линиями пишу

там много больше лишнего
диагональные линии - тупо
inc l и rlca/rrca

горизонтальные
rlca/rrca

вертикальные
inc l

Цитата:

что значит "нормальную"? медленней? :v2_laugh:

рабочую версию для специалиста
чтобы рисовал вертикальную, горизонтальную и наклонные линии

Цитата:

Сообщение от jerri

буфер не предусмотрен
и к тому же он сожрет всю скорость специалиста

ерунда, обсчёт 3D сжирает больше в разы
тут добавится только время на переброску буфера
но хоть мигать не будет

Цитата:

Сообщение от jerri

ты отнимаешь DX а DY не прибавляешь

:v2_laugh: :v2_dizzy_facepalm:
во-1, всё наоборот (для лежачих) - перепутал ты сейчас DX и DY
во-2, посмотри внимательно вот сюда, в код второй подветки того же цикла:

Цитата:

Сообщение от Lethargeek

_hd1:
ld a,ERR
sub (DY-DX)
ld ERR,a
jp nc,_hh2

помнишь школьное правило "минус на минус даёт плюс"?
так что нету никакой ошибки - прибавление из цикла вынесено

Цитата:

Сообщение от jerri

рабочую версию для специалиста
чтобы рисовал вертикальную, горизонтальную и наклонные линии

ты совсем уже обленился :D

Цитата:

Сообщение от Lethargeek

ерунда, обсчёт 3D сжирает больше в разы
тут добавится только время на переброску буфера
но хоть мигать не будет

обсчет 3д даже на спеке вполне сравним с перебросом экрана (всего кстати 4к)
а вот насчет специалиста я вообще не уверен. во первых 6к во вторых команды для переброски слабоваты.

Цитата:

:v2_laugh: :v2_dizzy_facepalm:
во-1, всё наоборот (для лежачих) - перепутал ты сейчас DX и DY
во-2, посмотри внимательно вот сюда, в код второй подветки того же цикла:

ничего я не путал.
при рисовании по горизонтали DY вычитаем DX прибавляем
при рисовании по вертикали DX вычитаем DY прибавляем

Цитата:

помнишь школьное правило "минус на минус даёт плюс"?
так что нету никакой ошибки - прибавление из цикла вынесено

я не вижу рабочей версии твоей программы

Цитата:

Сообщение от jerri

обсчет 3д даже на спеке вполне сравним с перебросом экрана (всего кстати 4к)

доооо, канешна:

Цитата:

Сообщение от Lethargeek

например, при отлёте глядя в задний экран время отрисовки станции = 80-90 тыщ тактов
пауза между отрисовками, то есть всё остальное время игрового кадра ~480 тыщ тактов
из которых надо сразу вычесть еще 90 тыщ на очистку и переброску буфера

разница в 5 раз... ну, пусть в 4 раза... или что же тогда жрёт основную часть ~400 тыщ тактов, если не 3d-расчёты, по-твоему?

Цитата:

Сообщение от jerri

ничего я не путал.
при рисовании по горизонтали DY вычитаем DX прибавляем
при рисовании по вертикали DX вычитаем DY прибавляем

нет, всё ты перепутал, заявляя:

Цитата:

Сообщение от jerri

ты отнимаешь DX а DY не прибавляешь

тогда как в примере вычитал я как раз DY, как и положено

Цитата:

Сообщение от jerri

я не вижу рабочей версии твоей программы

не наглей, я не обязан делать за тебя всю работу, да и времени сейчас на это у меня нет
дал пример проверенного на спеке способа экономичного обсчёта ошибки
понимающему - достаточно, не желаешь пробовать и думать - ССЗБ

Сравнил скорость последней версии линии jerri и линии blackmirrora, которую уже упоминал в этой теме. Тестировал как написано в упоминаемом посте. Текущий вариант jerri на несколько байт короче и на несколько процентов медленнее.
Отмечу, что в посте blackmirrora он кое-где использовал команды z80 отсутствующие у 8080, но замена там очевидна.
У jerri осталась лишняя команда OR A в районе между line_rlvb0 и line_rlv3 (тестировал без нее).
Я это все к чему. Достигнутая скорость линии вполне товарная, быстрее можно, но не намного, если не отказываться от сдвига маски и не разворачивать цикл.

на данный момент длина процедуры 214 байт - есть ли смысл раздувать вот это в 8 раз ради

ivagor, сколько даст ускорения вот этот вот этот разворот цикла?

Цитата:

Сообщение от jerri

есть ли смысл раздувать вот это в 8 раз

Нет, для элиты конечно не надо раздувать. При заполнении линиями квадрата 256x256 выигрыш 20-21%, для квадрата 128x128 - 18-19%, дальше я промежуточные не замерял, а в районе 15x15-16x16 точек процедуры сравниваются по скорости. На коротких линиях без развертывания быстрее, громоздкая инициализация самомодифицирующегося кода съедает выигрыш.
Понятно, что для применений, где нужна бескомпромиссная максимальная скорость линии во всем диапазоне и нет ограничений по размеру программы можно делать выбор между "обычной" процедурой для коротких и развернутой для длинных. Но элита на мой взгляд не тот случай.