> We suspect it could have something to do with interrupts or the way
> comm interrupts work.

If you search the list archives, you'll find out that only the comm master
can send data to any slaves, IIRC.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

> C typedefs aren't true macros,

Is there a significant difference between them, or are they only not true
macros because they're not handled at the same step by the preprocessor?


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Hi

We have been working on multiplayer communication for a while and
we've been able to get 2 GBAs talking to each other without problems.
However, our code doesn't seem to work with 3 or 4 GBAs connected.

We suspect it could have something to do with interrupts or the way
comm interrupts work. We are enabling bit 0x80 on SIO_CNT on slave0
(or master) and it generates comm interrupts and those are handled by
the other slaves. Slave1 and slave2 seem to receive data from slave0,
but slave2 is not receiving data from slave1 nor slave2 is receiving
data from slave1. We have tried setting bit 0x80 on the slaves but
that did not work either.

Any help on this will be very welcome.

Thanks in advance,
Rafael Matsunaga


[mod note: you can find a lot of information on this topic by searching the list
archives.]

> Is there any tool around that is similar to the
> MapAnalyzer for the GBC?

Google turned up fourteen Japanese pages on this name, and nothing in
English.

Perhaps, could you tell us what this tool does?  That way, we might be able
to find something.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

> As I have understood, the RAM of the GBA is divided
> into external and internal RAM, 256kb vs 32kb in size.
> (external placed on cart?).

No, both the 32k and the 256k are AGB hardware.  The difference is akin to
level 1 and level 2 cache - the 32k is far faster, but more expensive and
thusly more limited.

> How do I control where my
> memory is allocated using malloc() ?

There's been a lot of discussion of this on the list.  On the web page for
the group, you can search for keywords.  I would suggest digging for the old
dialogue.  (I should note that Yahoo's database search is rather
problematic - if you search for something, go get a drink, go to the
bathroom, come back, and hit search again, you're going to get quite a few
more results.)

===

Seperate issue: though most of you probably already know about this, Yahoo!
changed *all* of our marketing settings to opt-in without our consultation.
I would recommend that each of you go to your account info page, to
"marketing preferences", and set all of those to "no".  Then, complain.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

> > > ScanlineCounter = (volatile u16*)0x4000006; //this is the
> > > scan line counter
> >
> > you should declare ScanlineCounter a vu16* (volatile).
>
> Er.  Maybe I'm misunderstanding.  Can't you get away with it during
> declaration like he did there?  Like, I thought a typedef was really a
> special form of a macro?

That wasn't declaration, it was assignment. He cast 0x40000006 as a volatile
u16* value, then assigned it to a non-volatile u16* variable. Since
ScanlineCounter wasn't declared volatile u16* (or the equivalent vu16*), the
compiler was free to cache *ScanlineCounter in a register for the duration
of the while loop.

(Of course, that doesn't explain his observations. If the compiler had
optimized away the memory access, then you'd expect an infinite loop when
the V counter was less than 160, rather than no delay at all.)

- Mike

Very nice, John. One terminology mistake though. Z-buffering and double
buffering are two different things. Z-buffering is a technique used for 3D
rendering, while double buffering is what the GBA uses. You simply switch which
buffer is the front buffer (the one that gets drawn on the screen) and which is
the back buffer (the one you want to draw to), just like you say.

As for your question, yes, it is possible to scale/rotate the background in
bitmap modes. Which makes for a nice method of rendering in mode 5 (courtesy of
Jonas Lund AFAIK). If you rotate the screen 90 degrees and scale it up, the
results won't look bad at all. Remember that the mode 5 resolution is 160x128,
while the screen is 240x160. So your graphics will be stretched to twice the
size on one axis, while staying the same on the other. Take this into account
(as well as the flipped x and y axis) and you're all set for full-screen, double
buffered 15 bpp rendering :)

   ----- Original Message -----
   From: John Q. Pretentious
   To: gbadev@yahoogroups.com
   Sent: Sunday, March 31, 2002 2:54 AM
   Subject: [gbadev] Long discussion of screen basics (was re: Sprite in mode 4)

"John Q. Pretentious" <johnisaheadcase@y...> wrote:
> > > ScanlineCounter = (volatile u16*)0x4000006; //this is the
> > > scan line counter
> >
> > you should declare ScanlineCounter a vu16* (volatile).
>
> Er.  Maybe I'm misunderstanding.  Can't you get away with it during
> declaration like he did there?  Like, I thought a typedef was
> really a special form of a macro?

