random number generation (in asm)

[daxb]

Dice don't have perfect surface or shape, and this makes some results to come out many more often than others. Any RPG (not computer) player should know this

I know a guy with a yellow transparent 20 sided dice. It was incredible but he often threw two or three 1 in a row. Also the judge has a black 20 sided dice often threws the 1. We all feared that littel black dice. Maybe only subjective perception ourselves.

[meynaf]

Originally Posted by Thorham

Sure, but the pattern in which the numbers appear is still unpredictable, and you'll only be able to say that the chance that one number will show up will be higher than for a different number.

Of course i'm not able to say more than that, but it's enough to make it bad.

Originally Posted by Thorham

Partially. If you measure at every micro second, then you'll only get 20 bits, furthermore, humans click at a somewhat uniform rate. You don't take a second to click once, and the next time you take only a tenth of a second. This means that you'll likely end up with only 10 to 15 useful bits. And finally, because humans don't click that often, you end up with extremely little data. Not enough for certain applications.

But this "little data" is more than enough to generate an infinite sequence.

Originally Posted by Thorham

Although I certainly can't explain this, why would radio static be predictable anyway?

You're just reversing the question

Originally Posted by Thorham

Applications for which you need true random data, such as for gambling games where money is involved, for example. Hence the existence of hardware RNGs.

You'd probably be surprised to see how poor online gambling games are in that aspect...

Originally Posted by Thorham

No, only cryptographically strong PRNGs can be used for things such as encryption. There are quite a few very good PRGNs that are not cryptographically strong.

I have to see an example of this. All crypto code i've seen seemed to work well with relatively poor RNG.

Originally Posted by Thorham

Yes! The simple algorithm I came up with can benefit from such data. Those tables can be used for seeding. You can actually do all sorts of things with such data.

I didn't ask for some case where it is usable. I asked for one where it is needed.

And this is having a very limited number of seeds. Time is better for seeding.

Originally Posted by Thorham

To the human eye your algorithm doesn't produce any patterns, in fact my much simpler algorithm doesn't produce visible patterns, either. This of course doesn't mean that there are no patterns. The problem with your algorithm is that when you generate a table, say, for encryption, that the timers you're using will start to show regular behavior, because you're picking numbers at a regular interval. This means it's likely that your PRGN will be breakable. Only when you pick numbers at irregular intervals might the results be unpredictable.

