ЭТЮДЫ

[krt17]

В 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

[Advertiser]

[Vladson]

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

[Dart Alver]

Делал спрей для 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

[blackmirror]

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.

[Shiny]

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

[blackmirror]

Куда уж поинтересней, 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
...

[Shiny]

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

[Dart Alver]

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] и в принципе для моей цели она вполне подошла, так что респект. ))

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

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. А результат - зацикливается гдето на десятке точек.

[blackmirror]

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

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

[Reobne]

ld (rnd8+1),hl