C typedefs aren't true macros, but they act the same way.
(volatile u16 *) does work on hardware, even at GCC optimization
level 3.  Here's an excerpt from the pin8gba.h that my demos use:

typedef unsigned char  u8;
typedef unsigned short u16;
typedef unsigned int   u32;
/* ... */
#define LCD_Y (*(volatile u16 *)0x04000006)
/* ... */
/* an array of four 16-bit registers */
#define BGCTRL ((volatile u16 *)0x04000008)

It goes on to set up other cute tricks such as defining the
background scroll registers and DMA registers as arrays of
structs, letting me write code that looks like this:

   BGSCROLL[0].x = x;
   BGSCROLL[0].y = y;

--
Damian Yerrick

> > ScanlineCounter = (volatile u16*)0x4000006; //this is the
> > scan line counter
>
> you should declare ScanlineCounter a vu16* (volatile).

Er.  Maybe I'm misunderstanding.  Can't you get away with it during
declaration like he did there?  Like, I thought a typedef was really a
special form of a macro?


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

For those of you who know how the screen works, this isn't gonna tell you
anything new.  However, I'm prone to idiot errors; could someone check this,
and make sure it's correct?  Also, could someone answer my question about
S/R Bitmaps, and make sure I'm not forgetting something in the
what's-needed-to-display-a-sprite list?

>    What are the relations between modes and sprites? I
> was also playing with the "sprite" demo, and once I
> changed modes, it stopped working. What are the basics
> to show a sprite? What is the best tutorial around?

     First, the basics: there is 96k of RAM for video (hereafter VRAM).  It's
chopped up differently for the sprite-and-background modes (hereafter Sprite
modes) than it is for the direct pixel access modes (hereafter Bitmap
modes).  Of the six modes, the first three (0, 1, 2) are sprite modes, and
the last three (3, 4, 5) are bitmap modes.  Switching sprite modes changes
what kind of backgrounds you get; switching bitmap modes changes how the
bitmap RAM is interpreted (8 or 15 bit, with or without z-buffer, fullscreen
or partial screen).

     All modes have sprites, but the amount of VRAM given to sprites changes.
In the sprite modes, 32k of VRAM is given to the sprites (this 32k starts at
VRAM + 0x10000h, or 0x6010000h.)  The OAM breaks this space up into 2^10
chunks (numbered 0 to 1023), giving you that 10-bit index for which tile in
Obj Attr 2.

     The remaining space is given to the "maps" - the arrays of which tile is
being given to which square on a given background - and the tiles for the
backgrounds.  Because background sizes shift, you can demarcate where each
background begins and ends.  Also, you can demarcate where the tiles for the
backgrounds begin.  Of that 64k, at most 32k can be taken by the map data
(the tile layout), meaning that at least 32k is guaranteed to be space for
background tiles.

     In the sprite modes, shifting modes changes which backgrounds behave in
what way.  Mode 0 is the easiest: it's four normal backgrounds.  Nice and
simple.  Normal backgrounds can do the typical stuff: flip tiles in their
map, use 4- or 8-bit tiles, etc.  All four backgrounds may be turned on
(0,1,2,3).  However, in any of these modes, you may turn any BG off at any
time.  (In modes 1-5, certain BGs *must* be turned off, but you are never
forced to have any of them on.)

     Mode 1 is a little more complex.  You have two normal backgrounds (bg 0
and 1), and one background which does Scaling and Rotation (bg 2).  Scaling
and rotation backgrounds don't H/V flip tiles, and they can only use 8-bit
tile faces, but in exchange for that loss of control, you get to spin them
and zoom them to your heart's content.  In mode 1, BG3 must be turned off.

     Mode 2 is a pair of scaling and rotation backgrounds, and no normal
backgrounds.  Mode 2 has BG2 and 3 on, and 0 and 1 off.

     Now, in the bitmap modes, only 16k is given to tile faces.  The OAM