And my RNG doesn't pick numbers at regular intervals. Interrupts (e.g. for multitasking) can interrupt it and make its result totally unpredictable.
Not to mention that instruction timing is complex enough to be difficult to predict (especially when cache misses occur). Predicting my RNG would need a cycle accurate emulation of the machine it runs on, while exactly knowing the initial machine state !
And this includes not only the CPU, but also the cias and the display HW (i'm reading beam couters, too).

Originally Posted by Thorham

Unpredictable PRGNs are used in cryptography, and they're more complex than yours, and even those can be broken, although it's extremely difficult. Actually, there are better PRNGs than yours that aren't secure.

"are used in cryptography" ! But what do you know about them or cryptography itself ???
You haven't seen any encryption code in your life, have you ?
I perhaps still have the sources of PGP somewhere. Maybe a good read...

Originally Posted by Thorham

Except that your generator isn't random at all to begin with. No algorithm is. With unfair dice, there is only the chance that a number will show up more often than another, the pattern in which the numbers appear can't be predicted, however.

When you mix timers, old seed, timestamp, beam counters and old value in the system data bus, then you're likely to not show patterns.

Originally Posted by Thorham

What I want to know is why you think your PRNG is so good?

Because most of them get one seed, then make fixed, predictable computations based on it, while mine re-reads timers on the fly.

Originally Posted by Thorham

I'm not a pen and paper RPG player, and I don't use dice, so I didn't know this. It still doesn't matter, because the pattern your numbers will appear in can't be predicted. While it's easy to see patterns in a small number of throws, let's try ten thousand throws. Even a hundred throws doesn't mean anything.

And a hundred computer generated random numbers - with irregular timing - don't mean anything either.

Originally Posted by Thorham

The timigs aren't completely predictable, but there are some regularities, and humans are so slow that the little bit of unpredictability generated doesn't matter much at all.

Humans are slow enough so that their irregularities generate high time differences from a machine's point of view. So in fact it's exactly the opposite of what you're saying.

Originally Posted by Thorham

No, you can't see it with the naked eye. My simple, three line algorithm already does that. Your algorithm is too simple to be unpredictable, even with the timers (when generating a table). The moment you call your PRNG regularly (which is the case when making a table), the timers will start showing highly regular behavior, and this means you have patterns. This applies to all algorithms, and your's is not an exception.

This is thinking that the machine has perfectly regular timings, and it is not the case. A difference of 1 unit here and there is enough to kill any predictability.

Originally Posted by Thorham

And indeed we don't know this. However, something like radio static is for all intents and purposes truly random, and can't be predicted. There are simply physical events that can't be predicted. If the universe is deterministic than we still can't because we don't know how. Algorithms can always be predicted, although for a certain class of PRNGs this is incredibly difficult.

It may sometimes become so difficult that predictibility is just killed.
And you needn't extremely complex algorithms to achieve this.

Originally Posted by Thorham

It is partially, and it's only of use if this data is collected freaquently enough.

It's not a matter of frequency, but a matter of regularity.
If timing variations are higher than the timer's resolution, then it's enough - and it is the case.

Originally Posted by Thorham

I can't test it, because I'm not a crypto analyst, but I find it extremely unlikely that your algorithm is cryptographically secure (it's too simple).

Being simple doesn't mean being inefficient. Too bad there is no good rnd analyst here

Originally Posted by Thorham

Here's some further reading on the subject: computers are lousy random number generators.

Indeed. It explains things better than i would. Yes, man, the user is outside entropy

Originally Posted by daxb

I know a guy with a yellow transparent 20 sided dice. It was incredible but he often threw two or three 1 in a row. Also the judge has a black 20 sided dice often threws the 1. We all feared that littel black dice. Maybe only subjective perception ourselves.

Then play games where you need to make a high value to hit
Oh, well, ok. I knew of a guy who was said to be often throwing 20's at first try, regardless of the used die...

[Thorham]

Originally Posted by meynaf

Of course i'm not able to say more than that, but it's enough to make it bad.

It's bad for the dices usual purpose, but for random number generation it's not necessarily bad, because the data can be processed to remove the bias.

Originally Posted by meynaf

But this "little data" is more than enough to generate an infinite sequence.

You assume it is, but has to be proved (which I'm not asking you to do). The problem is that when you encrypt data with this, that there may still be patterns that you don't know of. Again, this has to be proven.

Originally Posted by meynaf

You're just reversing the question

That's how it looks, I know. The point is that I personally can't think of a reason why it wouldn't be random.

Originally Posted by meynaf

You'd probably be surprised to see how poor online gambling games are in that aspect...

Yes, some are, but I'm not talking about the bad ones, and it's not limited to computers. A lottery is a good example of using true RND generators.

Originally Posted by meynaf

I have to see an example of this. All crypto code i've seen seemed to work well with relatively poor RNG.

Strong crypto algorithms are concerned with being extremely hard to break, they don't have to produce good all purpose RND data. General purpose RNGs, like your own, are usually much more suited for general cases, but are often not good for encryption.

Originally Posted by meynaf

I didn't ask for some case where it is usable. I asked for one where it is needed.

That's simple, it's not necessarily needed It is still usful however.

Originally Posted by meynaf

And this is having a very limited number of seeds. Time is better for seeding.

Except that you calculate a 32 bit seed (from what I've seen), and this is also very limited.

Originally Posted by meynaf

And my RNG doesn't pick numbers at regular intervals. Interrupts (e.g. for multitasking) can interrupt it and make its result totally unpredictable.
Not to mention that instruction timing is complex enough to be difficult to predict (especially when cache misses occur). Predicting my RNG would need a cycle accurate emulation of the machine it runs on, while exactly knowing the initial machine state !
And this includes not only the CPU, but also the cias and the display HW (i'm reading beam couters, too).

But it needs proof. You're assuming the output is completely unpredictable. You have a point, but it's not enough, I'm afraid.

Originally Posted by meynaf

"are used in cryptography" ! But what do you know about them or cryptography itself ???
You haven't seen any encryption code in your life, have you ?
I perhaps still have the sources of PGP somewhere. Maybe a good read...

I actually have. I've been reading up a little on the subject. Check out the SHA-2 algorithm here: SHA-2.

Originally Posted by meynaf

When you mix timers, old seed, timestamp, beam counters and old value in the system data bus, then you're likely to not show patterns.

Perhaps, but It still needs checking.

Originally Posted by meynaf

Because most of them get one seed, then make fixed, predictable computations based on it, while mine re-reads timers on the fly.

Okay, but is that really very good?

Originally Posted by meynaf

And a hundred computer generated random numbers - with irregular timing - don't mean anything either.

What I mean is that you need a very large number of die throws to be able to say things about the output.

Originally Posted by meynaf

Humans are slow enough so that their irregularities generate high time differences from a machine's point of view. So in fact it's exactly the opposite of what you're saying.

No The point is that this data doesn't cause much influence. You can generate thousands of numbers in between clicks. If you would only use click times, then the RND numbers will be predictable.

Originally Posted by meynaf

This is thinking that the machine has perfectly regular timings, and it is not the case. A difference of 1 unit here and there is enough to kill any predictability.

Do you have proof?

Originally Posted by meynaf

It may sometimes become so difficult that predictibility is just killed.
And you needn't extremely complex algorithms to achieve this.

Perhaps not, but in every case it has to be proven if it's to be used in encryption.

Originally Posted by meynaf

It's not a matter of frequency, but a matter of regularity.
If timing variations are higher than the timer's resolution, then it's enough - and it is the case.

Perhaps. I think I'll generate a table of seed data with your seed algorithm, and I'll just check that.

Originally Posted by meynaf

Being simple doesn't mean being inefficient. Too bad there is no good rnd analyst here

The algorithm without the timer input is probably too simple for encryption. And it's indeed bad that there are no experts on the field here

By the way, sorry for all the proof stuff, but the problem here is that it's very difficult to prove this kind of thing.

[TCD]

No offense meynaf and Thorham, but do you really need to make another excessive multi-quote thread? These are just a pain to read Maybe there's a way to post just what you want to say, instead of quoting each line individually.

[Thorham]

Meynaf, I've generated a nice image based on your seeding algorithm. Simply by calling it in a loop and copying the seed to a table and converting the data to an image. The image is in the zone.

When you see this image, you'll notice the high regularities immediately. Note that mouse clicks aren't included because I didn't click anything while generating the table, but as you'll see, it wouldn't have mattered that much anyway.

The problem isn't just limited to regularities. Another one is that your seeding algorithm might be unable to produce all possible seeds. I think you should try and change this seeding algorithm.

Originally Posted by TheCyberDruid

No offense meynaf and Thorham, but do you really need to make another excessive multi-quote thread? These are just a pain to read Maybe there's a way to post just what you want to say, instead of quoting each line individually.

Perhaps, but only if this is preferred by most people. Personally I don't like it too much, though, and I'm a big fan of the quote function.

[meynaf]

Originally Posted by Thorham

It's bad for the dices usual purpose, but for random number generation it's not necessarily bad, because the data can be processed to remove the bias.

This is pretending to know the bias well enough, but with random stuff you never know

Originally Posted by Thorham

You assume it is, but has to be proved (which I'm not asking you to do). The problem is that when you encrypt data with this, that there may still be patterns that you don't know of. Again, this has to be proven.

Encryption doesn't need large amount of random ; 256 bits are more than enough and patterns are much less likely for small amounts.

Originally Posted by Thorham

That's how it looks, I know. The point is that I personally can't think of a reason why it wouldn't be random.

Like you said, this has to be proven

Originally Posted by Thorham

Yes, some are, but I'm not talking about the bad ones, and it's not limited to computers. A lottery is a good example of using true RND generators.

But here we're talking about computers.

Originally Posted by Thorham

Strong crypto algorithms are concerned with being extremely hard to break, they don't have to produce good all purpose RND data. General purpose RNGs, like your own, are usually much more suited for general cases, but are often not good for encryption.

Encryption only needs a key and this is relatively small data (see above).

Originally Posted by Thorham

Except that you calculate a 32 bit seed (from what I've seen), and this is also very limited.

Limited, but not even necessary. My random generator could work well even without a seed. In other words, same seed won't generate same sequence.

Originally Posted by Thorham

But it needs proof. You're assuming the output is completely unpredictable. You have a point, but it's not enough, I'm afraid.

See below about proof.

Originally Posted by Thorham

I actually have. I've been reading up a little on the subject. Check out the SHA-2 algorithm here: SHA-2.

You've been reading on the subject, but this page says nothing about random used, and you apparently haven't seen much code...

Originally Posted by Thorham

Perhaps, but It still needs checking.

Just do it ;-)

Originally Posted by Thorham

Okay, but is that really very good?

Very good, perhaps not, but better certainly.

Originally Posted by Thorham

What I mean is that you need a very large number of die throws to be able to say things about the output.

But usually less than for a computer RNG.

Originally Posted by Thorham

No The point is that this data doesn't cause much influence. You can generate thousands of numbers in between clicks. If you would only use click times, then the RND numbers will be predictable.

Click times are used as SEED and nothing more.

Originally Posted by Thorham

Do you have proof?

No. But you don't have the opposite proof either.

Originally Posted by Thorham

Perhaps not, but in every case it has to be proven if it's to be used in encryption.

See below for proof (again ).

Originally Posted by Thorham

Perhaps. I think I'll generate a table of seed data with your seed algorithm, and I'll just check that.

It's not a good idea to use the seed alone. It's not made for that.

Originally Posted by Thorham

The algorithm without the timer input is probably too simple for encryption. And it's indeed bad that there are no experts on the field here

See above about encryption (ahem ).

Originally Posted by Thorham

By the way, sorry for all the proof stuff, but the problem here is that it's very difficult to prove this kind of thing.

It's not mine to make the proof, but yours in fact. You say it is predictable, so prove it.

Originally Posted by TheCyberDruid

No offense meynaf and Thorham, but do you really need to make another excessive multi-quote thread? These are just a pain to read Maybe there's a way to post just what you want to say, instead of quoting each line individually.

Alas this is right, but how to do otherwise ?

Frankly if i could avoid this multi-quoting, i would do it.
But how to answer a message point-per-point without doing so ?

My "see above" and "see below" will try to reduce the number of quotes nevertheless. Now Thorham has to follow...

Originally Posted by Thorham

Meynaf, I've generated a nice image based on your seeding algorithm. Simply by calling it in a loop and copying the seed to a table and converting the data to an image. The image is in the zone.

When you see this image, you'll notice the high regularities immediately. Note that mouse clicks aren't included because I didn't click anything while generating the table, but as you'll see, it wouldn't have mattered that much anyway.

The problem isn't just limited to regularities. Another one is that your seeding algorithm might be unable to produce all possible seeds. I think you should try and change this seeding algorithm.

But the purpose of the seeding algorithm isn't to give perfect random. Nor does it need to give all possible seeds. It's still much better than just using the actual timestamp as seed !

Now do your image again with both the seeding algorithm called once at startup and the normal random generator (this time posting your image generation code as well). Then we'll see.

[Thorham]

I'll keep this short, because my knowledge on this subject is too limited (should be highly apparent ).

Originally Posted by meynaf

But the purpose of the seeding algorithm isn't to give perfect random. Nor does it need to give all possible seeds. It's still much better than just using the actual timestamp as seed !

Now do your image again with both the seeding algorithm called once at startup and the normal random generator (this time posting your image generation code as well). Then we'll see.

If you've taken a look at the image I've made based on data used by your seeding algorithm, then you'll clearly see the high regularities of those timers, and this is exactly what I'm trying to say. In your PRNG you're using timers to influence the data. Because those timers are in fact not random as shown, your PRNG will not produce true random data as far as I can tell.

[Maccara]

meynaf, you should look up "entropy extraction" (active field of study).

I don't think your timer-shuffling would stand up to scrutiny, if we consider cryptographically secure algorithms - however I'm far from an expert on the subject matter myself so can't claim anything specific.

There are some tests which have to be met at minimum (next-bit test and state compromise extensions at least - can't remember others for now) for an algo to be even considered secure.

[meynaf]

Originally Posted by Thorham

I'll keep this short, because my knowledge on this subject is too limited (should be highly apparent ).

Heheh

Originally Posted by Thorham

If you've taken a look at the image I've made based on data used by your seeding algorithm, then you'll clearly see the high regularities of those timers, and this is exactly what I'm trying to say. In your PRNG you're using timers to influence the data. Because those timers are in fact not random as shown, your PRNG will not produce true random data as far as I can tell.

But what is "true random" ?

It just needs to be statistically balanced, and unpredictable. So far it is.

Of course i've seen the image, but the seed generator doesn't need to be a rnd generator itself. It's just here to add a few more noise.

Originally Posted by Maccara

meynaf, you should look up "entropy extraction" (active field of study).

I've extracted entropy whereever i could find some in the Miggy already.

Originally Posted by Maccara

I don't think your timer-shuffling would stand up to scrutiny, if we consider cryptographically secure algorithms - however I'm far from an expert on the subject matter myself so can't claim anything specific.

I'm not only using timers. They're just used to add noise (entropy).

Originally Posted by Maccara

There are some tests which have to be met at minimum (next-bit test and state compromise extensions at least - can't remember others for now) for an algo to be even considered secure.

Do you have some links on the subject ?

[Thorham]

Originally Posted by meynaf

Heheh

Indeed It's perhaps useful to read up on this subject.

Originally Posted by meynaf

But what is "true random" ?

Perhaps this: 'Without any patterns that can be recreated with an algorithm or otherwise, except by chance", or something along those lines.

Originally Posted by meynaf

It just needs to be statistically balanced, and unpredictable. So far it is.

Is it truly? There are different kinds of tests you can run.

Originally Posted by meynaf

Of course i've seen the image, but the seed generator doesn't need to be a rnd generator itself. It's just here to add a few more noise.

What I meant here is that you're using timers that are regular in the PRNG itself, and this will lead to patterns if you create a table. Of course this setup is perfectly fine if the numbers are generated at irregular intervals.

Originally Posted by meynaf

I've extracted entropy whereever i could find some in the Miggy already.

And that's a problem for creating true random numbers. The Amiga's timings are still too regular.

Anyway, as long as you don't say that your RNG produces true random data, it's fine with me. You see, the amount of chaos you can create with the simplest of algorithms is fantastic. Even my simple three line algorithm does that (and is highly regular, except to the naked eye). The problem is making it truly random with out normal hardware RNGs.

[Maccara]

Originally Posted by meynaf

Do you have some links on the subject ?

Something I had "on-hand":
next-bit test stuff: http://www.scientiairanica.com/PDF/A...3/eghlidos.pdf
attacks on prng in general, including state compromise extensions: http://www.schneier.com/paper-prngs.pdf

EDIT: One interesting thesis article, which gives good and simple background for estimating entropy (in chap 3) and all that - could be adapted to evaluate your algorithm. Discusses the problem of finding proper source of randomness with enough data on a limited platform.
http://is.muni.cz/th/39510/fi_d/dissertation_thesis.pdf

Lots more (published papers on the subject) can be found if you go google.

I'm not personally qualified (or interested enough) to judge their merits, so I leave that as an exercise for the reader.

Just saying, that if someone wants to seriously make a cryptographically secure prng, there's some work to be done by the author before anyone will even bother to take a look at it seriously, and it is definitely not enough to just claim: "because I say so - there's the code, check yourself"[heavily paraphrased].

EDIT2: Please, do not take this the wrong way. The algorithms proposed are probably quite good enough for all "intended purposes". I just budded in as I saw claims on security without any qualifiers. If I can provide at least useful information what to look for, I'm happy.

[meynaf]

Originally Posted by Thorham

Perhaps this: 'Without any patterns that can be recreated with an algorithm or otherwise, except by chance", or something along those lines.

Then surely some PRNGs can apply ;-)

Originally Posted by Thorham

Is it truly? There are different kinds of tests you can run.

I think i will run a few of them !

Originally Posted by Thorham

What I meant here is that you're using timers that are regular in the PRNG itself, and this will lead to patterns if you create a table. Of course this setup is perfectly fine if the numbers are generated at irregular intervals.
And that's a problem for creating true random numbers. The Amiga's timings are still too regular.

Yet you might agree that it's perfectly suited for a game - that is, random fighting issues in it, and this was our original subject

Originally Posted by Thorham

Anyway, as long as you don't say that your RNG produces true random data, it's fine with me. You see, the amount of chaos you can create with the simplest of algorithms is fantastic. Even my simple three line algorithm does that (and is highly regular, except to the naked eye). The problem is making it truly random with out normal hardware RNGs.

To make something looking random, just compress something with a good data compressor : you'll get seemingly random data (apart headers, of course).

Originally Posted by Maccara

attacks on prng in general, including state compromise extensions: http://www.schneier.com/paper-prngs.pdf

I found this very interesting reading, even though a bit too academic for my taste.

Originally Posted by Maccara

EDIT: One interesting thesis article, which gives good and simple background for estimating entropy (in chap 3) and all that - could be adapted to evaluate your algorithm. Discusses the problem of finding proper source of randomness with enough data on a limited platform.
http://is.muni.cz/th/39510/fi_d/dissertation_thesis.pdf

But the problem is that Amiga isn't a cell phone. Nice reading nevertheless.

Originally Posted by Maccara

Just saying, that if someone wants to seriously make a cryptographically secure prng, there's some work to be done by the author before anyone will even bother to take a look at it seriously, and it is definitely not enough to just claim: "because I say so - there's the code, check yourself"[heavily paraphrased].

I won't do cryptographic applications on my miggy anyway.

Originally Posted by Maccara

EDIT2: Please, do not take this the wrong way. The algorithms proposed are probably quite good enough for all "intended purposes". I just budded in as I saw claims on security without any qualifiers. If I can provide at least useful information what to look for, I'm happy.

Nothing's really secure in our big bad world, and with random you never know (by definition), so...

[Thorham]

Originally Posted by meynaf

Then surely some PRNGs can apply ;-)

Of course, but many PRNGs are predictable (apparently), only the cryptographic algorithms are extremely difficult to crack.

Originally Posted by meynaf

I think i will run a few of them !

Yeah, you should.

Originally Posted by meynaf

Yet you might agree that it's perfectly suited for a game - that is, random fighting issues in it, and this was our original subject

More than good enough for a game. However, I'd still test your core algorithm (without the timers and a fixed seed) to see if it cycles too quickly (different seeds can yield different cycles). You might want to use it without timers for generating random dungeons that are the same for each seed value (ensures dungeons are the same across different machines), and for such reasons it's important that it doesn't cycle too quickly (can be slooooooow to test).

However, for game purposes your algorithm seems a little on the slow side:

1) It reads three chipset registers and that is somewhat slow. My solution to this is to use just one in combination with a small (16 kilobyte) true random table. The timer value is simply added to the offset of the table, and the value read from there is the value you add to the state of the RNG. Then you simply don't do this for every call, but for every few calls.

2) It uses a slow multiply.

3) It uses a very slow division for mod.

4) It's a little big to inline in a loop.

If you like optimized code, then you may want to look at these issues. My simple PRNG is only three lines, and can be inlined almost anywhere:

	rol.l	#7,d0
	add.l	d1,d0
	add.l	#$11111111,d1

You can easily add things such as timers to this and you'd still save a bucket load of cycles.

Originally Posted by meynaf

To make something looking random, just compress something with a good data compressor : you'll get seemingly random data (apart headers, of course).

Yes, but it's way to sloooooow

@Maccara: Very good reading, thanks

[modrobert]

Drifting slightly out of topic perhaps, but thought it might be a fun Amiga project; using a Geiger counter to seed random value via the serial port.

This adapter plugs into the digital out of the analog geiger counters and provides a random each time a radioactive particle is detected. The geiger counter is set up to read background radiation. The random numbers generated are truly random since they are based naturally occurring radioactivity.

The random number generate may be set to the following ranges:

Binary (1-2) Heads or Tails
Decimal (1-10)
1 Byte (1 - 255)
2 Byte ( 1 -65535)


The random number generator is compatible with analog meter geiger counters that use either an internal tube or a wand with shielded cable.

Typically, depending upon location, the generator will generate 20-40 random numbers per minute. TTL Serial Output Random numbers are sent out via a TTL serial port that may be interfaced to a micro controller or PC.
LCD Display 16 character by 2 line LCD (liquid crystal display) with back light provides easy to read output.

Source:
http://www.imagesco.com/geiger/analo...r-counter.html

The price is kind of steep, but it might also become useful when the atomic winter is upon us.

[meynaf]

Originally Posted by Thorham

Of course, but many PRNGs are predictable (apparently), only the cryptographic algorithms are extremely difficult to crack.

But cryptographic algorithms can be broken too (it's just a matter of computing power), so only the add of more entropy makes sense to me.

Originally Posted by Thorham

Yeah, you should.

But unfortunately all i've seen is using stupid float maths and never gives clear result.

Originally Posted by Thorham

More than good enough for a game. However, I'd still test your core algorithm (without the timers and a fixed seed) to see if it cycles too quickly (different seeds can yield different cycles). You might want to use it without timers for generating random dungeons that are the same for each seed value (ensures dungeons are the same across different machines), and for such reasons it's important that it doesn't cycle too quickly (can be slooooooow to test).

For random dungeons i'm using a different generator. The one you've seen REQUIRES the timer read.

Originally Posted by Thorham

However, for game purposes your algorithm seems a little on the slow side:

1) It reads three chipset registers and that is somewhat slow. My solution to this is to use just one in combination with a small (16 kilobyte) true random table. The timer value is simply added to the offset of the table, and the value read from there is the value you add to the state of the RNG. Then you simply don't do this for every call, but for every few calls.

2) It uses a slow multiply.

3) It uses a very slow division for mod.

