Mat:

How many people would have an AGB codebase already finished before being
hired to develop on AGB?

Doesn't seem to make much sense...

-----Original Message-----
From: Mat [mailto:matth@...]
Sent: Tuesday, January 09, 2001 8:51 AM
To: gbadev@egroups.com
Subject: Re: [gbadev] Size (and structure) of GBA teams


Hi

Once core code is established which most experienced programmers carry with
them from project to project, only 1-2 game programmers should be required.
I
seriously suggest that anyone that has not established a core code base
should
do so before anything else, and if a programmer does not already have a code
base then he probably isn't worth hiring.

I guess that the theory that Shawn presents may hold true for projects that
are
completely written from scratch, with no code base available.

One more thing, the number of artists on a project should definitely
outweigh
the number of programmers (Around 2 to 5 dependant upon graphical
intensity and complexity of course) since the major part of a game is
graphical
nowadays :)

Mat


----- Original Message -----
From: Shawn Freeman <sfreeman@...>
To: <gbadev@egroups.com>
Sent: Tuesday, January 09, 2001 4:06 PM
Subject: Re: [gbadev] Size (and structure) of GBA teams


> Hi Eric,
>
> > Additionally, I was hoping that you all would give me your insights
> > as to the average size and makeup of a GBA development team.  I
> > imagine this will change from title to title, so if I could get
> > several opinions, that would be a HUGE help.
>
> I'm currently lead on a couple of projects, and in my opinion you need at
> least two core programmers and a third game programmer, and preferably two
> artist who are familiar with the CGB/SNES type game art.
>
>         Just Me,
>             *SF
>
> >
> > Thanks in advance (no pun intended).
>
>
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>


unsubscribe: gbadev-unsubscribe@egroups.com

$400K is a tiny budget for a team. It's when you start getting towards
millions of dollars then you have to worry.

Martin.

-----Original Message-----
From: Eric Marcoullier [mailto:eric@...]
Sent: 09 January 2001 21:30
To: gbadev@egroups.com
Subject: Re: [gbadev] Size (and structure) of GBA teams


[..]

All totalled, that sounds like $400K -- have you heard of any company
receiving that much development money from publishers?

[..]

There is still room, especially on consoles, for one/two man operations.

This list is turning into a load of 'c' programmers trying to boast how good
their existing c libraries are!  Utter crap!

I personally can't wait for the machine to arrive then we will see what your
all really made of.

-Anthony

>Being a programmer for 20 years I have built a huge code base, which is
>...
>project. I'm all for cutting budgets :)

Thank you, Mat, and everyone else, for all this great info.  I am
currently speaking with a programmer about developing a GBA title (we
already have publisher interest, thankfully) and I think we have
dangerously underestimated how long it would take to produce a launch
platformer/adventure game.

My partner had specced a lead designer/programmer position, a second
programmer and an artist.  While this seems reasonable for GBC, this
sounds like too little for GBA development.  From what you have all
said, it sounds like a lead designer, two programmers and two artists
are the absolute minimum.  Plus, me, the producer.

All totalled, that sounds like $400K -- have you heard of any company
receiving that much development money from publishers?


>Are you really the founder of those sites,  if so thanks they are quite
>good.

Yep -- spent the three best years of my life at Imagine Media, and
the worst year of my life at Snowball :)  I'm glad you like them -- a
lot of people still bust their ass every day working on those sites,
and it's always nice to hear that their work is appreciated.


>Hope you get the producer position you are after. However you must be
>warned that producers are normally well hated by all other staff other than
>the directors of course :)

Goes with the territory, I guess.  But I'm a really lovable guy.  Really!

Thanks again for all the help.
Eric

--
---------------------------------------------------
Eric Marcoullier       --      eric@...
http://www.marcoullier.com      --     781.354.4433

Founder and Product Manager of the Following Sites:
IGN, Next Gen Online, Game Players Online, BuzzSite

Currently trying to secure a Game Producer position
---------------------------------------------------

Hi Eric

Being a programmer for 20 years I have built a huge code base, which is
very re-useable. C is C on any platform. Although some of the code will
need to be hand optimised to suit a particular system it takes a lot less
time
to do this than completely re-invent the wheel. As far as writing code that
is processor specific (ARM32 or ARM16 in the case of the AGB) it
would only be necessary for less than 1% of the total project code to
written in native assembler language to keep the overall game frame rate
nominal