doesn't change how it orders tiles; rather, you just start putting tiles in
at the halfway point (which is VRAM + 0x14000h, or 0x6014000h).  In the OAM,
just point to sprite number 512 and up when setting TileID (which is
equivalent to pretending to having 512 entries and just leaving bit 9 on, or
pretending to have 512 entries and ORing by something #defined to 512.)

     That leaves 80k of space in the bitmap modes, which is allotted to the
bitmap buffer.  The hardware considers BG2 to be the bitmap (don't ask me
why); in all bitmap modes, BG2 is the only BG which may be on.  I believe
turning BG2 off in a bitmap mode turns the actual bitmap off, but I've never
tried it, so I'm not certain.  Someone on IRC told me that the bitmaps took
scaling and rotation parameters correctly, but I've never tried it, so I
don't know if that's true (could someone give a definitive answer on this,
please?)

     In mode 3, the bitmap buffer is read as a single array of (240*160)
halfwords (16 bits).  Each of those entries is interpreted as a pixel in BGR
order, giving the bottom 5 bits to the Red value, the next 5 to Green, the
next 5 to Blue, and discarding the top bit.  This means that, in mode 3, you
can get away with just writing an RGB value to the correct location in an
array (shown below) and it will just set a pixel.  Mode 3 is the mode
obvious mode to computer programmers, IMHO.  Remember that you do still get
sprites, but that the amount of VRAM allotted to keeping faces is halved
(enough for 512 4-bit or 256 8-bit tiles, IIRC).

     In mode 4, the buffer is instead interpreted as an array of 8-bit
entries.  Since each entry (that is, each pixel) takes half as much space in
VRAM, you have enough memory for two screens; in fact, that's exactly how it
works.  The 80k is broken up into two full screens' worth of data, called
Z-Buffer 0 and Z-Buffer 1 (many people omit the Z.)  If you're familiar with
Z-Buffers or Double Buffering, you should be nodding your head about now.
If not, read on.

     There's a bit in DISPCNT (I think it's bit 4, but I'm too lazy to check)
that sets which of those two chunks is being used to paint the screen.  The
reason one wants this is because it's helpful for drawing smoothly, if your
draw routines won't finish in the space of a single screen draw cycle.  If
you've ever seen the screen draws that get diagonal lines chopping across
the middle, that's the effect we're trying to avoid: that comes from being
halfway done drawing when the screen gets updated.  What you do instead is
to draw to the buffer which isn't being used, and then flip the screen to
use that buffer (one bit set doesn't take long at all) when you know the
screen isn't in the middle of drawing.  That's what double buffering is:
drawing offscreen and instantly popping your changes into place.

     That's so useful, in fact, that mode 5 does it, too.  Mode 5 is an odd
mode that you don't see used terribly often.  It's a 15-bit color mode with
Z-Buffers.  "But ... there isn't that much VRAM", you say?  Right: Mode 5
only uses part of the screen.  Specifically, it's 160x128, in the middle of
the screen.  I don't know if there's a way to stretch it to fit the screen -
I don't use mode 5 at all.  I believe that it's intended for full-color fast
paint to screen, suggesting things like movie playback, etc.  However, as
every good programmer knows, it's really for whatever interesting crap you
can make it do.  <grins>

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

     Regarding sprites and what you need to do to turn them on:

         1) The sprite layer must be enabled (DISPCNT bit 12=on)

         2) You need to have an onscreen sprite which is not set to DblSize,
S/R on (setting both effectively hides the sprite)

         3) The sprite needs to be pointing at a valid tile, and the tile
needs to have tile data (they start transparent)

         4) Screen display must be enabled (AKA Forced Blank, or LCDC; this
is DISPCNT bit 7, and it must be set to *off* - setting the bit forces the
screen to all-white)

         5) Set the palettes, so that your sprites aren't solid black

         6) If you're in a bitmap mode (mode 3,4,5), you must remember that
sprites start at 512, not 0

         7) You must not use my graphics (so ugly they'll break your screen,
natch)

         8) Your gameboy must be on, and it must have a program loaded (a
cart, or multiboot)

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

Anyhoo, I think that that about covers the basics of screen usage.  I didn't
really cover much about map usage ('cause I don't want to type anymore), and
I didn't explain anything about 1D/2D sprite tile layout (someone else can
do that, I'm not in the mood).  But it should work.  Also, I promised to
show an example of drawing to a mode 3 screen, so here goes:

(This uses macros.  Macros are bad for reasons whose explanations are
outside of the scope of this posting.  Macros are also very fast, but then
again, so are inline functions, which aren't bad at all.)

I did not test this code.  But I think it ought to work, unless I did
something stupid.

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

typedef volatile unsigned char vu8;
typedef volatile unsigned short int vu16;

#define DispStat 0x4000004
#define DispCnt 0x4000000
#define Mode3 3
#define BG2_On 0x0400
#define tPutPixel(usex, usey, usecolor) *(vu16 *)(VRAM
+((((vu8)(usey)*240)+(vu8)(usex))*2))=(vu16)(usecolor)

void setmode3() {  // Bad: function does more than it should, but is good
enough for an example
   *(vu16 *)DispCnt = Mode3 | BG2_On;  // Turn on BG2 and set to screen mode
3
   *(vu16 *)DispStat = 0;  // Turn off LCDC with a shotgun
}

int main() {  // main *must* return an int - void is against standard!
vu8 i, j, hang;
vu16 zcolor;

   setmode3();  // Prepare the screen and turn it on

   for (color=0; zcolor<32768; zcolor++) {  // For each possible 15-bit color
do
     for (j=0; j<160; j++) {  // for each screen row do
       for (i=0; i<240; i++) {  // for each scren column do
         tPutPixel(i,j,zcolor);  // draw the pixel at (i,j) in color zcolor
       }
     }
   }

   while (1) {
     ++hang; hang=0;  // Gee, I wonder.  Maybe this hangs the app?
   }

   return 0;  // proper form!
}


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

GBFS is an alternative to the hassle of the various "incbin" hacks
(such as bin2h, b2x, objcopyroda/interflip, etc.) used to put binary
data (such as graphics, text, maps, and sounds) into a Game Boy
Advance program.  It also has the advantage that artists and music
people will be able to try their media immediately on the emulator
without having to recompile the program.  It's analogous to the
"appended datafile" method used in some PC games, especially those
that use the Allegro library (http://alleg.sourceforge.net).

Use the included tools to put all your media into a GBFS file (an
archive similar to a zip file but not compressed) and then simply
concatenate the program binary to the GBFS file containing the
data.  Then use the library to find binary objects by name.

A demonstration program is included that rolls credits
based on a font and text file both stored in a GBFS file.
Feel free to borrow this code for your game's end credits.

Find it at http://pineight.com/gba/

--
Damian Yerrick

I'm sorry but I can't find the trailer you're talking about on their website,
where did you get it from?
Do you know what are the typical bitrates for the low and high quality movie?

Alex.
   ----- Original Message -----
   From: Droid
   To: gbadev@yahoogroups.com
   Sent: Friday, March 29, 2002 5:20 PM
   Subject: R: [gbadev] AVI movies


   It's a VERY good player, and the quality can be changed according to the
   rom space you would give to your movie. There's a couple of movies of a
   BMW trailer that show you the difference between a high quality movie
   and a low quality one; you should look at them.

   Droid

-----Original Message-----
From: John Bäckstrand [mailto:sandos@...]
Sent: 02 April 2002 15:42
To: gbadev@yahoogroups.com
Subject: [gbadev] external vs internal RAM

As I have understood, the RAM of the GBA is divided
into external and internal RAM, 256kb vs 32kb in size.
(external placed on cart?). How do I control where my
memory is allocated using malloc() ?

---
John Bäckstrand





Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

As I have understood, the RAM of the GBA is divided
into external and internal RAM, 256kb vs 32kb in size.
(external placed on cart?). How do I control where my
memory is allocated using malloc() ?

---
John Bäckstrand

In the way of using dynamic palettes,
You can implement a control system in the level compilation.
While compiling, the program detect if more than 16 palettes are used by
animations in 1 GBA screen.
It is true that when you have a dynamic management for animations, it take
more ressources, but the processor is fast.
In my engine, I have full dynamic allocations for animations (characters and
palettes) and the same for background. At the same time, we uncrunch all
data in real time for animations and background (2 levels of compression : 1
is a kind of RLE compression) for levels & animations.
And we haven't any problems of time.

So in my opinion, Dynamic alloactions are the best way to make a good game,
because graphists don't take care of anything. There are less problems.

Christian.




-----Message d'origine-----
De : Otaku [mailto:otaku@...]
Envoyé : mardi 2 avril 2002 04:01
À : GBADEV Mailing List
Objet : Re: [gbadev] Various sprites and one palette

A rather belated reply to the thread as I'm busy finishing up my current
project.

Muddying the waters even further here's my 2 penn'orth worth. I actually use
a couple of different methods depending on the view. I have one placed in
the game where I have a large 256 colour sprite on-screen, which obviously
uses fixed colours so I use a "fixed" palette, the sprite uses the first 64
entries in the palette, I then over-write certain other portions of the
palette for a number of 16-colour sprites that share the same screen. For
another view I use a fixed palette but switch out the first four banks of 16
colours for various team colours, each team has two sets of colours, some of
the colours are the same (the sleeves on their shirts change colour, their
caps change colour), but skin colour and hair colour changes depending on
racial origin. So I can mix and match the players. All of these slots are
"fixed" in the sense that the sprites "know" which palette to use but the
colours there may change. For the menu systems all of the sprites are 16
colours and the palettes are dynamically assigned. One footnote, when you
mix 256 colour sprites and 16 colour sprites, if you are "clever" with your
colour allocations you can have a 256 colour sprite and a 16 colour sprite
sharing the same region of the palette, also for the 256 colour sprite,
those "transparent" colours that are modulo 16 (0, 16, 32, 48, 64, etc) are
usable as normal.

Fixed palette
Info: The entire palette is determined at pre-compile time by the artist or
programmer, or determined at compile time by the compiler.
Pros: a) Allows the use of 256 & 16 colour sprites on the same screen
Cons: a) Inflexible approach. b) Can quickly run out of colours c) Artists
hate it.

