| |
Dr. Jay
Account closed
Registered: Jan 2003
Posts: 32 |
Random Numbers
Just wanted to share. This has probably been discussed a million times, but in case it hasn't ... was doing a search for random numbers. Some of the old hardware tricks like $d800 don't work with specific versions of the machine and certainly not in all emulators. I found this snippet of code which, if I remember correctly, was from boulderdash:
random eor $dc04
eor $dc05
eor $dd04
adc $dd05
eor $dd06
eor $dd07
rts
Tried using it - I always test random numbers by using the sequence to plot pixels. If you have a bad generator, you can easily see patterns. I could tell this pattern above was clustering on byte-boundaries after watching a few minutes in the plotter. I felt like it was because it was synched too much to the timers and that something would have to throw it out. Then I started thinking about how stable rasters are a $#$@#$@$ and if the call to this routine doesn't always come on a stable raster then we'll have some cycles out of synch ... so I made this simple modification:
random lda #$00
eor $dc04
eor $dc05
eor $dd04
adc $dd05
eor $dd06
eor $dd07
sta random+1
rts
And it appears to work like a charm - much more random! Just uses a seed to feed into the timer sequence, rather than the timer sequence alone!
|
|
... 11 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
Quote:mod(random()*9,9)+48 seems to work.
now THAT makes no sentence whatsoever.... you are still using the random function =)
Quote:But it's no problem if the table assembles different everytime ;)
trust me, unless what you are doing is trivial, you always want code that can be tested in a way that the expected results do not change for each compile =P |
| |
Perplex
Registered: Feb 2009
Posts: 254 |
Not to mention that using a random function to generate the table can result in *very* unevenly distributed sets of numbers. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
indeed. its also pointless - combining two random things does not really improve anything (often quite the contrary) |
| |
enthusi
Registered: May 2004
Posts: 674 |
For my recent games I create a Rijndael sbox table which is surprisingly little code and the I generate pointers into it with a simple full width 8 bit lfsr. Thus I have no bit-correlations between calls. |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
prng:
inx
adc #157 ;lo-byte of seed
sta $fb
eor $fc
adc #17 ;hi-byte of seed
sta $fc
eor $fb
sta $0400,x
jmp prng
use two immediate values for seed, and two memory locations: $fb and $fc for processing. those are scrambled during each update by the xor and adc's. not done any diehard testing, but looks random to me. rule 30 produce randomness which is basically two boolean operators: or and xor on two inputs. i guess its the same what happens here. it is LFSR probable due to previous states of the accumulator. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
relying on the current value of A is really a bad idea.... (this has nothing to do with LFSR either....) |
| |
tlr
Registered: Sep 2003
Posts: 1702 |
Quote: For my recent games I create a Rijndael sbox table which is surprisingly little code and the I generate pointers into it with a simple full width 8 bit lfsr. Thus I have no bit-correlations between calls.
Doesn't this just give you a repeating sequence of 255 numbers? I would go for a longer LFSR. |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Quote: relying on the current value of A is really a bad idea.... (this has nothing to do with LFSR either....)
You are right Groepaz, its not linear, but it is dependant on its previous states, so I misread wikipedia: "a linear-feedback shift register (LFSR) is a shift register whose input bit is a linear function of its previous state."
Don't use accumulator then. The values are stored in memory. In this case accumulator is used only to generate the numbers. It have longer periodicity because it use two temp values (16-bit). This was meant as precalc. Doing this in without precalc may be used in special cases like this: 32 Bytes Fuzzy Logic but that uses another method. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
its not a LFSR because it is not a shift register in the first place =) |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
true true. i was wrong when i said it was LFSR. but would have been nice to find out what their logical differences are however. its just bit manipulation. some prng's ive made earlier use rol instead of lsr. |
| Previous - 1 | 2 | 3 - Next |
