--- TJ <comfortably_numb_@...> wrote:
> Nope, I haven't done this. Once you figured out how to reprogram the
> cart it
> might make for some useful hardware but you would also have to make a
> driver
> for it since it is a USB device. After all that I would still think
> the
> flash cart would be way more suited for developing on. It wouldn't be
> that
> much longer to flash the cart and you would have a normal sized cart
> to work
> with. The truth is if you are planning on making a program bigger
> than the
> ram on gba can handle you might as well spring for the flash cart and
> basically have no restrictions.

A really smart product would be a SRAM based cart.  A blank cart with
say 64Mbit of ram.  Put a small boot ROM and a bank swapper on it.

Then when you boot up the small ROM waits for you to send data and
stores it in the SRAM.  When its down it uses the bank switcher and
loads the program.

Advantage, super fast loading of the program [also less mucking with
hardware, e.g. you can write more times to it] and no stupid 256kb
program limit.  Also you would not wear your system too much by
removing/inserting the cart.

The cons:  A small 64mbit cart would probably cost 200$ US or so.  The
program won't stay when powered down, it will also consume more power
from the batteries.

Tom

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

Nope, I haven't done this. Once you figured out how to reprogram the cart it
might make for some useful hardware but you would also have to make a driver
for it since it is a USB device. After all that I would still think the
flash cart would be way more suited for developing on. It wouldn't be that
much longer to flash the cart and you would have a normal sized cart to work
with. The truth is if you are planning on making a program bigger than the
ram on gba can handle you might as well spring for the flash cart and
basically have no restrictions.

----- Original Message -----
From: "Dennis Munsie" <munsied@...>
To: <gbadev@yahoogroups.com>
Sent: Tuesday, April 30, 2002 2:36 PM
Subject: RE: [gbadev] USB upload cable


> Are you suggesting that you have done something like this or that you know
> of a way to do this, or are you just telling what would need to be done?
> Because the way it's worded, it appears that you are answering a FAQ :)
>
> Does anyone know anything about the internals on the game shark?  I
wouldn't
> mind picking one up for hacking with -- it's not too terribly expensive,
and
> having a USB interface would be kinda handy.  Also, depending on the size
of
> the flash, it could possibly be an 'expanded MBV2' cable -- you could
upload
> to the flash if you wanted to -- for those of us who don't think that 256k
> is that small ;)
>
> dennis

--- In gbadev@y..., porneL <pornel@w...> wrote:
>
> angle = atan2(enemy->x - player->x, enemy->y - player->y);
> dx = COS[angle];
> dy = SIN[angle];

?isn't there still a divide in that atan2 function?

> another idea to get normalized vector
>  while(dx>256 || dy>256) {dx >= 1; dy >= 1;}
>  // I assume 8.8 fixed point
>
>  its very inaccurate, but often enough for hooming missiles.

:) this is great thanks - it works fine, and the inaccuracy just
gives a little variation in bullet speed - very nice.
(another "now why didn't I think of that?" moment)

TYVM

col.

--- Andrew Scott <wargboy@...> wrote:
> tom st denis wrote:
> > Don't get me wrong guys, alot of your suggestions will work such as
> the
> > LCG or this LFSR.  So don't think I'm some sort of hard-case.  Its
> just
> > that I come from a crypto background and even for simulations I
> like to
> > have decent PRNGs.
>
> The old cliche "horses for courses" comes to mind. Not to disparage
> your crypto background but, realistically, we're talking about a
> games console here - will a philosophically correct PRNG make your
> game more fun than a less philosophically correct PRNG? Will the
> player actually notice any difference whatsoever? If you're making
> games then this is pretty much the only question you need to ask.
> (if you're not then rock on - do it right - and what are doing on
> an AGB that's not a game?)

I can imagine quite a few other uses for the GBA.  For example, a
portable packet radio terminal :-)

> > Considering this is a 32-bit RISC processor we are working with I
> think
> > we can step out of the age of single-state PRNGs.  I mean is it so
> > terrible that a PRNG take 200 bytes of ram?  Sure every little bit
> > counts but overall I doubt that will cause any problems.
>
> I dunno if you're doing commercial stuff but, if you are, then
> 200 bytes of RAM can be quite a price to pay just to get a psuedo
> random number here and there. Personally, I can think of better ways
> to spend my (very limited) RAM. If you've never run out of RAM then,
> by all means, rock on. If, one day, you find that you're out of RAM,
> maybe consider using a cheaper PRNG ;)