Static palette
Info: Portions of the palette are loaded under programmer control as and
when needed, the colours are dynamic but the entries they are loaded to are
static, i.e. load the palette for the player at slot #5.
Pros: a) Flexible approach. Useful for both 256 colour & 16 colour sprites,
especially when mixing on the same screen.
Cons: b) Difficult to explain to the artist. b) Programmer has to worry
about which slots are open. c) Can make re-arranging palettes difficult.

Static palette & Dynamic palette
Pros: a) Flexible approach. b) Allows automatic changing of palettes on the
fly.
Cons: a) Bloody difficult to explain to the artist. b) Tedious to implement.
c) Can be slow to execute if your in-game resource management system is not
implemented properly.

Fully Dynamic palette
Pros: a) Totally flexible b) You don't worry about where the palettes are
allocated.
Cons: a) Not suitable for 256 colour sprites. b) Can be difficult to debug.
c) Same as point c) above. d) Extra lookups during run-time to see which
palette to use for a particular sprite/animation frame. d) Artists love it.
e) Extra overhead when de-allocating palettes no longer in use. f) You can
run out of palettes if you have an over-zealous level designer or artist who
will usually say something along the lines of "just make it work", "don't
bother me with details", and "is there any way we can get another 128
hardware palettes?".


----- Original Message -----
   From: Andrew Crowe
   To: gbadev@yahoogroups.com
   Sent: Tuesday, March 26, 2002 3:42 AM
   Subject: Re: [gbadev] Various sprites and one palette


   >    I have many sprites to show simultaneously in the game I`m working
on,
   and I`d like to know from you guys the best way to work with the palette.
Do
   all sprites have to share the same palette, as in the GBC? Which would be
   the best way to set up a complete palette of all my sprites? I was
thinking
   about making a big PCX with all of them and then saving the palette, and
   then applying it back to each sprite separately, but I don't know if this
   works, and it feels like brute force. Is there any other way?

   Sprites use one 256 colour palette, either all 256 colours at once (all
   sprites have the same palette) or each sprite can use 16 colours from the
   palette, taken in groups of 16.

   The way that I'm planning to do is give each sprite it's own 16 colour
   palette, then build the main palette dynamically

   eg.

   say you have 2 copies of sprite 1 which has palette A, and another sprite
   with palette B:

   Sprite 1: colours 0-15
   Sprite 2: colours 0-15
   Sprite 3: colours 16-31

   Palette:

   colours 0-15 : A
   colours 16-31 : B


   If I moved sprite 3 off screen, and broght on a different sprite, I'd
   replace colours 16-31 with the new palette

   That way you could have any number of colours for sprites, tho you'd have
to
   write palette management routines, and of course you could only have 16
   different "types" of sprite onscreen at once



   Andrew

Hi,