A lot of games rely mainly on their graphical content rather than gameplay.
(Does not apply to all games) This leads to better drawn / rendered
graphics and much more of it. FMV is also very common in games
nowadays which requires a lot of expertise and time. These factors and the
need to design maps / game worlds using custom map / world creation
editors it adds up to a lot of creative talent required. Another factor that
tends
to increase team sizes in larger companies is the fact that trainee's are
added
to the team in order to help train them up.

We have however forgot another important part of game production which
is testing. Lets not forget them poor test guys who get paid to play games
all day and annoy the hell out of programmers with minor inconsistencies :)
Incidentally all team members double up as testers towards the end of a
project. I'm all for cutting budgets :)

Are you really the founder of those sites,  if so thanks they are quite
good.
Hope you get the producer position you are after. However you must be
warned that producers are normally well hated by all other staff other than
the directors of course :)

Regards

Mat


----- Original Message -----
From: Eric Marcoullier <eric@...>
To: <gbadev@egroups.com>
Sent: Tuesday, January 09, 2001 8:09 PM
Subject: Re: [gbadev] Size (and structure) of GBA teams


> >do so before anything else, and if a programmer does not already have a
code
> >base then he probably isn't worth hiring.
>
>
> >One more thing, the number of artists on a project should definitely
> >outweigh the number of programmers (Around 2 to 5 dependant upon
graphical
>
> Do both of these statements apply to GBA?  I don't know how many
> programmers are going to already have a code base for the system.
>
> Additionally, five artists for a handheld game, no matter how pretty,
> sounds like a lot.
>
> Can you clarify?
>
> Thanks!
> Eric
> --
> ---------------------------------------------------
> Eric Marcoullier       --      eric@...
> http://www.marcoullier.com      --     781.354.4433
>
> Founder and Product Manager of the Following Sites:
> IGN, Next Gen Online, Game Players Online, BuzzSite
>
> Currently trying to secure a Game Producer position
> ---------------------------------------------------
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>

Hi,

>No, you can access it via CPU. I wrote a simple asteriods on the real
>hardware without using any DMA.

  Oh, thank you, you calmed me down a bit ; )

  - Nokturn

In message <OE34rn4Zpdp9O3oUO7900008e86@...>
           "Nokturn" <nokturn_@...> wrote:

> Greets,
>
>  as you may know, I have made a game together with Simon and it's been
published on gbadev.org
>
>  I have though heared that it crashes on the real hardware. Now a question to
you official developers:
>
>  What do I have to do to make the game run on real hardware? I don't know the
reason why it crashes, but I suppose it is because the OAM, which I access per
CPU. Is it true that I HAVE to access it er DMA?

No, you can access it via CPU. I wrote a simple asteriods on the real
hardware without using any DMA.

--
exoticorn/icebird

>do so before anything else, and if a programmer does not already have a code
>base then he probably isn't worth hiring.


>One more thing, the number of artists on a project should definitely
>outweigh the number of programmers (Around 2 to 5 dependant upon graphical

Do both of these statements apply to GBA?  I don't know how many
programmers are going to already have a code base for the system.

Additionally, five artists for a handheld game, no matter how pretty,
sounds like a lot.

Can you clarify?

Thanks!
Eric
--
---------------------------------------------------
Eric Marcoullier       --      eric@...
http://www.marcoullier.com      --     781.354.4433

Founder and Product Manager of the Following Sites:
IGN, Next Gen Online, Game Players Online, BuzzSite

Currently trying to secure a Game Producer position
---------------------------------------------------

Yo,

> I guess that the theory that Shawn presents may hold true for projects
that
> are completely written from scratch, with no code base available.

Yup. However, sometimes you need to rewrite a code base for extra speed (i.e
assembler). I don't have any arm code libs lying around here ;).

> One more thing, the number of artists on a project should definitely
> outweigh the number of programmers (Around 2 to 5 dependant upon graphical
> intensity and complexity of course) since the major part of a game is
> graphical
> nowadays :)

Agreed. Absolute minimum is 2, but more is definately better! :)

                 Just Me,
                     *SF

Hi