Yeah, I have to agree here.  Going over board is perhaps not the best
idea either.  Just whatever you do make sure you use the PRNG correctly
:-)  [e.g. avoid lsb of a LCG...]

Tom

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

> let it alone be the
> simple thing that a shift/eor thing most likely wont ever spit out a
> consecutive sequence of the same value (0,0,0,0,0...), which could
> very well happen with a real prng that passes all statistical tests.

Er.  They can?  That seems kind of ghetto.  Is there a reasonable way to
implement a class for PRNGs that can intercept bad initialization sequences
and prevent this sort of thing, or is that an unacceptable cost to the
randomness of the generator?  Alternately, is this maybe just not really
realistic?

> > what about this? works fine for me :o)
>
> Umm?  No?  This is known as a Linear Feedback Shift Register or LFSR

He wasn't saying that it was an LSB.  He was just saying that it was good
enough for him.

> Don't get me wrong guys, alot of your suggestions will work such as the
> LCG or this LFSR.  So don't think I'm some sort of hard-case.  Its just
> that I come from a crypto background and even for simulations I like to
> have decent PRNGs.

I'm tempted to go into a crypto newsgroup and start telling people that they
need to double buffer their screen writes, so that I can get the same
response there that you're getting here:

" ... what?  Why?"

One thing you'll find is that just like good crypto doesn't need
particularly smooth video updates, good games don't need 667-dimensionally
equidistributed pseudorandoms.  It's just overkill for a monster which can
move in any of five directions.

Here's a hint: the NSA is not employiong cryptanalysts to do major math to
find out what the probability is of Blue Zombie moving upwards.  Our
creature behavior does not need to be generated by one-time pad.

> Considering this is a 32-bit RISC processor we are working with I think
> we can step out of the age of single-state PRNGs.  I mean is it so
> terrible that a PRNG take 200 bytes of ram?  Sure every little bit
> counts but overall I doubt that will cause any problems.

It's 200 bytes you could be using for other things.  To quote Friday:
"There's principalities up in this motherfucker, Smokey!"  Besides, things
like processor cycle cost are pretty significant, too.  That LFSR appears to
be a branch, a barrel rotate, and sometimes an OR.  Wow: that's cheap.  (In
fact, thank you for reminding me of this, Groepaz - I'm a-gonna start using
it again.)

- Fatty, whose bathroom scale reads a twenty-twen-twen.

(Don't mess with my emotions... heh)

----------------

SEPERATE ISSUE:

It looks like I might be able to go to E3 on my poverty budget, after all.
Don't suppose anybody wants to accept a fraction of their hotel costs to
allow me to sleep on their floor, do they?  :)  (Yay, raver mentality...)

I'm such an idiot -- it turned out to be nothing that was suggested (though,
I do thank everyone for the responses :).  I was calling the swi from ARM
code -- and I was doing a swi 17.  I had forgot that the swi number had to
be shifted left 16-bits.  In thumb mode, swi 17 would've worked fine -- in
arm, it needs to be swi 0x110000

thanks to everyone who replied :)

dennis

-----Original Message-----
From: Alex Ganea [mailto:alex_toresh@...]
Sent: Monday, April 29, 2002 9:00 PM
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] LZ77 decompression in BIOS


Check if both your (compressed) source buffer and the destination are
aligned on a dword. I guess swi 18 worked because it needs the data to be
aligned on words or something.

Ive spent a little time disassembling the flashlinker gamepack menu and managed
to figure out how
it pages different banks of the rom in. I dont know if anyone has posted this
information before but I certainly
havent seen it.

I've written a small piece of example code that pulls off a bank switch and
turns the screen red or green
depending on whether the rom contents changed or not.

This appears to work as it should (green screen on emulator - red screen on
flashlinker).

This information should be enough to help anyone who might want to code a nice
new menu selector
for the flash linker.

Both the source and binary are available here.

http://www.gbadev.freehosting.net/

Are you suggesting that you have done something like this or that you know
of a way to do this, or are you just telling what would need to be done?
Because the way it's worded, it appears that you are answering a FAQ :)

Does anyone know anything about the internals on the game shark?  I wouldn't
mind picking one up for hacking with -- it's not too terribly expensive, and
having a USB interface would be kinda handy.  Also, depending on the size of
the flash, it could possibly be an 'expanded MBV2' cable -- you could upload
to the flash if you wanted to -- for those of us who don't think that 256k
is that small ;)