> Sorry for the basic question folks...
>
> What's the usual way of controlling what data is code (like AGBMain for
> example), and should be loaded into memory, and what data is things like
> music and graphics for other levels, and should be kept in ROM until
> needed?  Our software project has just gotten big enough that the
> difference matters.  I'm using gcc and HAMlib, in case that's relevant.

Putting "const" at the start of the array decleration forces the data into
ROM (eg .const unsigned short int)

to swap data between ram and rom (eg. reading a map or gfx data into ram to
make vram copying faster) you'll need to handle that manually.

what you need to do is allocate the RAM that the data will take up (by using
malloc or making an array) then reading the contents of the ROM array into
it

eg

// x = array length

while(x--){
     workram_map[x] = rom_map[x]
}



Andrew

Is there any tool around that is similar to the
MapAnalyzer for the GBC?

Thanks for the help,

Cesar.

________________________________________________________________________________\
_______________
Yahoo! Empregos
O trabalho dos seus sonhos pode estar aqui. Cadastre-se hoje mesmo no Yahoo!
Empregos e tenha acesso a milhares de vagas abertas!
http://br.empregos.yahoo.com/

Sorry for the basic question folks...

What's the usual way of controlling what data is code (like AGBMain for
example), and should be loaded into memory, and what data is things like
music and graphics for other levels, and should be kept in ROM until
needed?  Our software project has just gotten big enough that the
difference matters.  I'm using gcc and HAMlib, in case that's relevant.

In unrelated news, I've found a small bug in crt0.s that causes it to fail
when there are no global variables - who owns this code?

Thanks in advance,

- Jeremy

On the PC, use floating point (it's often as fast or faster than fixed
point, of course depending on what you're doing). On the GBA, use fixed
point.
that's all there is to it :)

-henrik

-----Ursprungligt meddelande-----
Fran: Mat [mailto:matth@...]
Skickat: den 1 april 2002 15:05
Till: gbadev@yahoogroups.com
Amne: Re: [gbadev] Floating point speed?


If I wanted a non real-time renderer on PC, I wouldn't be implementing it on
the GBA would I?

I want this to render static screens on the GBA for game story purposes. If
I can render scenes from within the mesh then I won't have to store
thousands of frames of pre-rendered graphics.

Mat



----- Original Message -----
From: Aaron St.John <aaronstj@...>
To: <gbadev@yahoogroups.com>
Sent: Monday, April 01, 2002 5:11 AM
Subject: Re: [gbadev] Floating point speed?


> >I'm using it for an high precision non real-time 3d renderer.
>
> And this is better done on the GBA than the PC because...?
>
>
>
>
> Stupid like a fox!
> Look ma, I'm an artist: http://aaronstj.deviantart.com





Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

A rather belated reply to the thread as I'm busy finishing up my current
project.

Muddying the waters even further here's my 2 penn'orth worth. I actually use a
couple of different methods depending on the view. I have one placed in the game
where I have a large 256 colour sprite on-screen, which obviously uses fixed
colours so I use a "fixed" palette, the sprite uses the first 64 entries in the
palette, I then over-write certain other portions of the palette for a number of
16-colour sprites that share the same screen. For another view I use a fixed
palette but switch out the first four banks of 16 colours for various team
colours, each team has two sets of colours, some of the colours are the same
(the sleeves on their shirts change colour, their caps change colour), but skin
colour and hair colour changes depending on racial origin. So I can mix and
match the players. All of these slots are "fixed" in the sense that the sprites
"know" which palette to use but the colours there may change. For the menu
systems all of the sprites are 16 colours and the palettes are dynamically
assigned. One footnote, when you mix 256 colour sprites and 16 colour sprites,
if you are "clever" with your colour allocations you can have a 256 colour
sprite and a 16 colour sprite sharing the same region of the palette, also for
the 256 colour sprite, those "transparent" colours that are modulo 16 (0, 16,
32, 48, 64, etc) are usable as normal.

Fixed palette
Info: The entire palette is determined at pre-compile time by the artist or
programmer, or determined at compile time by the compiler.
Pros: a) Allows the use of 256 & 16 colour sprites on the same screen
Cons: a) Inflexible approach. b) Can quickly run out of colours c) Artists hate
it.