Once core code is established which most experienced programmers carry with
them from project to project, only 1-2 game programmers should be required.
I
seriously suggest that anyone that has not established a core code base
should
do so before anything else, and if a programmer does not already have a code
base then he probably isn't worth hiring.

I guess that the theory that Shawn presents may hold true for projects that
are
completely written from scratch, with no code base available.

One more thing, the number of artists on a project should definitely
outweigh
the number of programmers (Around 2 to 5 dependant upon graphical
intensity and complexity of course) since the major part of a game is
graphical
nowadays :)

Mat


----- Original Message -----
From: Shawn Freeman <sfreeman@...>
To: <gbadev@egroups.com>
Sent: Tuesday, January 09, 2001 4:06 PM
Subject: Re: [gbadev] Size (and structure) of GBA teams


> Hi Eric,
>
> > Additionally, I was hoping that you all would give me your insights
> > as to the average size and makeup of a GBA development team.  I
> > imagine this will change from title to title, so if I could get
> > several opinions, that would be a HUGE help.
>
> I'm currently lead on a couple of projects, and in my opinion you need at
> least two core programmers and a third game programmer, and preferably two
> artist who are familiar with the CGB/SNES type game art.
>
>         Just Me,
>             *SF
>
> >
> > Thanks in advance (no pun intended).
>
>
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>

Hi Eric,

> Additionally, I was hoping that you all would give me your insights
> as to the average size and makeup of a GBA development team.  I
> imagine this will change from title to title, so if I could get
> several opinions, that would be a HUGE help.

I'm currently lead on a couple of projects, and in my opinion you need at
least two core programmers and a third game programmer, and preferably two
artist who are familiar with the CGB/SNES type game art.

         Just Me,
             *SF

>
> Thanks in advance (no pun intended).

> I know a certain tinpot company in the uk who has a one man 'team'. just
> because they are greedy bastards.

Then this certain tinpot company won't have a very successful agb industry.
:)

         Just Me,
             *SF

I know a certain tinpot company in the uk who has a one man 'team'. just
because they are greedy bastards.

----- Original Message -----
From: Eric Marcoullier <eric@...>
To: <gbadev@egroups.com>
Sent: Tuesday, January 09, 2001 12:58 AM
Subject: [gbadev] Size (and structure) of GBA teams


> I'm doing some research regarding GBA development and while I've seen
> a lot of documentation online for programming, I've found precious
> little about the meat and bones of development.
>
> First off, if anyone has any links that I should check out, that
> would be awesome -- I'm a big believer in RTFM, and don't want to
> bother y'all needlessly.
>
> Additionally, I was hoping that you all would give me your insights
> as to the average size and makeup of a GBA development team.  I
> imagine this will change from title to title, so if I could get
> several opinions, that would be a HUGE help.
>
> Thanks in advance (no pun intended).
> Eric
>
> --
> ---------------------------------------------------
> Eric Marcoullier       --      eric@...
> http://www.marcoullier.com      --     781.354.4433
>
> Founder and Product Manager of the Following Sites:
> IGN, Next Gen Online, Game Players Online, BuzzSite
>
> Currently trying to secure a Game Producer position
> ---------------------------------------------------
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>
>

I'm doing some research regarding GBA development and while I've seen
a lot of documentation online for programming, I've found precious
little about the meat and bones of development.

First off, if anyone has any links that I should check out, that
would be awesome -- I'm a big believer in RTFM, and don't want to
bother y'all needlessly.

Additionally, I was hoping that you all would give me your insights
as to the average size and makeup of a GBA development team.  I
imagine this will change from title to title, so if I could get
several opinions, that would be a HUGE help.

Thanks in advance (no pun intended).
Eric

--
---------------------------------------------------
Eric Marcoullier       --      eric@...
http://www.marcoullier.com      --     781.354.4433

Founder and Product Manager of the Following Sites:
IGN, Next Gen Online, Game Players Online, BuzzSite

Currently trying to secure a Game Producer position
---------------------------------------------------

This is a little off topic but not too far. Can anyone tell me if the GBA
will have region locked/ecoded cartridges or is it still "no regions" as per
the current gameboy.

Just want to work out if I should wait for a UK model or get myself and
early import.

Thanks

Keith