dennis

-----Original Message-----
From: TJ [mailto:comfortably_numb_@...]
Sent: Sunday, April 28, 2002 2:09 AM
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] USB upload cable


in order to do that you would have to reflash it with the code to receive
the data and load it into ram, so not unless you did that.

tom st denis wrote:
> Don't get me wrong guys, alot of your suggestions will work such as the
> LCG or this LFSR.  So don't think I'm some sort of hard-case.  Its just
> that I come from a crypto background and even for simulations I like to
> have decent PRNGs.

The old cliche "horses for courses" comes to mind. Not to disparage
your crypto background but, realistically, we're talking about a
games console here - will a philosophically correct PRNG make your
game more fun than a less philosophically correct PRNG? Will the
player actually notice any difference whatsoever? If you're making
games then this is pretty much the only question you need to ask.
(if you're not then rock on - do it right - and what are doing on
an AGB that's not a game?)

> Considering this is a 32-bit RISC processor we are working with I think
> we can step out of the age of single-state PRNGs.  I mean is it so
> terrible that a PRNG take 200 bytes of ram?  Sure every little bit
> counts but overall I doubt that will cause any problems.

I dunno if you're doing commercial stuff but, if you are, then
200 bytes of RAM can be quite a price to pay just to get a psuedo
random number here and there. Personally, I can think of better ways
to spend my (very limited) RAM. If you've never run out of RAM then,
by all means, rock on. If, one day, you find that you're out of RAM,
maybe consider using a cheaper PRNG ;)

Cheers,

AJS

Hello tom,

Tuesday, April 30, 2002, 4:43:46 PM, you wrote:

tsd> Don't get me wrong guys, alot of your suggestions will work such as the
tsd> LCG or this LFSR.  So don't think I'm some sort of hard-case.  Its just
tsd> that I come from a crypto background and even for simulations I like to
tsd> have decent PRNGs.

tsd> Considering this is a 32-bit RISC processor we are working with I think
tsd> we can step out of the age of single-state PRNGs.  I mean is it so
tsd> terrible that a PRNG take 200 bytes of ram?  Sure every little bit
tsd> counts but overall I doubt that will cause any problems.

you are right ofcoz, but still - unless you really _need_ a "real"
random-number generator, whythehell would you want to use one? even
for simulations (as in games, not weather forecast ;=P) such a simple
algo in 32bit will work nicely. your crypto background probably isnt
much of a help here, since games have certain different requirements
usually. actually most of the times such "predictable" pseudo-random
sequences work even better than a real prng - let it alone be the
simple thing that a shift/eor thing most likely wont ever spit out a
consecutive sequence of the same value (0,0,0,0,0...), which could
very well happen with a real prng that passes all statistical tests.

and however, if you want more "unpredictable" numbers, just EOR the
outcome of that shifting-crap with some value read from unconnected
i/o space, from timer, dma, or whatever - thats in _no_ way more
"decent" like you probably want, but it works :=P

--
Best regards,
  groepaz                            mailto:groepaz@...

or you can read state of player button in rand function
xoring or something like in your seed value, this work for me.

Keywiz


[cropped by mod]

--- groepaz <groepaz@...> wrote:
> Hello Markus,
>
> Tuesday, April 30, 2002, 12:32:19 PM, you wrote:
>
>
> >> >> gSeed = (16807*gSeed)&0x7fffffff;
> >> >
> >> >Hmm, if you ignore the lsb bits yeah,
> >>
> >> Why would you ignore the lsb bits?  The msb bits overflow into the
> lsb
> >> bits each iteration.  There's nothing "less random" about the
> >> msb bits.
> >>
> >> As for the output stream not being "random looking" or "useful,"
> I'm
> >> curious why you make that claim.  It has nice statistical
> properties,
> >> is efficient in speed and size, and moreover, most stdlib
> >> implementations of "rand()" use a variant of this.
>
> MG> well, i just tried it out and without >>16 the results aren't
> random
> MG> whatsoever :)
> MG> and to increase randomness you can call it once every time the
> player
> MG> hits a button or so :)
>
> static int _rndseed = 1;
>
> int rand(void) {
>
>     if(_rndseed&1) {
>         _rndseed>>=1;
>         _rndseed^=0xb400;
>     }else{
>         _rndseed>>=1;
>     }
>
>     return(_rndseed);
>
> }

