Using Allegro 5, is there an effective way to generate a random number besides using "srand(time(NULL)?"

Sorry I took so long to reply, but I just got back from reading the manual. There are no random number generating functions in it.

By the way, srand() is how you seed the RNG. rand() is how you generate a random number.

There are various third party libraries for random number generation if you dislike the flawed rand() & require something truly random.

www.google.com

I have some code I got from somewhere many years ago. It's very simple code and obviously not going to be "truly random" (I don't think anything can be to be honest). But it's handy if you want your code to be portable. Give then same seed it will generate the same sequence of numbers, which is what I originally wanted.

unsigned long rng_seed;
unsigned long rng (void) {
  return ((rng_seed = (rng_seed+1)*314159265L) >> 16) & 0xFFFF;
}

// use it something like this
rng_seed = (unsigned)time(NULL);

for (i=0; i<100; i++)
   printf("%d\n", rng()%100);

As I said, probably the simplest of random functions you'll ever see, but it works and it's portable.

Well of course, but rand() is not serious.. It has very visible patterns, in certain cases bit too predictable.

Append:
Seems like nice code, could be used quite well in some short-on-libraries place

You could always try the Mersenne Twister or rip the drand48 functions from djgpp if your libs don't have it.

If you want truly random, you'll need a physical source of entropy: A sample of a radioactive substance would be perfect, but if you don't have any fissionable materials at hand, you can pick up pretty good noise from a radio (make sure you don't accidentally hit any actual signal though), or you could use a diode and make it 'leak' (that is, throw a high enough voltage at it to make it conductive in the 'wrong' direction; the conductivity will go on and off at fairly random intervals), etc.
For all practical purposes (except encryption) however, Mersenne Twister is good enough, and, most importantly, it's fast. The wikipedia article Arthur linked to has links to excellent implementations in C and C++ IIRC.

Fissile material sounds good.. /me went to buy few kg Pu-238 in the local flee market

But overall, as of random.. That is very much dependent on the degree of "randomness" required.. For brutal testing purposes, without care about performance various irrational numbers calculation & processing can be doing quite good I suppose.

Anyways.. Function that easily gives 15 even numbers in a row, but never gives 16 even numbers in a row is a poor randomizer. (that's the behavior of MSVS rand() )

I guess it would be very simple to design a small device, that wouldn't cost more than a few bucks, and you could place it inside your computer. Or connect to a USB port. And it could be supported by the system, or by some driver. It could receive white noise from the UHF band. Or it could have same radioactive stuff that common fire detectors contain. One could read say 64 random bits every nth millisecond.

I'm not sure software solution with access to the mouse wouldn't handle..

Pu-238 isn't fissile, and there's no need to use a fissionable isotope for a random number generator either.
</brain damage>

Wow. So either you read fast, or the manual is rather short...

@molang

Crap. And I was wondering why was it so cheap.

/me has gone to find someone could enhance my Pu with an extra electron..

This has come up in several threads here in the past, but the "it works" is questionable Run for example this code:

It outputs a rand.pbm which looks like this: http://allefant.com/allegro/rand.png

It's certainly a nice pattern, but not what you would normally call random.

The mersenne twister mentioned above is slightly more complex code (but not much) but you will have a much harder time coming up with a test case showing how it's not random

In addition to not being random, the rng() function above also has only 65536 different seeds. So if you generate e.g. a random map with 1000x1000 tiles, out of the 2^1000000 possible worlds you are limited to 2^16 worlds. With MT you could get 2^20000 or so different worlds.

You want it ionized?

Anyway. The Mersenne Twister is pretty much the standard "good" PRNG, and the reference implementation is BSD-licensed.

One other case where a good RNG is needed is any game with random "drops" in a huge catalogue of items, each one with a "drop rate". You'll really expect the item with 3/10000th to be less likely than the one with 5/10000th, and at this scale, bad RNGs will cause problems.

I want it fissile so that I can has TRUE randomness!

A decent operating system will have the /dev/random file, that you can read random numbers that are generated by the system running. It could be a useful source of randomness.

Sorry for derailing your derailing.

I thought it could be OS duty to provide the user with random bits.

Except in the situations where your program needs reproducible series : for demo-replaying, or in order to keep synchronized 2 instances of program over network.

It's different story.

The same seed will always produce the same sequence of random numbers AFAIK. So its just a matter of remembering the seed you used and passing it to the RNG.

RNGs have no seeds.

If you know that something is random, then wouldn't be random...

Yes, sorry, PRNG.

I propose the adoption of the term NPRNG (Non-Pseudo-Random Number Generator) to lift this old ambiguity.
Either it's pseudo-random, or it's non-pseudo random.

I wrote a C++ RNG library available at
https://sourceforge.net/projects/pracrand/

The Mersenne Twister, mentioned in previous posts, generally produces decent quality output at decent speeds. There are plenty of RNGs that produce better output at better speeds with much smaller state sizes & initialization times though.

Generally my default RNG is Bob Jenkins small fast PRNG:
http://burtleburtle.net/bob/rand/smallprng.html

Do we have to drag this out again?

{"name":"random_number.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/3\/83ad4bb68067b16d8072f66715c945bb.png","w":400,"h":144,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/3\/83ad4bb68067b16d8072f66715c945bb"}

I've used the GNU random number generator ones in scientific papers. They are open source (+1 for reviewers) and they are generally fast and effective. They are written in C and easy to link with

http://www.gnu.org/software/gsl/manual/html_node/Random-number-generator-algorithms.html

Wow, now that's a rare case here on A.cc:

The derailment of the topic actually has given relevant suggestions to the OP. Although it looks like he saw what we're talking here about and quickly ran away to the SDL library forums..

Append:
Is there some nice study with comparison and analyze of the "randomness" patterns of various libraries? What are the overall methods to analyze the even distribution, yet randomness.. ?

I'm not much of a fan of GSL, at least for RNG purposes:

1. I suppose you could list "open source" as a strength for it, but there's hardly any RNGs that aren't open source, and GSL has one of the most restrictive licenses out there for an RNG library (it's GPL; a lot of other RNG implementations are free for use even in closed source or non-viral software).

2. Its RNGs tend to be slow. The GSL RNG interfaces don't really allow ultra-high-speed RNGs, their algorithm choices tend to favor slow RNG algorithms, and their RNG implementations seem to be slow implementations as well. eg the GSL MT19937 implementation is 40% slower than my polymorphic MT19937 and 60% slower than my non-polymorphic MT19937 implementation.

3. Its recommended RNGs have various irregular output ranges, some of which are not even powers of 2, let alone nice powers of 2 like 2^8, 2^16, 2^32, or 2^64.

It does have some advantages of course - for instance GSLs support for various random number distributions is way better than mine, and their RNG algorithms tend to have better understood mathematical structures.

************************
edit:
type568:
Broadly methods of analysis fall in to two categories:
A. Theoretical analysis & proofs: basically, attempt to do mathematical proofs about the algorithms. The limitation is that only the simplest of algorithms can be analyzed unless the algorithm was specifically designed around the intended path of analysis. And any proof tends to be very limited in the scope of what it can say.
B. Empirical analysis: Basically, run the RNG and examine the output. The limitation is that only the simplest of flaws can be found. And it's not entirely clear how significant any flaw found really is to real world RNG users.
Though some methods are sort of hybrids of those two.

There are a number of libraries that perform empirical analysis on RNG output. I prefer my own (named Practically Random, see the link above) and TestU01. There is a NIST test suite is popular for that purpose, and RaBiGeTe is another entry in the field. There is also a classic named DIEHARD that is badly outdated and should not be used, but is still popular.

Thanks, downloading NIST..