> I attempted to get some stuff up and running in C++, but had many problems
> so I abandoned it, however I think I remember someone else on the list
> mentioning that they had a project up and running in C++ successfully. I
> would recommend due to your time constraint to use plain old C.

I have a project running strictly in object oriented C++, and have not had
any problems that are really worth mentioning.  The reason I chose C++ is
that I was porting existing C++ code from a PC prototype.  Aside from
having to shoehorn the game into the much smaller memory space, it has been
an easy port so far.  Your mileage may vary of course.

What problems have people been running into with C++?  Why would time
constraints lead you to use C?  Wouldn't C++ help you work faster?

-Ben

--
Benbuck Nason
  "Showdowns with pronouns, plus I make love to verbs." - Diaz Brothers

Hi

You can get PCMCIA SCSI cards and so far we have successfully run the devkit
on Acer and Dell laptops with no problems.

Good luck :-)

CK


-----Original Message-----
From: Dave Mariner [mailto:elevenstrong@...]
Sent: 04 January 2001 15:25
To: Gameboy Development; gbadev@egroups.com
Subject: [gbadev] devkits + laptops...


Hi guys,
             As my new years resolution would appear to be to see a bit more
of the world, I'm planning on getting a laptop. Has anyone had any
experience with the IS devkits on laptops? If so, can you let me know which
ones do/don't work with 'em? I know I'll obviously have to rule out any
without scsi,  unless you can get a pcmcia scsi i/f?


             TIA,

Dave Mariner
overworked@...
=========================
Windows NT crashed.
I am the Blue Screen of Death.
No one hears your screams.
- Windows Haiku



unsubscribe: gbadev-unsubscribe@egroups.com

Hi guys,
             As my new years resolution would appear to be to see a bit more
of the world, I'm planning on getting a laptop. Has anyone had any
experience with the IS devkits on laptops? If so, can you let me know which
ones do/don't work with 'em? I know I'll obviously have to rule out any
without scsi,  unless you can get a pcmcia scsi i/f?


             TIA,

Dave Mariner
overworked@...
=========================
Windows NT crashed.
I am the Blue Screen of Death.
No one hears your screams.
- Windows Haiku

> That's odd because when I was converting Quake to the ARM I managed to
> change all the floating points maths, with the exception of the QuakeC
> stuff, to use the 64 bit multiply. When it came to dividing the results
> achieved were more accurate in some places than the original floating point.
> I did use a reciprocal table that made use of all 32 bits though and used a
> shift to gain the required accuracy for each stage of the calculation.
> Using the 64 bit mul and accumulate also helped a lot when dealing with 64
> bit numbers.

we also dont had any accuracy problems (why should there be any? :).
Only the shift eats accuracy when the table is not big enough for
the number range..   but i think 16:16 fixed point math should do on AGB
and so the table would be just 128kb.

--

Manfred Linzner
(Project Manager)
Shin'en Multimedia
http://www.shinen.com
Tel.: ++49 (0)89 785 82 565
Fax.: ++49 (0)89 785 82 535

> Im rendering large textures from ROM directly to VRAM, I dont touch EX_WRAM.
> at the moment, but I'm going to need it soon for larger geometry buffers.

> The numbers I am using require too much precision for me to use recipricols
> and its too late in the day for me to move the engine over to 64 bit math , I
tried it
> for geometry and perspective texture mapping but accuracy was terrible.

i understand. one additional problem with texturemapping on agb is the low
display resolution.

> The game I am working on requires a a couple of thousand divs per frame :)
> , but with interpolation I managed to get it down by a factor of 16.
>
> What type of game is it? Im currently getting between 30 and 45 fps, but
> would like a solid 40+

our game can be roughly compared to afterburner or galaxy force.
so no number crunching like in real 3d scenes. only for collsions
and prespective translation some math is needed. all other perspective
stuff like texturing ceiling & floor and doing a perspective sky is
done with the hardware capabilities.

i'm fell more convinced to use the agb as a piece of special hardware
like the amiga then a number crunching device that it obviously is not.


regards

--

Manfred Linzner
(Project Manager)
Shin'en Multimedia
http://www.shinen.com
Tel.: ++49 (0)89 785 82 565
Fax.: ++49 (0)89 785 82 535