Umm?  No?  This is known as a Linear Feedback Shift Register or LFSR
and the normal course of operation is to take the LSB [or MSB depending
on how you implement it] bit only.  For example in this case in 16
consecutive outputs of your PRNG several of the bits are correlated
with a probability of 1.

If all you want todo is step through 0..65535 in a somewhat random
looking pattern than this will do.  But if your game logic really needs
something pseudo-random then this will fail miserably.

Don't get me wrong guys, alot of your suggestions will work such as the
LCG or this LFSR.  So don't think I'm some sort of hard-case.  Its just
that I come from a crypto background and even for simulations I like to
have decent PRNGs.

Considering this is a 32-bit RISC processor we are working with I think
we can step out of the age of single-state PRNGs.  I mean is it so
terrible that a PRNG take 200 bytes of ram?  Sure every little bit
counts but overall I doubt that will cause any problems.

Tom

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

I seem to remember having several problems with the BIOS LZ77 decompression. 
Can't remember if I had it crash, but I do remember needing to allocate more
space to decompress to than the length of the data being decompressed, by about
16 bytes or possibly more.

The solution for me was....use a different LZ77 compression/decompression
system.

   ----- Original Message -----
   From: Dennis Munsie
   To: gbadev@yahoogroups.com
   Sent: Monday, April 29, 2002 8:29 PM
   Subject: [gbadev] LZ77 decompression in BIOS


   Hello --

   I'm having a problem with decompressing data using the built in BIOS
   routines, specifically, SWI 17.  On emulators, both with and without a real
   BIOS file, it works perfectly.  On real hardware, though, it the SWI doesn't
   seem to return.  Are there any possible problems I should be looking out
   for?

   For the record, I have used the SWI 18 (decompress to VRAM) just fine
   before.  My source data is in EWRAM (because of the MBV2 cable) and I'm
   trying to decompress to either EWRAM or IWRAM -- both don't work on
   hardware.

   I can provide code if needed -- but, it's pretty simple ARM asm code --
   nothing too out of the ordinary.

   thanks!
   dennis

dx = pEnemy->>x - pPlayer->x;
dy = pEnemy->>y - pPlayer->y;
PS> dx = dx*dx;
PS> dy = dy*dy;
PS> distance = dx+dy; /* make sure to account for distance==0 */
PS> dx = (dx<<8)/distance; /* #.8 fixed point */
PS> dy = (dy<<8)/distance;

this doesnt give you unit vector - your distance is actually
distance*distance - you'd need:

dx = (dx<<8)/sqrt(distance);
dy = (dy<<8)/sqrt(distance);

and yes - this is slooow.
personally I prefer finding angle between objects:
(atan is ofcourse precalculated)

angle = atan2(enemy->x - player->x, enemy->y - player->y);
dx = COS[angle];
dy = SIN[angle];


another idea to get normalized vector
  while(dx>256 || dy>256) {dx >= 1; dy >= 1;}
  // I assume 8.8 fixed point

  its very inaccurate, but often enough for hooming missiles.



  bye, porneL


--
Nothing is faster than the speed of light. To prove this to yourself,
try opening the refrigerator door before the light comes on. [
http://pornel.plj.pl ]

1200 603/200 040/25 16M 8.6G 4X 3.1 AGA, GG 989217

--- Markus Glanzer <markus.glanzer@...> wrote:
>
> > >> gSeed = (16807*gSeed)&0x7fffffff;
> > >
> > >Hmm, if you ignore the lsb bits yeah,
> >
> > Why would you ignore the lsb bits?  The msb bits overflow into the
> lsb
> > bits each iteration.  There's nothing "less random" about the
> > msb bits.
> >
> > As for the output stream not being "random looking" or "useful,"
> I'm
> > curious why you make that claim.  It has nice statistical
> properties,
> > is efficient in speed and size, and moreover, most stdlib
> > implementations of "rand()" use a variant of this.
>
> well, i just tried it out and without >>16 the results aren't random
> whatsoever :)
> and to increase randomness you can call it once every time the player
> hits a button or so :)

Or just use a decent PRNG.  I mean if you are going to use a LCG then
at least use one with a C constant... e.g. of the form

rnd = rnd * B + C

Personally I'd rather use the lagged fibonacii generator because its
statistically more random and doesn't even require multiplication :-)

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

