A86: Re: Fast Random Number Generation

[Prev][Next][Index][Thread]

A86: Re: Fast Random Number Generation


A similar type of random number routine was used for the TI-85 version of
Joltima, but it screwed the game up badly and was replaced with Hideaki
Omuro's (the Crash guy) routine which works very well by using
self-modifying code.  The reason this style of routine didn't work with
Joltima is this:

When you're walking around, I had it keep getting a random number for each
step you take.  If the result was a 1, then the battle began.  Otherwise,
you kept walking.  Once a battle began, another random number was requested
to decide who you fight.  Now since using the R register and/or many other
'quick' random number methods gives you 'pattern' stylish random numbers,
Joltima would always get the same number after the 1.  See what I mean?  It
would keep getting numbers which are not 1's, and then someday it would
finally get a 1.  Immediately following the 1 was the same number everytime.
The result?  In the unfixed Joltima85, you fought the same enemies in every
battle!  YUCK!  I still got great e-mail comments from TI-85 players, but
they were sure missing out.  Imagine fighting the same battle while going
through one of the caves!  Anyways...

I mention this because I'm sure many potential RPG's and other type games
would use random numbers in this fashion.  To prevent game-destroying
patterns, use the built-in ROM routine.  It's VERY good, but slow.  In
David's case, he needs a fast random number so I suggest using Hideaki's
routine.  It's extremely quick.  I would put it in this post, but I don't
know if he wants it out.  I guess that was kind of dumb of me to suggest
using some code that isn't even available.  Go download the CrASH v1.5 shell
for the TI-82 and look at the readme file to get his email address and
contact him.

-Justin Karneges [Infiniti]

>I've been doing some experimenting to come up with a quick routine for
>random number generation.  The routine below (47t without ret) is what I
>have come up with.  The results are semi-random.  The same numbers keep
>coming up, as you'd expect considering it's pulling opcodes off rom pages,
>though the distribution seems fairly decent.  For my purposes, the actual
>number doesn't matter as long as the distribution works.  Attached is the
>skeleton program used to test the routine.  It just prints out six rows of
>random numbers in hex.
>
> Speed is important, I don't want it to take longer to generate a random
>number than it would to draw a sprite, as is the case with Mardell's
>generator from ZTetris when using a large numbers for A.  If speed didn't
>matter, I'd use his as it makes much better numbers than mine ;-)
>
>Any suggestions/improvements?
>
>; returns: a = psuedo random number
>RandomNumber:
>     ld a,r
>   ld b,a
>  add a,b
>  ld c,a
>  ld a,(bc)
>  ld c,a
>  ld a,(bc)
>  xor b
>  add a,c
>  ret
>
>--
>David Phillips <david@acz.org>
>http://www.acz.org/
>