через строчку переключаем экран (атрибуты/чанки)
на 4-й строчке надо сменить атрибуты (можно успеть pop:ld)
где-то ещё каждый кадр надо перебросить атрибуты 0-й строчки
при смене картинки надо обновить её за 1 кадр
это 3072 (4*768) байта чанков и 1536 (2*768) байтов атрибутов (из них 768 выводим в самом мультиколоре и 768 где-то)
итого остаётся 4*768
внутри мультиколора можно перебросить ещё 3*768 байтов
итого остаётся 1*768
это 1*768*13 ~ 10000 = 45 строк! плюс ещё переброска 0-й строчки "где-то" каждый фрейм (можно в верхнем бордере вместе с музыкой)

в какой экранной области атрибуты, а в какой чанки?
или чередовать?
если чередовать, то надо за 1 кадр обновить только атрибуты (верхушки и мультиколор на 4-й строчке)
это можно объединить с c2p или оставить половину времени в мультиколоре под пользовательскую процедуру

c2p:
атрибуты (таблица в одной странице):
pop hl
ldd ;каждый второй рендер - из медленной страницы! кидаем не в экран, а в быстрый буфер
:26/пару * 32 = 832 = 3.714 строк (вообще 39936)
(у нас только 2 строки + 126 тактов на обновление 4-й строчки: можно успеть ldi, но без pop, или не на всю ширину)
+
чанки (таблица в другой странице):
pop hl
ldd ;каждый второй рендер - из медленной страницы!
ld a,(hl) ;каждый второй рендер - из медленной страницы!
ld (bc),a ;slowmem!!!
:40/пару (вообще 61440)
=66/пару * 32*48 = 101376 (это больше 2 полей экрана!!!)

если чередуем, то как писать из страницы (где таблица) в страницу 7???
если бы всегда атрибуты в странице 7, то можно - но тогда чанки нельзя вывести в страницу 7!
тогда надо таблицы в нижней памяти (где столько взять? рядом с chmap?), одна из них pop hl:dec h (+4 такта/пару)

