How would you create a random number generator that doesn't depend on anything but ASM instructions?
Posted on 2003-01-04 18:14:54 by CyberGuy
Search the board and post in the correct forum next time. Thanks.
Posted on 2003-01-04 18:31:58 by bazik
Install the MASMv7 package from www.movsd.com and look into \MASM32\OOP\CSprite\random.inc

aweX <-
Posted on 2003-01-06 03:52:38 by aweX
CyberGuy,

Maybe not %100 what you wanted, but look at the example:

http://www.asmcommunity.net/board/index.php?topic=8556&highlight=Random+algorithm+for+small+numbers

Regards,

Vortex
Posted on 2003-01-06 04:25:15 by Vortex
Smallest + simplest way I know (16 bit):


in al, 0x40
xadd [si], ax

(si -> seed / accumulator)

See it in action at http://www.stud.uni-karlsruhe.de/~urkt/flames.com :)

HTH
Jan
Posted on 2003-01-06 05:21:49 by Jan Wassenberg
This one works fine.


; #########################################################################
;
; Park Miller random number algorithm.
;
; Written by Jaymeson Trudgen (NaN)
; Optimized by Rickey Bowers Jr. (bitRAKE)
;
; #########################################################################

.486 ; create 32 bit code
.model flat, stdcall ; 32 bit memory model
option casemap :none ; case sensitive

.code

; #########################################################################

nrandom PROC base:DWORD

mov eax, nrandom_seed

xor edx, edx
mov ecx, 127773
div ecx
mov ecx, eax
mov eax, 16807
mul edx
mov edx, ecx
mov ecx, eax
mov eax, 2836
mul edx
sub ecx, eax
xor edx, edx
mov eax, ecx
mov nrandom_seed, ecx
div base

mov eax, edx
ret

nrandom ENDP

; #########################################################################

nseed proc TheSeed:DWORD

.data
nrandom_seed dd 12345678
.code

mov eax, TheSeed
mov nrandom_seed, eax

ret

nseed endp

; #########################################################################

end

Regards,

hutch@movsd.com
Posted on 2003-01-06 05:27:26 by hutch--
Thanks, I'll try all your techniques.
Posted on 2003-01-06 17:35:54 by CyberGuy
Hello there!

I wonder what you people think of my random-generation function. Maybe somebody else did something similar, but honnestly, I did it all by myself. That's the reason why I ask some feedback :-)


getRnd32 PROC maxVal:DWORD
mov ecx, Rnd32Num
rcl ecx, cl ;the concept if just to mess around with the bit position...
jc @F

sub cl, 3 ;...this number is purely subjective. Can be anything else...
rcr ecx, cl
not ecx ;and here, it's to reduce the chances that I get the same sequence.

@@:
mov Rnd32Num, ecx ;I put back the number "generated" so I'll continue from there on the next call...
mov eax, ecx

xor edx, edx ;my prog crashed before I put this line... Taken from hutch-- provious post...
div maxVal

mov eax, edx
ret
getRnd32 ENDP


Now you must assume this:
-Rnd32Num is a DWORD value defined by another function (similar to a "seed" function)
-maxVal is the maximum value you want to have as the random number


I did a little program similar to NaN's to test my function. Here is a sample:



...so, what do you think?

Thanks!
Posted on 2003-01-11 12:54:23 by dotCODE
...and sorry for the typos...
Posted on 2003-01-11 12:55:36 by dotCODE
If you can, post full screen shots of your generator at work (256 colors). Using three random values (x,y, color).

Your above images look good, but the scope is too narrow to notice any patterns. If you 'zoom' out to full screen you may or maynot see 'textured' patterns. If you dont, you got a winner :alright:

Theory goes, if you have a truely random generator, over a very large amount of samples, the mean (average) should be 50% the random # range. ie) 0->1 = 0.5 mean.

So where does the picture come in? Well, your painting a range of colors 0-256, in pixels all over the screen. Your true 'random' center would be 128 for red, green, and blue. So zomin out, and looking at the overall image. If you see a 50% greyish 'overall look' to the screen (dispite that pixels may definitely not be grey), with no clear patterns in the image your generator is very close to truely random ;)

Hope this helps..
:alright:
NaN
Posted on 2003-01-11 13:18:17 by NaN
Hi NaN, glad to have a reply from you :-)

I admit that 16x16 grid with 20 different colors is not a big test... If it's ok with you, I'll try to slip my random function in the directDraw prog you did (I'll try to find the thread, I don't remember where you post it :-( )
Posted on 2003-01-11 13:43:08 by dotCODE
Looking at your above 16x16 post. Another test is the mean percentage of all the color 'bins' should be equal to the 1/Number of bins == 0.05 or 5%

Your example has an average percent: 4.95%

The other example is: 5.10 %

From the example show, your is better with 5% error to 10% error.

But the 'big' picture is truely the best way to test. Your example may be very random over small ranges, but then repeat alot in larger scales...

Just somethings to think about ;)
:alright:
NaN
Posted on 2003-01-11 15:22:20 by NaN
Looks like you're right again ;-)

I did what I mentionned before (I put my algo in your ddraw demo):



To the left, my code
To the right, Park Miller algo

I don't know how to interpret this. I don't see an obivious pattern, even at 1280x1024.
But looks like it simply do not generate some numbers - probably the reason why there is so many black pixels.

I think I'll go back to my books ;-)
Posted on 2003-01-11 17:22:16 by dotCODE
There is probabaly a strong patter occouring, but i could be wrong.

The way to tell if fill the screen first with one solid color (say black), and then have the random generator only randomize from color 1 to 255 (no black color pixels added... At the end, there should be no black left. If there is alot, then there is a repeating pattern happening for co-ordinate generation, and consiquently for color generation as well.

NaN
Posted on 2003-01-11 21:35:56 by NaN
Here's the link to Whiz Kid's page. His RAND asm source draws random color, random size rects. One of the first 32-bit Windows ASM examples ever! :)

http://www.geocities.com/SiliconValley/Heights/7394/
Posted on 2003-01-12 06:18:26 by S/390