Static palette
Info: Portions of the palette are loaded under programmer control as and when
needed, the colours are dynamic but the entries they are loaded to are static,
i.e. load the palette for the player at slot #5.
Pros: a) Flexible approach. Useful for both 256 colour & 16 colour sprites,
especially when mixing on the same screen.
Cons: b) Difficult to explain to the artist. b) Programmer has to worry about
which slots are open. c) Can make re-arranging palettes difficult.

Static palette & Dynamic palette
Pros: a) Flexible approach. b) Allows automatic changing of palettes on the fly.
Cons: a) Bloody difficult to explain to the artist. b) Tedious to implement. c)
Can be slow to execute if your in-game resource management system is not
implemented properly.

Fully Dynamic palette
Pros: a) Totally flexible b) You don't worry about where the palettes are
allocated.
Cons: a) Not suitable for 256 colour sprites. b) Can be difficult to debug. c)
Same as point c) above. d) Extra lookups during run-time to see which palette to
use for a particular sprite/animation frame. d) Artists love it. e) Extra
overhead when de-allocating palettes no longer in use. f) You can run out of
palettes if you have an over-zealous level designer or artist who will usually
say something along the lines of "just make it work", "don't bother me with
details", and "is there any way we can get another 128 hardware palettes?".


----- Original Message -----
   From: Andrew Crowe
   To: gbadev@yahoogroups.com
   Sent: Tuesday, March 26, 2002 3:42 AM
   Subject: Re: [gbadev] Various sprites and one palette


   >    I have many sprites to show simultaneously in the game I`m working on,
   and I`d like to know from you guys the best way to work with the palette. Do
   all sprites have to share the same palette, as in the GBC? Which would be
   the best way to set up a complete palette of all my sprites? I was thinking
   about making a big PCX with all of them and then saving the palette, and
   then applying it back to each sprite separately, but I don't know if this
   works, and it feels like brute force. Is there any other way?

   Sprites use one 256 colour palette, either all 256 colours at once (all
   sprites have the same palette) or each sprite can use 16 colours from the
   palette, taken in groups of 16.

   The way that I'm planning to do is give each sprite it's own 16 colour
   palette, then build the main palette dynamically

   eg.

   say you have 2 copies of sprite 1 which has palette A, and another sprite
   with palette B:

   Sprite 1: colours 0-15
   Sprite 2: colours 0-15
   Sprite 3: colours 16-31

   Palette:

   colours 0-15 : A
   colours 16-31 : B


   If I moved sprite 3 off screen, and broght on a different sprite, I'd
   replace colours 16-31 with the new palette

   That way you could have any number of colours for sprites, tho you'd have to
   write palette management routines, and of course you could only have 16
   different "types" of sprite onscreen at once



   Andrew



         Yahoo! Groups Sponsor
               ADVERTISEMENT




   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

It is pretty expensive, but it gets a lot more manageable when you turn down
the playback frequency and keep the number of simultaneous sounds to a
minimum. Still, I guess the CGB synth would be better performance-wise, but
in that case I think you'd want to have the composers work with a fixed set
of sounds rather than try to reproduce whatever general MIDI instruments
they feel like using. It would still be cool if you could pull it off
though. Sorry I couldn't be of more help.

- Mike

----- Original Message -----
From: "Lovelace, Rebecca" <rebecca.lovelace@...>
To: <gbadev@yahoogroups.com>
Sent: Monday, April 01, 2002 2:43 PM
Subject: RE: [gbadev] Question on getting MIDI music from sound dept. to GBA


> I was under the impression that direct sound was too expensive to use all
> the time (CPU-wise), and that you wanted to use the synth when you could
get
> away with it.
>
> Am I mistaken?
>
> Rebecca
>
> -----Original Message-----
> From: Mike Danylchuk [mailto:miked@...]
> Sent: Monday, April 01, 2002 2:38 PM
> To: gbadev@yahoogroups.com
> Subject: Re: [gbadev] Question on getting MIDI music from sound dept. to
> GBA
>
>
> I've never used the CGB-compatible waveforms, so I'm not sure how people
> come up with those, but I'd guess that the majority of GBA games are using
> direct sound.
>
> - Mike
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

I was under the impression that direct sound was too expensive to use all
the time (CPU-wise), and that you wanted to use the synth when you could get
away with it.

Am I mistaken?

Rebecca

