ЭТЮДЫ

В 99% игр, где управление пойти вверх вниз вправо влево без диагоналей, при одновременном нажатии 2 клавиш срабатывает та что опрашивается раньше, меня это часто напрягало если нужно изменить направление резко надо помнить толи надо нажать точно, толи отпустить в зависимости от того куда в данный момент движется игрок. Раз уж занялся 3dgm решил сделать по нормальному. Может кому еще понравится идея

Код:

---

checkKey
                        ld        a, (oldKey)
                        ld        b, a
                        ld        a, (joyKey)
                        ld        (oldKey), a
                        ld        c, a
                        xor        b
                        ld        b, a
                        ld        a, (realKey)
                        ret        z
                        and        b
                        jr        nz, .s1
                        ld        a, c
                        and        b
                        jr        nz, .s2
.s1
                        ld        a, c
.s2
                        ld        (realKey), a
                        ret
joyKey                db        0
oldKey                db        0
realKey                db        0

---

Шынни, из той же оперы что всякие LFSR или LSFR не помню как он там называется, свою функцию он выполняет, он прост и его можно даже "железно" реализовать на простейшей логике, ждать от него звёзд с небес в отношении "случайности" я бы не стал...

Делал спрей для BGE, потребовался генератор случайных чисел. Два забраковал - не заполняли область, в конце концов откопал в интернете метод Фибоначчи с запаздываниями и пожертвовал буфером в 256 байт (можно меньше, но тогда медленнее будет) жалко, но зато работает как надо.
А один из прежних (забыл как обзывать) приспособил для заполнения буфера. Так на вшивость не тестировал, но в спрее раскидывает равномерно и заполняет полностью.

Код:

---

RNDF          ld hl,RNDbuff  ; начальное заполнение буфера для RND ; адрес буфера кратен 256
              ld c,0
1              ld a,r
              and #07
              ld b,a
              ld a,#35
.seed  EQU $-1
2              bit 0,a
              jr z,3F
              xor %01110000
3              rrca
              djnz 2B
              ld (.seed),a
              ld (hl),a
              inc l
              dec c
              jr nz,1B
              ret


RND    ; метод Фибоначчи с запаздываниями , использую буфер на 256 байт вместо 98 для удобства.
            push hl,de,bc
            ld de,RNDbuff+256-97  ; 97 a
.ia      EQU $-2
            ld hl,RNDbuff+256-33  ; 33 b
.ib      EQU $-2
            ld bc,RNDbuff          ; 0 i
.ii      EQU $-2
            ld a,(de)
            sub (hl)
            ld (bc),a          ; X[i]= X[i-a]-X[i-b]
            inc l
            inc c
            inc e
            ld (.ia),de
            ld (.ib),hl
            ld (.ii),bc
            pop bc,de,hl
            ret

---

Dart Alver, если уж делать большой буфер, то есть парочка вариантов поинтереснее:

Код:

---

rnd:        jp x0               

x0:
        ld a,x1       
        ld (rnd+1),a       
        ld a,(x1_n+1)
x0_n:        sub a,n
        ld (x2_n+1),a
        ret               
....
xn:
        ld a,x1       
        ld (rnd+1),a       
        ld a,(x0_n+1)
xn_n:        sub a,n
        ld (x1_n+1),a
        ret               


rnd:
        push hl
p0:        ld hl,ptr
        inc l
;        jr z, patch1
        mov a,l       
        ld (p0+1),a
        add a,ofs1       
;        jr z,patch2
        ld (p1+1),a
        ld a,(hl)       
p1:        ld l,n
        sub a,(hl)
        ld (hl),a
        pop hl       
        ret

---

Первый вариант тратит 14 тактов на jp/ret, 20 тактов на правку команды jp, и 33 такта на вычисления. На генерацию одного байта тратится 67 тактов, недостаток только в том, что каждый элемент массива заменён кодом размером 14 байт.
Второй вариант хорошо работает, если сделать 256 элементов в буфере, чтобы записывать новый элемент на место одного из старых, тогда вычисления займут 104 такта. Если нужен буфер конкретного размера, то можно либо добавить условные переходы на подпрограммы, которые будут править указатели и менять ofs1 на ofs2 и обратно при достижении указателями конца буфера, либо добавить только один из них, а подпрограммы чуть усложнить, чтобы они убирали первый условный переход и вставляли второй и наоборот, тогда вместо 14 дополнительных тактов при буфере на 98 элементов в среднем мы будем терять 10.