Проще не чередовать, тогда таблицы в странице и не надо inc h.
Если таблицы в странице, то вся текстура должна укладываться в 18 цветов (#dd..#ff через один)!!! [Чанки можно во всю страницу (32 цвета), но тогда атрибуты не получится по тем же данным в странице 7.]
Если не чередовать, то надо, чтобы планировщик задач спланировал вызовы полного обновления атрибутов и чанков (начиная с конца предыдущего кадра).

Как спланировать обращение к медленной памяти при c2p атрибутов? всегда класть их в верхний бордер (не влезет) или всегда в экран? можно всю планировку в экран:

кадр:
1. музыка (5 строк)
2. переброска 0-й строчки (45 строк)
3. планировщик?
4. инициализация пользовательского фрейма
5. (пауза - выход на строчку 3)
---
6. мультиколор + пользовательские процедуры по 6 строк
---
7. вторая задача пользователя (56 строк)


что будут делать первая и вторая задачи в зумротаторе? можно в мультиколоре делать только c2p (в 3 кадра), а вторая задача вся на зумротатор. Но за 2 кадра = 56*2 = 112 строк = 25088 тактов не успеет во весь экран (3072 чанков).
Если окно 48x40, то 1920 чанков, остаётся 88*2 = 176 строк = 39424 тактов (20.5 тактов на чанк)
Надо разложить c2p на более чем 2 кадра: можно отложить c2p атрибутов в отдельный кадр, т.к. он подцепляется в каждом кадре отдельно.
Если окно 48x40, то 1920 чанков, остаётся 88*3 = 264 строк = 59136 тактов (30.8 тактов на чанк, а у нас минимум 31.5)
Не успеваем честный зумротатор.
Это при маленьком окне.
Вообще лучше оставить окно 48x48 или 64x32.
Или пол-экрана 32x48 (1536 чанков) - тогда пользовательские процедуры по 7 строк. Но 56*3 = 168 строк = 37632 тактов (24.5 тактов на чанк, а у нас минимум 31.5).

Т.е. всё-таки надо планировать зумротатор в области мультиколора.
Желательно уложиться в 4 кадра.

c2p чанков должно планироваться только вне экрана (иначе трудно будет настроить под вайтовые и новайтовые компы), остальное можно и в экране, и вне экрана (если чанковый буфер в быстрой памяти и если таблица атрибутов в нижней памяти, т.к. 7-я страница медленная).
c2p чанков можно асинхронно (в нижнем бордере) только при чередовании экранов в рендерах, но тогда таблица чанков должна быть в нижней памяти, таблица атрибутов тоже!
для универсальности надо всё в страницах. тогда c2p чанков идёт в 5-й экран (планируется вне экрана (можно таблицу в медленной странице), но синхронно!!!), а c2p атрибутов в быстрый буфер (из быстрой страницы).
тогда можно 32 цвета.

Если c2p чанков вне экрана, то мы ограничены временем верхнего и нижнего бордера. Не успеем обновить весь экран.

Или всё-таки планировать c2p чанков в экране (из быстрой страницы)? Чтобы упростить настройку под разные компы, надо округлить все записи до 8 тактов (40 тактов на чанк не получится).










/**
Если и чанки, и атрибуты в одной странице, то можно выводить одновременно:
pop hl
ld d,N
ld a,(hl) ;slowmem!!!
ld (de),a
dec h
ld d,N+2
ldd
ld a,(hl)
ld (bc),a
:72/пару - медленно
*/

для зумротатора можно без c2p, но неудобно (надо заполнить две разных области памяти, из них одна в странице)





выделение времени под пользовательскую процедуру кусками по 6 строк:
пользователь должен щёлкать экранами каждую строчку!!! делать это минимум 5 раз
jumpXX:
<mc>
ld iy,jumpYY
patchXX:
jp ...
---
[exx]
<пользователь>
[exx]
jp (iy)
---
jumpYY:
потеря времени 32 такта на один вызов (в мультиколоре) + патчи (вне мультиколора)
пользователь будет щёлкать экранами через out (c),d...out (c),e
но пользователь должен работать в своей страничке! т.е. должен пересчитывать d,e!
при этом должен знать текущий экран (фаза меняется каждый рендер)
ld a,hx
or pg
out (c),a
 или (если свободно a,a'):
<расчёт a,a'>
...
out (c),a
ex af,af'
 или (не занимать альтернативные регистры):
<пересчёт d,e>
...
out (c),d/e

проще не чередовать


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








зумротатор:

а) зумротатор универсальный (можно с горизонтальным тилтом):
add hl,bc
ld a,h
exx
add hl,bc
ld d,h
ld e,l
ld a,(de)
exx
ld (de),a
inc e
:60/чанк * 64*48 = 184320
не контролирует выход за текстуру (если в #8000..#ffff, то +8 тактов, но как же, если c2p надо в быстрой памяти!!!)
и занимает bc, т.е. как переключать экраны? один bc перенести в sp
если не чередовать страницы экрана в рендерах, то можно при этом ещё освободить de (bc будет через ld bc)
/**
add ix,bc
add hl,sp
ld d,hx
ld e,h
ld a,(de)
ld (...),a
:58/чанк, 10 байт/чанк (30720 байт), придётся класть в страницы - нереально
*/
/**
add ix,bc
add hl,de
ld a,h
exx
ld d,hx
ld e,a
ld a,(de)
ld (hl),a
inc l
exx
:68/чанк - тормоз
*/
/**
add ix,bc
add iy,sp
ld d,hx
ld e,hy
ld a,(de)
ld (hl),a
inc l
:64/чанк без bc,bc' и при этом занимает iy
*/
/**б)
одна координата через 8-разрядную арифметику
add hl,sp
ld a,d
add a,e
ld d,a
ld a,h
exx
ld h,a
ld a,l
adc a,b
ld l,a
ldi
exx
:67/чанк без bc - тормоз
*/

в)
можно ли сделать универсальный зумротатор из нескольких неуниверсальных?
патчи строки на весь экран не помогут
можно сделать тилт после зума, но не после зумротатора (будет неправильно зацикливать текстуру под углом)
нельзя после зумротатора сделать повтор (продолжение строки после зациливания - это уже другое место текстуры)
можно только разбить по старшим байтам сумматоров (+0..1, +1..2, +2..3...), но будет очень много разных пар
можно только по одному из сумматоров (V, чтобы зацикливать?)
нет выигрыша???

/**г)
неполная разрядность, текстура 16x256 с правильным зацикливанием
add ix,bc ;%uuuuVVVV vvvvvvvv
adc hl,sp ;%???????? UUUUUUUU
ld a,hx
or b;#f0
ld h,a
ldi
:62/чанк без bc' - тормоз
будут непредсказуемые перекосы по u
как их лечить???
62/чанк при add a,b:adc hl,sp:ld c,hx:ld h,c (без правильного зацикливания, но и без перекосов)
*/
д)
таблицы U и V на все масштабы - не хватит нижней памяти, тогда текстуру надо в нижней памяти, а таблицы вверху
как входить в нужной фазе u и v?
е)
16x16:
add hl,bc ;%11VVVVvv vUUUUuuu
[ld a,h:or #c0:ld h,a]
ld d/e,(hl)
1/2*push de
:23.5 [+15]
будут непредсказуемые перекосы по v
как их лечить? можно за счёт математики (это просто необычный порядок стыковки квадратиков)
при bc<0 достаточно одного set. а как ускорить при bc>0? перевёрнутая текстура в другой странице?
тогда 31.5
ё)
тайловый ротатор???
ж)
полигоны? нельзя при больших расстояниях - полигонов будет бесконечность
з)
по столбцам? код столбца сгенерировать? и какой будет этот код?
сдвиг относительно центральной оси зависит от расстояния (точного!) и угла поворота, умножить на X
и)
набирать неровные шаги из готовых процедур по 4 или 8 шагов (как в DMA Sound Blaster)
будет заметно регулярные складки?
для одной оси: +0, +1/8, +2/8, +3/8 ... +63/8 и отрицательные, итого ~128
для двух осей слишком много вариантов (128*128)


хотелось бы тилт с затенением
это можно через разные таблицы c2p, но где хранить столько таблиц - под каждую яркость?


для скорости зумротатор лучше всё-таки без c2p, а прямо в экран (пиксели и атрибуты)
тогда надо 2 экрана
значит, процедуры пользователя должны уметь работать в любой из 2 фаз. но как писать из текстуры в страницу 7 и с учётом таблицы чанков?
лучше графику чанков прямо в текстуре. но как писать в страницу 7?



в чанках 4x2:
всего 271000..322000
из них:
91739 background (ldir)
6293 rotmatrix
4000 rotate
125074 drawpolys (12 шт) tmap
91862 c2p

для сравнения SOMMER:
всего 431000
из них:
2416 rotate axes
75688 background (ldi)
45079...49324 rotate
19743..20037 prepare
3591 prepare stacks?
111698...139902 drawpolys (24 шт) gouraud
154769..159248 c2p