Hello Markus,

Tuesday, April 30, 2002, 12:32:19 PM, you wrote:


>> >> gSeed = (16807*gSeed)&0x7fffffff;
>> >
>> >Hmm, if you ignore the lsb bits yeah,
>>
>> Why would you ignore the lsb bits?  The msb bits overflow into the lsb
>> bits each iteration.  There's nothing "less random" about the
>> msb bits.
>>
>> As for the output stream not being "random looking" or "useful," I'm
>> curious why you make that claim.  It has nice statistical properties,
>> is efficient in speed and size, and moreover, most stdlib
>> implementations of "rand()" use a variant of this.

MG> well, i just tried it out and without >>16 the results aren't random
MG> whatsoever :)
MG> and to increase randomness you can call it once every time the player
MG> hits a button or so :)

static int _rndseed = 1;

int rand(void) {

     if(_rndseed&1) {
         _rndseed>>=1;
         _rndseed^=0xb400;
     }else{
         _rndseed>>=1;
     }

     return(_rndseed);

}

void srand(int r) {
     _rndseed=r;
}

what about this? works fine for me :o) (thats for 16bit numbers
obviously) ... actually, this one has been taken from a discussion
that came up HERE loooooooooooooong ago :o) search the archives, there
are the other eor-constants for various bitlenghts aswell :=) (this
algo btw is especially great for gfx-algorithms, like fading out a
bitmap or sth, since its certain that every possible 16bit (or
whatever) number appears once in the random sequence..... you dont get
the "it takes forever to fade out the last 3 pixels" problem ;O))

this one also should be even faster than the above mentioned method (3
vs 2 arm-instructions, but no MUL)

--
Best regards,
  groepaz                            mailto:groepaz@...

> >> gSeed = (16807*gSeed)&0x7fffffff;
> >
> >Hmm, if you ignore the lsb bits yeah,
>
> Why would you ignore the lsb bits?  The msb bits overflow into the lsb
> bits each iteration.  There's nothing "less random" about the
> msb bits.
>
> As for the output stream not being "random looking" or "useful," I'm
> curious why you make that claim.  It has nice statistical properties,
> is efficient in speed and size, and moreover, most stdlib
> implementations of "rand()" use a variant of this.

well, i just tried it out and without >>16 the results aren't random
whatsoever :)
and to increase randomness you can call it once every time the player
hits a button or so :)

cheers,
Markus

     Giuseppe Crugliano
   Game Designer/Programmer
  g.crugliano@...
    Mobile +39 329 5457012
________________________________
    A R T E M A T I C A
 hi technology digital arts
________________________________
 Phone : +39 (0) 185 324660
  Fax : +39 (0) 185 368490
Mail artematica@...
Web http://www.artematica.com
______________________________

--- Phil Stroffolino <pstroffo@...> wrote:
> >> gSeed = (16807*gSeed)&0x7fffffff;
> >
> >Hmm, if you ignore the lsb bits yeah,
>
> Why would you ignore the lsb bits?  The msb bits overflow into the
> lsb
> bits each iteration.  There's nothing "less random" about the msb
> bits.

First off no, the msb bits do not flow into the lsb bits.  In fact a
bit at position I will not affect a bit at position I-1.
Multiplications modulo 2^k propagate upwards.

> As for the output stream not being "random looking" or "useful," I'm
> curious why you make that claim.  It has nice statistical properties,
> is efficient in speed and size, and moreover, most stdlib
> implementations of "rand()" use a variant of this.

True and most of them suck too.  If you are gonna make use of random
number generators you have to make sure the generator is at least
statistically well.

LCG's routine fail many tests and as your reply indicates many people
don't know that.

Say you had todo a 1/0 switch and you had used the above PRNG [or one
with a non-zero C constant] you'd find the program not behaving too
well.

Tom

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

Yes, I changed to epp mode and added 25 wait states and it works fine now.

Thank you all for your help!!!!!!!!!



> Hi
>
> Did that with me too
>
> Did you try adding some wait (using param -w nnn)
> with EPP, -w 10 works fine for me
>
> Anyways, just keep boosting the value until it works
>
> Vince

Check if both your (compressed) source buffer and the destination are aligned on
a dword. I guess swi 18 worked because it needs the data to be aligned on words
or something.

