The problem I see with your approach is that it could lead to things seeming very deterministic and not-random. Since you will always pull out the same numbers in the same order, the only way you'll get any variation in your game is by changing the order in which things request random numbers, which I can think of many situations where that wouldn't happen leaving you with a scripted fight that goes the exact same way every time.
The only game whose RNG calculation I can speak to is Dragon View, and it does it like this:
Code: Select all
8187be jsl $80e3bc ;Subroutine assumes already in 8-bit A mode
80e3bd lda #$80
80e3c0 plb ;Switch to bank $80
80e3c1 lda $2137 ;Latch screen draw pixel position
80e3c4 lda $213c
80e3c8 lda $213c ;double read as it has a first/second-read flip-flop system (in $213F)
80e3cb pla ;second read is discarded
80e3cc adc $a5
80e3ce sta $a5 ;$A5 is the RNG variable. So add in the lo byte of horizontal scanline location
80e3d0 lda $213d
80e3d4 lda $213d ;same double-read business as $213C
80e3d7 bit #$01 ;test highest bit ($213C and $213D are allegedly 9 bits long)
80e3d9 bne _dontAddVerticalByte
80e3dc adc $a5
80e3de sta $a5 ;add in the lo byte of vertical scanline position IFF hi byte bit0 is not set.
80e3e0 bra _doneRNGCalc
80e3e3 lda $a5
Doesn't seem like the fastest code I've ever seen but it'll definitely make things nice and random provided your RNG routine isn't being called first thing in a frame or at a totally deterministic time. Generally speaking, if your joypad routine comes before your RNG calls just what the player is pressing at that moment should ensure enough randomness in the screen position by the RNG call. And since every time it adds into the previous number, it becomes basically impossible to get stuck in a situation where you keep seeing the same reactions.
Your proposal just kinda strikes me as a glorified version of this
, and while I can see the motivation for and the advantages of that method, I just don't feel like it'd be "random" enough...