That's odd because when I was converting Quake to the ARM I managed to
change all the floating points maths, with the exception of the QuakeC
stuff, to use the 64 bit multiply. When it came to dividing the results
achieved were more accurate in some places than the original floating point.
I did use a reciprocal table that made use of all 32 bits though and used a
shift to gain the required accuracy for each stage of the calculation.
Using the 64 bit mul and accumulate also helped a lot when dealing with 64
bit numbers.


-----Original Message-----
From: Mat [mailto:matth@...]
Sent: 04 January 2001 14:42
To: gbadev@egroups.com
Subject: Re: [gbadev] Multi Player Gamins

The numbers I am using require too much precision for me to use recipricols
and its too
late in the day for me to move the engine over to 64 bit math , I tried it
for geometry
and perspective texture mapping but accuracy was terrible.

Hi Manfred

> the major bottle neck is often the EXRAM & ROM accesses. If your routine
> spends most it's time copying stuff from rom to ram there is often no big
> speed increase, but when you can access your stuff from internal RAM only
> the difference can be quite huge. E.g. the code for our sample mixer in
our GAX soundroutines
> is about 8 times faster in handoptimized ARM32 code then in optimized C
code.
> The code can be make use of the conditional ARM32 commands and so our
mainloop
> gets alot smaller then the C one which is quite bloated.

Im rendering large textures from ROM directly to VRAM, I dont touch EX_WRAM.
at the moment, but I'm going to need it soon for larger geometry buffers.

> The ARM has a sort of hardware divide, dont you know? :)
> You know that muls are fast and  "X=Y/Z" can be translated to
"X=Z*1/Y"....

from which I gather you mean something along these lines:

n = 16384 / Z;    // Tabulate this
X = (Y * n) >> 16;

The numbers I am using require too much precision for me to use recipricols
and its too
late in the day for me to move the engine over to 64 bit math , I tried it
for geometry
and perspective texture mapping but accuracy was terrible.

> As we have in our current game a couple of hundred DIVS each frame it
> was just not possible to use the normal div without going down to 30fps
with.
> With the above method i was able to speed up the divs by about 800%. Only
drawback is the need of a 16kb table.

The game I am working on requires a a couple of thousand divs per frame :)
, but with interpolation I managed to get it down by a factor of 16.

> So finally everything is still 60fps and we have enough time to mix 8
channels for music and fx in 21khz. :)
>

What type of game is it? Im currently getting between 30 and 45 fps, but
would like a solid 40+

Regards

Mat

> What kind of speed increase are you guys getting by using ARM32 asm
> directly? because if its significant I may have another attempt. As an example
I wrote
> a horizontal textured line blitter in C and ARM32 asm and got only a 10% speed
> increase. The only real difference I got was some very odd stack
> manipulation madness. I think it may be because I was writing directly to
VRAM.

hi,

the major bottle neck is often the EXRAM & ROM accesses. If your routine
spends most it's time copying stuff from rom to ram there is often no big
speed increase, but when you can access your stuff from internal RAM only
the difference can be quite huge. E.g. the code for our sample mixer in our GAX
soundroutines
is about 8 times faster in handoptimized ARM32 code then in optimized C code.
The code can be make use of the conditional ARM32 commands and so our mainloop
gets alot smaller then the C one which is quite bloated.

> Yep I agree the integrated shifter and conditional execution are excellent,
> just a pity there is no hardware divide or DMA mod / scale functionality, oh
and
> a double speed mode would have been nice :) Actually I think I would have
> just settled with a complete 32 bit bus so I dont have to cache most of my
code
> in WRAM :(

The ARM has a sort of hardware divide, dont you know? :)
You know that muls are fast and  "X=Y/Z" can be translated to "X=Z*1/Y"....

As we have in our current game a couple of hundred DIVS each frame it
was just not possible to use the normal div without going down to 30fps with.
With the above method i was able to speed up the divs by about 800%. Only
drawback is the need of a 16kb table.

So finally everything is still 60fps and we have enough time to mix 8 channels
for music and fx in 21khz. :)


regards

--

Manfred Linzner
(Project Manager)
Shin'en Multimedia
http://www.shinen.com
Tel.: ++49 (0)89 785 82 565
Fax.: ++49 (0)89 785 82 535

Hi Manfred