Later,
Alex.
   ----- Original Message -----
   From: Dennis Munsie
   To: gbadev@yahoogroups.com
   Sent: Monday, April 29, 2002 3:29 PM
   Subject: [gbadev] LZ77 decompression in BIOS


   Hello --

   I'm having a problem with decompressing data using the built in BIOS
   routines, specifically, SWI 17.  On emulators, both with and without a real
   BIOS file, it works perfectly.  On real hardware, though, it the SWI doesn't
   seem to return.  Are there any possible problems I should be looking out
   for?

   For the record, I have used the SWI 18 (decompress to VRAM) just fine
   before.  My source data is in EWRAM (because of the MBV2 cable) and I'm
   trying to decompress to either EWRAM or IWRAM -- both don't work on
   hardware.

   I can provide code if needed -- but, it's pretty simple ARM asm code --
   nothing too out of the ordinary.

   thanks!
   dennis

From: "Phil Stroffolino" <pstroffo@...>
> The following is from a college textbook.  It's always worked nicely
> for me:
>
> gSeed = (16807*gSeed)&0x7fffffff;

I did a quick search about this...  All the LCG's I found using a multiplier
of 16807 used a modulo of 2^31-1, not 2^31.  The latter is what the code
above performs.  Furthermore, the correct implementation of this:

gSeed = (16807*gSeed) % 0x7fffffff; requires that the intermediate
result have at least 47 bits of accuracy.  Otherwise it is the equivalent
(assuming
32 bit ints) of ((16807*gSeed) & 0xffffffff) % 0x7fffffff.

For an extensive discussion and analysis of various RNGs, take a look at
http://random.mat.sbg.ac.at/results/karl/server/server.html

The version I posted earlier seems to have quite reasonable spectral
characteristics
and uses a modulo of 2^32 which can therefore be performed with a simple
32-bit multiply yeilding a 32-bit result with the modulo implied by the
precision
of the result.

- John

> First off, does anyone have a free fast arctan algorithm, I've been
> looking around the web, and the best I can come up with is
variations
> on the 'CORDIC' approach wich is still a little slow for my tastes.


I have replaced atan with an approximation for my homebrew projects.
Mainly I did it as gcc's atan mysteriously stopped working for me the
other day. (after succesfully moving over to "proper" makefiles,
rather than a big gcc command line, ld complained that "s_atan.o does
not support interworking, but test.elf does" and that coincided with
atan ceasing to work)

Anyway, these are the approximations:

arctan(x) = x/(1+0.28*x^2) for |x|<=1
arctan(x) = (pi/2 - x/(x^2+0.28)) for |x|>1

accuracy is <0.006 radians(!). The GBA would baulk at that amount of
divides and float-ing values though, so it probably isn't the fastest
method in the world - I haven't timed it but it works for me - you
could always take those as a start and "approximate more" :)

From: "tom st denis" <tomstdenis@...>
> Hmm, if you ignore the lsb bits yeah, but this method is really not
> that "random looking".  LCGs are just too regular to be that usefull.

The output of an LCG needs to be taken as a whole, not as individual
bits.  Using the value obtained as a fraction in the form of x = n/m where
n is the value obtained and m is the modulo yields an x where  0 <= x < 1.
using x = (n * r)/m yields an x where 0 <= x < r.

Choosing a modulo of the word length of your native multiplier makes all
this very easy.  If you are looking for a binary choice, you can just use the
most significant bit of the generated seed since it will be the most random
bit and is the equivalent of peforming the above multiplication using an r of 2.

Indeed if you are using an r of 2^y, you can simply use the upper y bits of the
seed.

If you're doing serious monte carlo simulations where the statistics of the
outcome
are critical, you probably want to use some other method--perhaps even recording
cosmic background noise such as the NSA does for their one-time-pads used in
some of the most secure encryption techniques.  In most cases for games,
however, LCGs are pretty good.

- John

>> gSeed = (16807*gSeed)&0x7fffffff;
>
>Hmm, if you ignore the lsb bits yeah,

Why would you ignore the lsb bits?  The msb bits overflow into the lsb
bits each iteration.  There's nothing "less random" about the msb bits.

As for the output stream not being "random looking" or "useful," I'm
curious why you make that claim.  It has nice statistical properties,
is efficient in speed and size, and moreover, most stdlib
implementations of "rand()" use a variant of this.


__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

--- In gbadev@y..., tom st denis <tomstdenis@y...> wrote:
>
> First naturally make sure your interrupt/main entry are compiled in
ARM
> mode.

