> -----Original Message-----
> From: yerricde [mailto:d_yerrick@...]

> > GCC compiled Thumb code is plenty fast enough for sprite based
> > 2d games
>
> Even when you have over 100 sprites on the screen? That's very
> plausible in a space shooter or a Smash TV style game.
> Is 200,000 cycles enough?

depends on your update code to be honest. Hardware sprites don't use mush in
the way of CPU time :)
the main problem you have is collision since that needs to be done in
software & there are tricks to reduce what actually needs checked.

I was very surprised when I had a basic shell of a game going with around
300 moving objects but that was using tilebased collision. Compiled for
thumb too, thus my comment above.

> The biggest problem with putting code in IWRAM is that the most
> common link scripts and libraries (such as the ones included with
> devkitadv and HAM) do not directly support the IWRAM code overlay
> trick used in most games for the Atari Jaguar console. Such
> overlays let you copy a program segment into IWRAM using DMA,
> which means that you don't waste memory by having the T&L code,
> the rasterizer, and the mixer in IWRAM all at once.

heh, that sort of stuff can be hand coded quite easily. I was involved in a
Jaguar project once - unfortunately Atari went belly up before they paid us
or the game got published. Pity really as it had been classed AAA by Atari
US :/ We went 100% assembly for that - too much hassle coding for
multiprocessor machines in C methinks. That & we were using Falcons to code
on :) Nice machine with some very odd features the Jag.


> > Personally I prefer assembly to high level languages but I
> > haven't yet found a decent macro assember for ARM that doesn't
> > cost big bucks.
>
> What's wrong with GNU Binutils?

um do you mean GAS? Haven't really looked at it much - got put off by the
horrendous syntax when I was coding 68k & Devpac could output GCC object
files anyway :) Is it any better for ARM?

Looks like the ARM tools are desirable given the dhrystone tests, pity about
the price :/

> > Keeping an eye on the assembly output of GCC seems to be the
> > best way of optimising code & learning how to get the compiler
> > to do what you want.
>
> I can attest to that. It's how I (half-)optimized my mixer.

heh, chuck the assembly output into a source file & go from there :) There
are tricks in assembly that you just can't code in C, not enough control
over the code. Not that I want to start a C vs Assembly debate - horses for
courses & all that.

Dave