Nice one, that never occurred to me :) Problem is I already went and wrote
my
own asm divide, I reckon the gcc stuff would be faster than mine though.

What kind of speed increase are you guys getting by using ARM32 asm
directly?
because if its significant I may have another attempt. As an example I wrote
a
horizontal textured line blitter in C and ARM32 asm and got only a 10% speed
increase. The only real difference I got was some very odd stack
manipulation
madness. I think it may be because I was writing directly to VRAM.

Yep I agree the integrated shifter and conditional execution are excellent,
just
a pity there is no hardware divide or DMA mod / scale functionality, oh and
a double speed mode would have been nice :) Actually I think I would have
just
settled with a complete 32 bit bus so I dont have to cache most of my code
in
WRAM :(

Regards

Mat


----- Original Message -----
From: Manfred Linzner <linzner@...>
To: <gbadev@egroups.com>
Sent: Thursday, January 04, 2001 10:09 AM
Subject: Re: [gbadev] Multi Player Gamins


> > Also, with regards to overlays. You dont have to goto assem to get fast
code
> > up and running. You can implement a code caching system, whereby you
> > reserve a small area of WRAM for functions. You then compile functions
that
> > require the utmost speed to ARM32, copy them to the code cache in WRAM
> > and execute.(TIP: You cannot use normal C divide in ARM32, or maybe its
> > just me linking with the wrong libs).
>
> It's not your fault. The branches in your code are obviously relative and
so you can't call
> any outside functions within your ram-moved code. or you jump to nirvana
then :)
>
> To use outside functions you must pass the needed functions addresses to
some pointers first
> and use the pointers instead of the real functions addresses.
>
> > 1. Turn compiler optimisations upto level 3 -O3 option. I have measured
only
> > a 10% increase (at best) between my hand written ARM32 code and compiler

> > optimised.
>
> Level 3 optimising does really a good job for a c compiler.
> (tho we got for most functions alot more then 10% speed increase when
rewriting
>  it to arm32 code. the optimising function simply does not use the full
potential
>  of the conditional commands of the arm32 mode).
>
>
> regards
>
> --
>
> Manfred Linzner
> (Project Manager)
> Shin'en Multimedia
> http://www.shinen.com
> Tel.: ++49 (0)89 785 82 565
> Fax.: ++49 (0)89 785 82 535
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>

> Also, with regards to overlays. You dont have to goto assem to get fast code
> up and running. You can implement a code caching system, whereby you
> reserve a small area of WRAM for functions. You then compile functions that
> require the utmost speed to ARM32, copy them to the code cache in WRAM
> and execute.(TIP: You cannot use normal C divide in ARM32, or maybe its
> just me linking with the wrong libs).

It's not your fault. The branches in your code are obviously relative and so you
can't call
any outside functions within your ram-moved code. or you jump to nirvana then :)

To use outside functions you must pass the needed functions addresses to some
pointers first
and use the pointers instead of the real functions addresses.

> 1. Turn compiler optimisations upto level 3 -O3 option. I have measured only
> a 10% increase (at best) between my hand written ARM32 code and compiler
> optimised.

Level 3 optimising does really a good job for a c compiler.
(tho we got for most functions alot more then 10% speed increase when rewriting
  it to arm32 code. the optimising function simply does not use the full
potential
  of the conditional commands of the arm32 mode).


regards

--

Manfred Linzner
(Project Manager)
Shin'en Multimedia
http://www.shinen.com
Tel.: ++49 (0)89 785 82 565
Fax.: ++49 (0)89 785 82 535

Hi

I attempted to get some stuff up and running in C++, but had many problems
so I abandoned it, however I think I remember someone else on the list
mentioning that they had a project up and running in C++ successfully. I
would
recommend due to your time constraint to use plain old C.

Also, with regards to overlays. You dont have to goto assem to get fast code
up and running. You can implement a code caching system, whereby you
reserve a small area of WRAM for functions. You then compile functions that
require the utmost speed to ARM32, copy them to the code cache in WRAM
and execute.(TIP: You cannot use normal C divide in ARM32, or maybe its
just me linking with the wrong libs).