4) It's a little big to inline in a loop.

If you like optimized code, then you may want to look at these issues. My simple PRNG is only three lines, and can be inlined almost anywhere:

 rol.l #7,d0
 add.l d1,d0
 add.l #$11111111,d1

You can easily add things such as timers to this and you'd still save a bucket load of cycles.

But exactly how many random numbers do you need to generate for a game ?
It's not enough for the RNG's speed to count much, unless it's several tens of times slower than mine.

Originally Posted by Thorham

Yes, but it's way to sloooooow

Speed isn't an issue here. It's for the example, not for practical use.

Originally Posted by modrobert

Drifting slightly out of topic perhaps, but thought it might be a fun Amiga project; using a Geiger counter to seed random value via the serial port.





Source:
http://www.imagesco.com/geiger/analo...r-counter.html

The price is kind of steep, but it might also become useful when the atomic winter is upon us.

If you have a good geiger you needn't wait for the atomic winter to get something out of it

[pandy71]

my advise... just use a Zener diode or special noise diode - they generate flat noise - amplify noise (additionial source of noise), convert to digital by some ADC (additional noise)...

[meynaf]

Originally Posted by pandy71

my advise... just use a Zener diode or special noise diode - they generate flat noise - amplify noise (additionial source of noise), convert to digital by some ADC (additional noise)...