Куда уж поинтересней, jp/jr не быстрее?

Цитата:

---

Сообщение от Шынни

Куда уж поинтересней, jp/jr не быстрее?

---

Это меня малость переглючило, я забыл что для ret нужно не только код команды прочитать, но и два байта вытащить из стека, и считал что ret выполняется за 4 такта, поэтому в сумме у меня получилось 14 тактов вместо 20.

Перебор генераторов вида x(n)=x(n-m)-x(n-1) позволил найти парочку весьма симпатичных:
Первый получается при m=22, с длиной цикла 2^22-1, если в изначальном массиве не все числа чётные.
Второй получается при m=37, с длиной цикла 2^37-2^19-2^18+1, если в изначальном массиве только одно нечётное число.
Если забить на сохранение hl, для 8-разрядного генератора можно использовать вполне компактный код:

Код:

---

rnd8:        ld hl,buf-22
        ld a,(hl)
        inc l
        jr z,rnd_2
rnd_1:        sub a,(hl)
        ld (hl),a
        ld (rnd+1),hl
        ret
rnd_2:        ld l,-22
        jp rnd_1

---

Для 16-разрядного, при m=22, можно использовать вариант с 11 подпрограммами по 19 байт каждая + 3 байта на модифицируемую команду jp:

Код:

---

rnd16:        jp rnd_0

rnd_0:        ld hl,nn
        ld a,rnd_1
        ld (rnd+1),a
        ld a,(rnd_10+1)
        sub a,l
        ld l,a
        sub a,h
        ld h,a
        ld (rnd_0+1),hl
        ret
...

---

Замудреный код. окажись он по адресу $60FE и посыплется.

Цитата:

---

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

Код:

---

rnd:
        push hl
p0:        ld hl,ptr
        inc l
;        jr z, patch1
        mov a,l       
        ld (p0+1),a
        add a,ofs1       
;        jr z,patch2
        ld (p1+1),a
        ld a,(hl)       
p1:        ld l,n
        sub a,(hl)
        ld (hl),a
        pop hl       
        ret

---

---

Подставил в спрей с ofs1=-22, работает вродебы нормально, заполняет область целиком, прирост в скорости в моём случае не определяется вовсе, разве что экономия десятка байтов кода, хотя при буфере 256 b тоже не особо существенно но тем не менее ))
По поводу вообще... Я скажем так в гсч вообще 0.0, поэтому брал готовую формулу из интернета X[i]=X[i-a]-X[i-b] с рекомендованными значениями a=97, b=33. У вас немного попроще X[i]=X[i-a]-X[i-1] и в принципе для моей цели она вполне подошла, так что респект. ))

А тут что-то вы перемудрили - не работает ))

Цитата:

---

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

Код:

---

rnd8:        ld hl,buf-22
        ld a,(hl)
        inc l
        jr z,rnd_2
rnd_1:        sub a,(hl)
        ld (hl),a
        ld (rnd+1),hl
        ret
rnd_2:        ld l,-22
        jp rnd_1

---

---

Не понял логику в " rnd_1: sub (hl) " , когда l<>0. А результат - зацикливается гдето на десятке точек.

Цитата:

---

Сообщение от Dart Alver

А тут что-то вы перемудрили - не работает ))

---

Смысл всех переходов в этом коде, чтобы перезагрузить указатель на текущий элемент, если он дошёл до конца буфера, а адрес конца буфера должен быть кратен 256 байтам. Можно inc заменить на dec, а -22 на +22, чтобы buf указывал на начало буфера, но тогда буфер нужно увеличить на 1 элемент, поскольку 0й не будет использоваться. А так код вычисляет x[n]=x[n-1]-x[n-22] и записывает на место x[n-22]. Минимум данные вместе с кодом займут 40-41 байт, если делать буфер 256 байт, то можно выкинуть условный переход и выиграть 7 тактов.

ld (rnd8+1),hl