-----Original Message-----
From: Mike Danylchuk [mailto:miked@...]
Sent: Monday, April 01, 2002 2:38 PM
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] Question on getting MIDI music from sound dept. to
GBA


I've never used the CGB-compatible waveforms, so I'm not sure how people
come up with those, but I'd guess that the majority of GBA games are using
direct sound.

- Mike

I had the same problem. My first attempt was to export the waveforms from a
free SBLive soundfont, but those are intended to be looped, and the GBA
won't loop them, at least not with the Nintendo music library.

I ended up creating a MIDI file that played C5 over and over again with
patch changes in between, then played it back and sampled it on a
full-duplex sound card. Once the individual samples were isolated, filtered,
and downsampled, the results sounded pretty good.

The only problem is that with one-shot samples, the sample needs to be at
least as long as the note to be played, and the effective length of the
sample gets cut in half with each higher octave, so if you have a lot of
sustained high notes, you'll need very long samples.

I've never used the CGB-compatible waveforms, so I'm not sure how people
come up with those, but I'd guess that the majority of GBA games are using
direct sound.

- Mike

> Since the GBA doesn't have built-in patches for General MIDI etc, how do
> people go about getting MIDI files to sound good on the GBA?  If your
sound
> department generates a MIDI file, how do you generate the corresponding
> patch bank to use the CGB-compatible synth?
>
> Thanks!
> Rebecca
>

>I had this same problem i dont know what it is ether!! is it Bimbo?

As you may or may not have seen, we resolved this problem.  The compiler
(correctly) assumes that the array or 'unsigned short int's that Bimbo
produces is destined for RAM.  So when the ROM starts up, it take the image
in ROM and copies it to RAM, which isn't large enough to store the image
(which takes up 240*160*2 bytes, or 76,800).  The way to work around this is
open up the .C file that Bimbo produces and change 'unsigned short int' to
'const unsigned short int'.  Since you specify 'const', the compiler knows
that you don't intend on changing array in code, so it knows to keep it in
ROM instead of copying it to RAM.  Problem solved.




Stupid like a fox!
Look ma, I'm an artist: http://aaronstj.deviantart.com


_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

Since the GBA doesn't have built-in patches for General MIDI etc, how do
people go about getting MIDI files to sound good on the GBA?  If your sound
department generates a MIDI file, how do you generate the corresponding
patch bank to use the CGB-compatible synth?

Thanks!
Rebecca

If I wanted a non real-time renderer on PC, I wouldn't be implementing it on
the GBA would I?

I want this to render static screens on the GBA for game story purposes. If
I can render scenes from within the mesh then I won't have to store
thousands of frames of pre-rendered graphics.

Mat



----- Original Message -----
From: Aaron St.John <aaronstj@...>
To: <gbadev@yahoogroups.com>
Sent: Monday, April 01, 2002 5:11 AM
Subject: Re: [gbadev] Floating point speed?


> >I'm using it for an high precision non real-time 3d renderer.
>
> And this is better done on the GBA than the PC because...?
>
>
>
>
> Stupid like a fox!
> Look ma, I'm an artist: http://aaronstj.deviantart.com

Heja,

I wondered about this too, cause I noticed the empty characters in Mappy
once. However, I think the GameBoy Advance hardware explicitly excludes the
sprites from 0x14000 downwards. After all, specifying a sprite index of 0,
doesn't allow the sprite to use the contents of the frame-buffer there. The
sprite just doesn't show. I think this is done trough some clever
bitmasking, which would explain using 0x14000 instead of 0x12c00.

Not sure though, so forgive me if I'm giving disinformation here,
mwhauhauahaah..a.a..a ..

Cheers,

Jape

This is a reply to:

Slightly OT this question, but I'm gonna ask anyway :)  Has anyone
actually taken advantage of the extra 160 16 colour characters available
and butted their sprite data slap bang at the end of the screen?

Well, from my calculations it's something like 160 characters anyway.
Screens end at 0x12c00 and sprites are SUPPOSED to start at 0x14000 in
mode 3 or 4.



_________________________________________________________________
Download MSN Explorer gratis van http://explorer.msn.nl/intl.asp.

>I'm using it for an high precision non real-time 3d renderer.

And this is better done on the GBA than the PC because...?




Stupid like a fox!
Look ma, I'm an artist: http://aaronstj.deviantart.com


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

I had this same problem i dont know what it is ether!! is it Bimbo?