Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Productions > Random Numbers
2003-01-29 18:32
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....
 
2017-03-04 19:18
xIII

Registered: Nov 2008
Posts: 210
Quote: no idea what kickass likes really :=) it must have some kind of modulo operator, i guess =P

mod(random()*9,9)+48 seems to work.

But it's no problem if the table assembles different everytime ;)
2017-03-05 10:32
chatGPZ

Registered: Dec 2001
Posts: 11360
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
2017-03-05 11:01
Perplex

Registered: Feb 2009
Posts: 255
Not to mention that using a random function to generate the table can result in *very* unevenly distributed sets of numbers.
2017-03-05 11:11
chatGPZ

Registered: Dec 2001
Posts: 11360
indeed. its also pointless - combining two random things does not really improve anything (often quite the contrary)
2017-03-05 16:11
enthusi

Registered: May 2004
Posts: 677
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.
2017-03-06 00:41
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.
2017-03-06 09:33
chatGPZ

Registered: Dec 2001
Posts: 11360
relying on the current value of A is really a bad idea.... (this has nothing to do with LFSR either....)
2017-03-06 09:49
tlr

Registered: Sep 2003
Posts: 1787
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.
2017-03-06 14:52
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.
2017-03-06 15:19
chatGPZ

Registered: Dec 2001
Posts: 11360
its not a LFSR because it is not a shift register in the first place =)
Previous - 1 | 2 | 3 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
serato/Finnish Gold
Rebok/BOOM!/Tropyx
Black Beard
Guests online: 130
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 The Demo Coder  (9.6)
7 What Is The Matrix 2  (9.6)
8 Uncensored  (9.6)
9 Wonderland XIV  (9.6)
10 Comaland 100%  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 Party Elk 2  (9.6)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.6)
5 Libertongo  (9.5)
6 Rainbow Connection  (9.5)
7 Onscreen 5k  (9.5)
8 Morph  (9.5)
9 Dawnfall V1.1  (9.5)
10 It's More Fun to Com..  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Nostalgia  (9.3)
5 Triad  (9.2)
Top Musicians
1 Rob Hubbard  (9.7)
2 Jeroen Tel  (9.7)
3 Mutetus  (9.7)
4 Jammer  (9.6)
5 Linus  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.074 sec.