A few more speed tips:
1. Turn compiler optimisations upto level 3 -O3 option. I have measured only
a
10% increase (at best) between my hand written ARM32 code and compiler
optimised.
2. Turn on pre-fetch and set correct wait state timings for THUMB code in
rom
using the following:

  u32  ws0 = 5;
  u32  ws1 = 5;
  u32  ws2 = 5;
  u32  prefetch = 1;
  *((u16 *)(REG_BASE + 0x204)) = (prefetch << 14) | (ws2 << 8) | (ws1 << 5) |
(ws0 << 2);

3. Scope variables

and so on..........

Hope some of this helps

Mat






----- Original Message -----
From: <nharding@...>
To: <gbadev@egroups.com>
Cc: <nharding@...>
Sent: Wednesday, January 03, 2001 11:15 PM
Subject: [gbadev] Multi Player Gamins


> Has anyone looked into mutliplayer gaming yet on the AGB? I'm supposed to
> write my game so that up to 4 players can play with just the one
> cartridge, but we only have 1 devkit at the moment! Also if I'm writing
> this as multiplay, I'm going to have to do lots of code overlays to ensure
> that it fits into the available ram, how do I specify this in C/C++?
> Talking of C++ has anyone done any performance tests to see if there is
> any overhead for C++. Sorry for all the questions but I'm the solo coder
> on a project which has to be finished for May!
>
> Neil Harding
>
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>

Hi Neil,

There is a file MultiSample_en.zip available from noa's site that should
help you out.  No sure how you would go with overlays, although at 2.5k
per second to 3 machines - 1.7 minutes just to fill ram I am not sure they
would be of much use anyway.  Hope this helps some.

Dave.



-----Original Message-----
From: nharding@... [mailto:nharding@...]
Sent: Thursday, January 04, 2001 10:15 AM
To: gbadev@egroups.com
Cc: nharding@...
Subject: [gbadev] Multi Player Gamins


Has anyone looked into mutliplayer gaming yet on the AGB? I'm supposed to
write my game so that up to 4 players can play with just the one
cartridge, but we only have 1 devkit at the moment! Also if I'm writing
this as multiplay, I'm going to have to do lots of code overlays to ensure
that it fits into the available ram, how do I specify this in C/C++?
Talking of C++ has anyone done any performance tests to see if there is
any overhead for C++. Sorry for all the questions but I'm the solo coder
on a project which has to be finished for May!

Neil Harding


unsubscribe: gbadev-unsubscribe@egroups.com

Hello,

First off I'd say you would have some issues with C++. However it is your
project so you may do what you like. If you really plan on pulling off code
overlays and need speed I'd get out the old ARM architecture manual and
start coding essential parts of the program which will reside in ram in
assembly.

Secondly, and most unfortunately, the feature you are referring to is called
multi-boot where you can have linked players play without a cartridge. Up to
this point Nintendo has NOT released any documentation on the multi-boot
feature and how it is supposed to work! I'm sure you can do linked gaming
just fine but, because the docs to support it are there, but if you are
looking to boot other AGB's off of a single cartridge your gonna have to
wait for Nintendo to provide us developers with more info.

Ciao...

-----Original Message-----
From: nharding@... [mailto:nharding@...]
Sent: Wednesday, January 03, 2001 3:15 PM
To: gbadev@egroups.com
Cc: nharding@...
Subject: [gbadev] Multi Player Gamins


Has anyone looked into mutliplayer gaming yet on the AGB? I'm supposed to
write my game so that up to 4 players can play with just the one
cartridge, but we only have 1 devkit at the moment! Also if I'm writing
this as multiplay, I'm going to have to do lots of code overlays to ensure
that it fits into the available ram, how do I specify this in C/C++?
Talking of C++ has anyone done any performance tests to see if there is
any overhead for C++. Sorry for all the questions but I'm the solo coder
on a project which has to be finished for May!

Neil Harding


unsubscribe: gbadev-unsubscribe@egroups.com

Has anyone looked into mutliplayer gaming yet on the AGB? I'm supposed to
write my game so that up to 4 players can play with just the one
cartridge, but we only have 1 devkit at the moment! Also if I'm writing
this as multiplay, I'm going to have to do lots of code overlays to ensure
that it fits into the available ram, how do I specify this in C/C++?
Talking of C++ has anyone done any performance tests to see if there is
any overhead for C++. Sorry for all the questions but I'm the solo coder
on a project which has to be finished for May!

Neil Harding