I think i'll stay with pure software solutions

[pandy71]

small AVR uC (embedded ADC + communication) + very simple analog circuit can give truly random data - this can be difficult to beat in pure software way (if possible at all) - Amiga except paddle interface (it can give some limited randomness due of way how it works) is lack of ADC - this limit randomness...

[Thorham]

Originally Posted by meynaf

But cryptographic algorithms can be broken too (it's just a matter of computing power), so only the add of more entropy makes sense to me.

Sure, but the best cryptographic algorithms are currently not hackable on a practical level (takes too long to be of any use).

Originally Posted by meynaf

But unfortunately all i've seen is using stupid float maths and never gives clear result.

That sucks, but can't you at least use the math libs for float?

Originally Posted by meynaf

For random dungeons i'm using a different generator. The one you've seen REQUIRES the timer read.

Not from what I've seen, it seems to work fine without the timers. About that dungeon generating PRNG, could you post it, if you want?

Originally Posted by meynaf

But exactly how many random numbers do you need to generate for a game ?

Depends on the game

Originally Posted by meynaf

It's not enough for the RNG's speed to count much, unless it's several tens of times slower than mine.

I suppose so

Originally Posted by meynaf

Speed isn't an issue here. It's for the example, not for practical use.

Okay, but this example still is really slow, although it's a good example of how something may look random while it's not in any way random at all.

Originally Posted by meynaf

I think i'll stay with pure software solutions

They're the handiest, until you need true random numbers

Originally Posted by pandy71

small AVR uC (embedded ADC + communication) + very simple analog circuit can give truly random data - this can be difficult to beat in pure software way (if possible at all) - Amiga except paddle interface (it can give some limited randomness due of way how it works) is lack of ADC - this limit randomness...

Or a FM transistor radio connected to the input of a sound card. Costs only a tenner or so. The back draw is that you need some custom software to process the sampled data.

[pandy71]

Originally Posted by Thorham

Or a FM transistor radio connected to the input of a sound card. Costs only a tenner or so. The back draw is that you need some custom software to process the sampled data.

Amiga and input of sound card?

FM noise is not always random (some interferences can be quite regular)
Most modern FM receivers do auto-mute