16 уровней яркости
test_rndnoise.scl - случайный шум (максимум, чего можно добиться фильтрацией битпланов по маске)
test_rndframeshift.scl - случайное перемешивание 16 фреймов с разным порогом (почему-то выглядит хуже, шевеление медленнее)
test_rndxyframeshift.scl - то же, но к random прибавлено x+y (разницы с предыдущим не видно)
test_xyframeshift.scl - вместо шума только pixel > (frame+x+y)&0xf
test_chunk.scl - стандартные чанки вместо x+y (выглядит не очень чисто - появляются полоски)
test_woolchunk.scl - шумовые чанки вместо x+y (выглядит лучше всего), смотрибельно даже при переключении за 3 фрейма
        pixel > frame+achunkpixelnumber[pixelnumber])&0x0f

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

        
Как посчитать эту формулу в realtime? желательно ещё с регулировкой яркости
frame+achunkpixelnumber[pixelnumber] можно заменить на achunkpixelnumber[frame, pixelnumber] и даже вбить в иннелуп константами

Сравнение по 1 пикселю - медленно
таблица сравнения: scrpixel = achunkscrpixel[pixel(4), frame(4), pixelnumber(4)] - итого адрес 12 бит
сделать сразу несколько пикселей по такой таблице не получится
блок из 8 пикселей = 32 бита
но реально frame+pixelnumber = 4 бита захардкоженных, так что адрес 8 бит - можно брать по 2 пикс.

а) pixel > frame+achunkpixelnumber[pixelnumber])&0x0f
;8 пикселей abcdefgh полностью перепутаны - рисовать в такой экран неудобно
        pop bc ;%ccccggggddddhhhh
        ld l,b
        ld b,framepluspixelnumber1
        ld h,framepluspixelnumber2
        ld a,(bc) ;%d000h000
        rrca      ;%0d000h00
        or (hl)   ;%cd00gh00
        rrca      ;%0cd00gh0
        pop bc ;%aaaaeeeebbbbffff
        ld l,c
        ld h,framepluspixelnumber3
        or (hl)   ;%bcd0fgh0
        rrca      ;%0bcd0fgh
        ld l,b
        ld h,framepluspixelnumber4
        or (hl)   ;%abcdefgh
        ld (de),a
        inc e (d?)
;111 t/b (можно 99 t/b без rrca, если 4 копии таблиц, итого 16К, с удобным порядком пикселей)
в части случаев ещё ускорение за счёт inc/dec h вместо ld h
можно захардкодить смену яркости через те же таблицы, но брать таблицы в другом порядке?

без яркости процедуры вывода займут немного (16 фреймов по 4 неполных строки 19- или 22- b/b, итого можно 1.5К)
сам экран займёт 24К, надо в верхней памяти, иначе вся нижняя память занята экраном+таблицами
на 48К можно сделать с неудобным порядком пикселей генерацию экранов (т.к. хранить экраны негде), например, 3D рендер (а как компактно хранить сцены? для мешей и текстур места точно нет, но в древности делали 3D сплайны - как? ещё нужно прозрачность)

чтобы успеть за 3 фрейма, надо 34 t/b, а у нас тут получится 8(с неудобным порядком 10) фреймов! при этом видно прорисовку, надо обновлять полосками или псевдослучайными квадратиками?

на 128К можно на 2 экранах сделать R-Mode или просто 4 цветовых слоя, тогда обновление будет за 16 фреймов, зато в полном цвете (4R+4G+4B+4w)
какой рисунок чанков для R-Mode? просто растянуть 4x4 по вертикали вдвое, а на другом цветовом слое пускать текстуру чанков (можно и номер фрейма - но не только номер фрейма) в другой фазе? По идее для шумовых чанков это не сильно испортит рисунок
можно просто обычную штриховку на обычном R-Mode, всё равно там всё на чёрном фоне

или можно на 128К неполный цвет: два слоя 4R(M)+4G за 8 фреймов без мерцания, при старом рисунке штриховки.
или можно на 128К без мерцания за 12 фреймов (на Таймексе за 8 фреймов, на 128К можно и за 2, если просто перебрасывать экраны, которые займут 96К+6..12К перебросчик, в зависимости от соотношения количеств pop:ld (),hl и LDI) ТЖРИ слоя 4R+4G+4B, в следующем порядке (половина процессорного времени в экране свободно, т.е. под c2p свободно 48000 тактов), при старом рисунке штриховки:
 первая знакоместная строка:
- R screen1 (c2p)
- G screen0, обновляем атрибут screen0
- B screen0, обновляем атрибут screen0 (разрешается не успеть)
- R screen1 (c2p)
- G screen0, обновляем атрибут screen0
- B screen0, обновляем атрибут screen0 (разрешается не успеть)
- R screen1 (c2p)
- G screen0 (c2p)
 вторая знакоместная строка:
- B screen1 (c2p)
- R screen0, обновляем атрибут screen0
- G screen0, обновляем атрибут screen0 (разрешается не успеть)
- B screen1 (c2p)
- R screen0, обновляем атрибут screen0
- G screen0, обновляем атрибут screen0 (разрешается не успеть)
- B screen1 (c2p)
- R screen0 (c2p)
 и т.д.
Можно генерить 16 копий экрана прямо в 3D рендере (он будет в нижнем бордюре, а обновление за 3 фрейма)
 
для статичной картинки можно по 4 пикселя в байте (найти 256 нужных комбинаций) - это как минимум не хуже 64ц:
        pop bc ;4pix + 4pix
        ld l,b
        ld b,framepluspixelnumberRN
        ld a,(bc) ;%abcd0000
        or (hl)   ;%0000efgh
        ld (de),a
        inc e (d?)
;46 t/b (3 фрейма на экран), 16*2*256 = 8K таблиц, экран 12K - можно на 48K
как найти комбинации по 4 пикс (выбрать 256 из более 65536)? надо не просто рандомы - будет шум
надо как минимум набор плавных цветопереходов (17слева * 17справа = уже более 256!) и набор тёмных и светлых пятен разного размера на разных фонах в разных местах
ещё часто надо типа _/ или \_ (возможно, и /- или -\)
пройти по картинкам и найти частые? будет много близких! отсекать по уровню ошибки? причём как-то отдавать предпочтение вариантам без шумовых выбросов
или проще составить вручную?
начать с 17 базовых сплошных цветов, остальные искать автоматом
при нахождении лучшей комбинации из оставшихся учитывать близкие совпадения (с ошибками +-1 по всем осям) и удалять её (для поиска следующей лучшей) вместе с ними

б) фильтрация битпланов по шумовой маске - надо обязательно успеть за фрейм, иначе выглядит как каша (и даже за фрейм выглядит хуже, чем по таблице за 3 фрейма)
в каждом битплане один бит цвета (старший...младший)
маски составлены так, что вероятность единицы в N1 вдвое выше единицы в N2, а там вдвое выше, чем в N3, а там вдвое выше, чем в N4, а в сумме %11111111
???можно ли получить подобие чанковой штриховки???
за фрейм можно взять только один бит конкретного пикселя!!! так что так красиво, как по таблицам, не получится!

пусть у пикселя биты 3210, бит 3 берётся чаще всего (в половине случаев)
фрейм1:
3232
13.3
3232
.313
фрейм2:
2323
3.31
2323
313.
фрейм3:
313.
2323
3.31
2323
фрейм4:
.313
3232
13.3
3232
фрейм5:
3232
.313
3232
13.3
фрейм6:
2323
313.
2323
3.31
фрейм7:
3.31
2323
313.
2323
фрейм8:
13.3
3232
.313
3232
Если в точках бит0, то будет всего 9 уровней яркости вместо 16
Если в одной точке бит0, а другая всегда пустая, то не получится сумма %11111111
В одной точке бит0, а в другой бит3?


[        pop bc
        ld a,c
        and N1
        ld c,a
        ld a,b
        and N2
        or c
        ld (hl),a
        pop bc
        ld a,c
        and N3
        or (hl)
        ld c,a
        ld a,b
        and N4
        or c
        ld (de),a
        inc e
;105 t/b]
[или
        ld a,(hl)
        inc l
        and c;N1
        ld d/e,a
        ld a,(hl)
        inc l
        and b;N2
        or d/e
        ld d/e,a
        ld a,(hl)
        inc l
        and N3
        or d/e
        ld d/e,a
        ld a,(hl)
        inc l
        and N2
        or d/e
        ld d/e,a
        1/2*push de
;99.5/105.5 t/b]
[или
        ld a,(hl)
        inc l
        xor (hl)
        and c;N1
        xor (hl)
        inc l
        xor (hl)
        and b;N2
        xor (hl)
        inc l
        xor (hl)
        and N3
        xor (hl)
        inc l
        ld d/e,a
        1/2*push de
;89.5 t/b (and e...push af:inc sp не даст выигрыша, а 16 копий полных экранов ld (...),a нереально по памяти)]
или
        pop bc
        ld a,c
        xor b
        and l;N1
        xor b
        pop bc
        xor c
        and h;N2
        xor c
        xor b
        and N3
        xor b
        ld (de),a
        inc e
;74 t/b (можно 73 t/b, если and e...ld (...),a)