Actually now that I've got the command line switches sorted out, I
can just compile the whole damn thing with -mthumb and it works fine!
main, interrupts, uncle Tom Cobley and all - I'm guessing this is
because Jeffs crt0 which does the real initialization and handles the
low level interrupt processing is in ARM.

I still get some bugs in the thumb that arn't in the arm, but i think
these have other causes - dodgy alignment etc.

cheers,

col

Hello --

I'm having a problem with decompressing data using the built in BIOS
routines, specifically, SWI 17.  On emulators, both with and without a real
BIOS file, it works perfectly.  On real hardware, though, it the SWI doesn't
seem to return.  Are there any possible problems I should be looking out
for?

For the record, I have used the SWI 18 (decompress to VRAM) just fine
before.  My source data is in EWRAM (because of the MBV2 cable) and I'm
trying to decompress to either EWRAM or IWRAM -- both don't work on
hardware.

I can provide code if needed -- but, it's pretty simple ARM asm code --
nothing too out of the ordinary.

thanks!
dennis

--- In gbadev@y..., Phil Stroffolino <pstroffo@y...> wrote:
> >First off, does anyone have a free fast arctan algorithm, I've
been
>
> No, but if you are simply looking to steer bullets, you can just
> normalize the deltas.
>
> dx = pEnemy->x - pPlayer->x;
> dy = pEnemy->y - pPlayer->y;
> dx = dx*dx;
> dy = dy*dy;
> distance = dx+dy; /* make sure to account for distance==0 */
> dx = (dx<<8)/distance; /* #.8 fixed point */
> dy = (dy<<8)/distance;
>

yeah, this would work ok and was my first thought as well, but there
are 2 divides which aint so cool for gba :(
At a guess I could probably get a fairly accurate vector angle and
magnitude from a cordic algorithm for cheaper than those two divides
(the cordic arctan gives me the hypotenuse length as a side
effect :), then use a sin/cos lookup for moving the missile - this
would give easy steering control for homing-in, avoiding etc.
When I've tested it out I'll post my results.

thanks,

col.

Hi Col,

> First off, does anyone have a free fast arctan algorithm,

LUTs are your friend:


int _atan_low[1000];
int _atan_high[1000];

void InitArctan()
{
    int loop;

    for( loop = 0; loop < 1000; ++loop )
    {
      _atan_low[loop] = (int)((2880 * atan( ((double) loop) / ((double)
100) )) / PI );
      _atan_high[loop] = (int)((2880 * atan( (double) loop + 10 )) / PI );
    }
}

int arctan( double input )
{
    if ( input >= 0 )
    {
      if ( input < 10 )
        return _atan_low[(int)(input * 100)];
      else if ( input <= 1000 )
        return _atan_high[(int)(input - 10)];
      else
        return 1440;
    }
    else
    {
      if ( input > -10 )
        return -_atan_low[(int)(input * -100)];
      else if ( input >= -1000 )
        return -_atan_high[(int)(-input - 10)];
      else
        return -1440;
    }
}


This code isn't designed for the GBA so you should really precalculate
the LUTs and put them in ROM. Also note that this returns the result in
degrees<<4 (e.g. 1440 = 90 degrees, this is the unit I'm using for my
game, converting to your own unit shouldn't be too hard). I just noticed
that this algo could be made more efficient by multiplying atan_low by a
power of 2 rather than by 100.

> Last, random number generators.

Another LUT:


signed short numbers[65536];
unsigned short current;

void InitRandom()
{
    int i;

    for( i = 0; i < 65536; ++i )
      numbers[i] = rand(); // returns numbers in range 0-32767

    current = 0;
}

int random()
{
    return (int)numbers[++current];
}

This will use 128K of RAM (again, this code isn't designed for the GBA
so you should change it so that the LUT is precalculated and put in
ROM). You can easily reduce the size of the lookup table if you like
although you won't get the advantage of 'current' automatically wrapping
around at >65535 - although whether relying on this behaviour is the
fastest approach depends on the processor and I can't speak with any
authority about ARM. (I've got no experience programming the GBA yet.)

By the way, I know that both these routines are approximations, but
they're plenty good enough for a game - I'm using them in mine and you
certainly can't tell.
--
Cheers,
James.

     /\  apex                                 James Daniels
    //\\  designs            james.daniels@...
   //__\\                       http://www.apex-designs.net