[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 2002-09-04, Vincent <Vincent.Penquerch@xxxxxxxxxx> wrote:
> > Is rand() combined with srand() so unportable that allegro needs it's
> > own version? If it is, why does Peter not want it? I do think a random
> > number generator is a vital part of games programming so it would
> > belong in allegro, but I myself have never had problems using the libc
> > random generator. I would therefore support Peter that we
> > don't need it.
I dislike making up rationales, specifically because they're made up.
But...
1. General principle of post-2.x Allegro: If it can be in an addon, it
goes in an addon. RNGs are not even a borderline case.
2. General principle of my gut: Allegro has too much stuff, so keep out
even _more_ stuff (unless I'm proposing it, of course).
3. Pseudo-RNGs are a complex topic. I won't even try to pretend to have
a whiff of a clue about the theory, but AFAIK there is no "one size fits
all" solution. We could just pick one and incorporate it, but the user
can do that him/herself, easily, with the side-benefit of picking the
appropriate generator for the task.
> The important point is that the standard doesn't mandate the
> particular implentation of it, so you can't rely on a single
> seed to yield the same stream of numbers in different libcs.
> Which rules out nifty things you can do, eg to generate the
> same level on two different machines playing together just by
> transmittming the seed, having replay capability just by
> storing the seed and player/network input, etc).
4. I don't think the fictional Allegro-RNG would satisfy this either.
You would need a RNG that guarantees a specific sequence of outputs for
any particular seed -- for all eternity. That's very constraining, such
that even a buggy implementation can't be fixed without possibly
breaking someone's demo. If you need an RNG that definitely won't
change, I think you cannot avoid including it into your own code.
--
王浩禎