> [removed by mod: Dont think it is suitable to write
> how you came to that conclusion on a gba dev list with many licenced gba
> developers, therefor I chose to remove it]

Eep.  Good call.

Heh.  That's what I get for thinking this is an all-amateur list.

FWIW, it's probably not what anybody's gonna guess.  I just said something I
shouldn't have.  Bad fatty.

- Fatty


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

Ahh, it was that one divide by the current scanline that I didn't
think to try...
Thank you very much for your help, practically my entire
understandnig of the GBA has come from your tutorials^^

--- In gbadev@y..., "jason rogers" <dovoto@t...> wrote:
> I posted a fairly well comented mode 7 demo on
www.thepernproject.com .  I
> will be adding a short tutor on the matter in the next few days but
that
> should at least get you started.
> -dovoto

> isnt tony hawk's a 12 meg game tho? (I could be wrong!) - I really don't
> think its so much that there is a limit (first ive heard of it) as it is a
> cost issue - nobody but Nintendo can afford to do a bigger cart purely
> because of the how much they would cost at retail!

Nope.  It's 8. [removed by mod: Dont think it is suitable to write
how you came to that conclusion on a gba dev list with many licenced gba
developers, therefor I chose to remove it]

I do like the game on the PS2.  But I don't dig it on the AGB.  Way, way too
easy.

That said, no, it's not an issue of cost: The big N is not allowing anyone
to produce games larger than 8m, and won't even let themselves release and
>16m games.  Those limits are due to shift in a few months, I'm told, to N
w/ 32m and outside developers getting 16m carts.

> kind of unfair I guess - but hey, how else are Nintendo supposed to keep
> their games one step ahead of everyone else's? :0)

By hiring better programmers and game designers.  When Microsoft did this by
obscuring certain useful parts of the Windows 98 API, people were up in
arms.  They have enough clout to spank us through fair play.  I think they
ought to.

But, then again, I probably would have a different tune if I were N...

- John

(People need to learn to trim the footers out of replies.)


[this msg was edited by a mod, please check above for details]

> I read:
> > You're not throwing resolution away.
>
> if I understand it right of courswe you are

You're exchanging sample depth for sample rate.  Whenever your samples are
half the resolution, their timing is twice the resolution.

You are *not* throwing resolution away.  You've always got a 32khz sample at
64khz, and three multipliers (always *2) to spread around as you see fit.

> > You're just applying the time differently.  I think it's rather elegant,
> > but unfortunately, I don't know enough about sound to know why you'd
> > want one over the other
>
> bitdepth = resolution = headroom (kind of)

Uh, no.  Sample depth is the accuracy to which a tone is recorded.  This is
the step distance between tones.

> the idea is that the more bits you use to store a single sample
> (which is basically just the volume or the voltage on the wire)
> the finer grained your resolution in the digital representaion
> will be.
> the so called time domain representation holds no frequency information
> about a sound, just levels(=amplitudes)
> sample rate OTOH defines the speed at which the conversion of said samples
> D->A or vice versa takes place.

At the most technical level, this is correct, but it belies a fundamental
misunderstanding of the characteristics of FM sound.

Rate most certainly *is* a factor in audio sample resolution.  It's one of
four, of which the gameboy supports three: sample depth, sample rate,
channel count, and channel placement (the AGB supports the first three).

People argue which of sample depth or sample rate is more significant.  In
my opinion, they're roughly equivalent - if *either* goes too low, things
begin to suck.

The practical effects of sample depth are the accuracy in tonality that we
percieve as "off-key" when it gets bad.  In order to get a handle on this,
grab your favorite Primus CD (or a female jazz vocalist who moves through a
note slowly somewhere, or a saxophone).  Rip it in MP3 at CD rate - 44.1/16.
Record it again at 44.1/8.  You'll notice that your singer seems to miss her
note every so often.

In order to understand sample rate, consider how "grainy" a song sounds on
old but good condition audio tapes.  Things with extremely fast timing -
especially drum beats in German techno from the 80s - will really show up
low bitrate samples.  You'll get the impression that the tape just couldn't
keep up.

> As you might know the highest possible frequency that can be accurately
> represented in a discrete way is srate/2 (the Nyquist freq.)

It's curious that you know what the nyquist frequency is, that you know that
it involves sample rate, that it limits sample resolution, and that you
still don't think that sample rate is involved in audio resolution.

For those of you who don't know what the Nyquist frequency is, it's the
sample rate cut in half - the rate at which our ears will hear aliasing.
Low-bandwidth pass at the nyquist frequency and your audio will be clean,
clean, clean.

A good explanation of how the Nyquist frequency works is buried in this page
that explains Fast Fourier Transforms:
    http://www.daqarta.com/0t0cfft2.htm

> so if you need high frequencies but don't care about the headroom (the
> number of distict levels) go for higher srates, if you can get by with
> frequencies below you can opt for the higher resolution.

Well, this is the part that I meant when I said I didn't know enough about
sound.  It's not that I don't understand how an FM sample works - that's
pretrty easy.  I just don't know when rate is desirable, and when sample
depth is desirable.  I'm supposing that depth is the default, and that rate
is desirable when depth is a non-issue - say, in sampled speech, where the
tonal range is miniscule, or what have you.

- Fattrini, Alto Tenor Contralto Basso of the 5th nebula of Zorticulon X


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

> i'm hoping the limit will be raised... it's probably caused by production
> costs, so looking forward for chip-price drops ,)  ( or is this monopoly
> arrogance??  ..pssst! keep quiet... ;))

I think it's so that N's games can be stronger in the pimp-force than mere
outsider titles.

Cowards.

But, hey: it's still better than a GameBoy Color.

I think those limits are getting doubled for both parties in the next few
months: N will allow themselves to use full cart size, and the outsiders
will be moved from 8m to 16m.

- Fatzilla of the Second Ark


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

I read:
> You're not throwing resolution away.

if I understand it right of courswe you are

> You're just applying the time differently.  I think it's rather elegant,
> but unfortunately, I don't know enough about sound to know why you'd
> want one over the other

bitdepth = resolution = headroom (kind of)
the idea is that the more bits you use to store a single sample
(which is basically just the volume or the voltage on the wire)
the finer grained your resolution in the digital representaion
will be.
the so called time domain representation holds no frequency information
about a sound, just levels(=amplitudes)

sample rate OTOH defines the speed at which the conversion of said samples
D->A or vice versa takes place.
As you might know the highest possible frequency that can be accurately
represented in a discrete way is srate/2 (the Nyquist freq.)

so if you need high frequencies but don't care about the headroom (the
number of distict levels) go for higher srates, if you can get by with
frequencies below you can opt for the higher resolution.

regards,

x

--
chris@... Postmodernism is german romanticism with better
http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)

ninge wrote:
> isnt tony hawk's a 12 meg game tho? (I could be wrong!) - I really don't
> think its so much that there is a limit (first ive heard of it) as it is a
> cost issue - nobody but Nintendo can afford to do a bigger cart purely
> because of the how much they would cost at retail!
>
> Its just like in the snes days really, Nintendo could afford to release
much
> bigger carts (such as donkey kong country) at the same prices as everyone
> else was releasing the smaller cart sized games simply because they don't
> have to pay their own licensing / manufacturing fees!
>
> kind of unfair I guess - but hey, how else are Nintendo supposed to keep
> their games one step ahead of everyone else's? :0)

tony hawk is 8 MB ( i was already checkin' ;)
i agree with your arguments..

u know any game which's bigger than 8MB? afaik nobody broke this limit yet,
at least none of the released titles..

Dima

> And can someone enlighten me about the linkerscript and crt0 file used in
> devkit advance? Is it Jeff Frohweins nice work?
>
Yup - it is (afaicr) the same as Jeff's ls/crt and is included by default.
If you want an alternative ls/crt0 you can specify those to be used instead
of the default files.

Dave Mariner
================================
http://www.chevrolet-luv.cjb.net
http://exitblaze.com/cgi-bin/newsignups.pl?id=8516&cp=grxdkaQv2lSfc

Hi,
     I put FreeBSD on my lappy the other day - although I haven't got any of
my devtools over yet (first attempt with BSD), so that brings the total up
to 3.....if there's enough interest I'll set up a dedicated FreeBSD/GBADev
website ... what d'ya reckon?

Dave Mariner
================================
http://www.chevrolet-luv.cjb.net
http://exitblaze.com/cgi-bin/newsignups.pl?id=8516&cp=grxdkaQv2lSfc


----- Original Message -----
From: "Toby Hutton" <vjfaq5yxe12s001@...>
To: <gbadev@yahoogroups.com>
Sent: Thursday, November 29, 2001 2:21 AM
Subject: [gbadev] Do you use FreeBSD?


> Hello,
>
> I'm new here, thought I'd delurk.  I'm curious - does anyone use FreeBSD
for GBA dev?  I am just starting out, and the first thing I did was port
('translate' is probably a better word) Jeff F's flash linker client for
Linux to FreeBSD.  I straight port would be a little difficult (due to the
state of the code - sorry Jeff :)) so I've rewritten it to use the ppi(4)
interface, and in C++.  Is anyone interested in it?
>
> vgba has a native FreeBSD version which works great and yesterday I
whipped up a Gimp plugin that would save images in a format suitable for
easy Mode 4 loading... GBA devkit makes building arm-agb GNU tools a
breeze... looks like Linux/*BSD are very viable platforms for GBA
development.
>
> Cool.  I like that.
>
> Anyway, back to fiddling with DMA... and the final boss on Wario Land. :)
>
> Toby.
>
>
>
>
> list rules: http://www.gbadev.org/rules.txt
> unsubscribe: gbadev-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>

oh, that's rather discouraging.. thanks for the info! =) i saw questions
like mine on official newsgroups, but there were no answeres or just crap
replies.. ,)

i'm hoping the limit will be raised... it's probably caused by production
costs, so looking forward for chip-price drops ,)  ( or is this monopoly
arrogance??  ..pssst! keep quiet... ;))

Dima

John Q. Pretentious wrote:

> Um.  So I was going to rant about how it was really just an issue of cost
and such, but at the last minute I decided to ask one of my real developer
friends at Ye Olde Unnamed Major Development House.
>
> It turns out that only the big N is allowed to even make 16m carts right
now; other dev houses are limited to 8.  Man: 1/4th the size.  What crap.
>
> I presume that this limitation is gonna go away over time, but I don't
actually know.

isnt tony hawk's a 12 meg game tho? (I could be wrong!) - I really don't
think its so much that there is a limit (first ive heard of it) as it is a
cost issue - nobody but Nintendo can afford to do a bigger cart purely
because of the how much they would cost at retail!

Its just like in the snes days really, Nintendo could afford to release much
bigger carts (such as donkey kong country) at the same prices as everyone
else was releasing the smaller cart sized games simply because they don't
have to pay their own licensing / manufacturing fees!

kind of unfair I guess - but hey, how else are Nintendo supposed to keep
their games one step ahead of everyone else's? :0)

ninge
   -----Original Message-----
   From: John Q. Pretentious [mailto:johnisaheadcase@...]
   Sent: 29 November 2001 20:34
   To: gbadev@yahoogroups.com
   Subject: Re: [gbadev] card size?


   You have access to WarioWorld?

   Um.  So I was going to rant about how it was really just an issue of cost
and such, but at the last minute I decided to ask one of my real developer
friends at Ye Olde Unnamed Major Development House.

   It turns out that only the big N is allowed to even make 16m carts right
now; other dev houses are limited to 8.  Man: 1/4th the size.  What crap.

   I presume that this limitation is gonna go away over time, but I don't
actually know.

   Huh.
     ----- Original Message -----
     From: Dima
     To: gbadev@yahoogroups.com
     Sent: Thursday, November 29, 2001 5:15 AM
     Subject: Re: [gbadev] card size?


     yes, official documentation says that the maximal possible size is
32Mbyte /
     256Mbit. but the actual question is - which card sizes are in
production?
     i.e. what's the max size available to publishers from nintendo? even on
     warioworld i couldn't find any clear answers..


   [Non-text portions of this message have been removed]



         Yahoo! Groups Sponsor
               ADVERTISEMENT




   list rules: http://www.gbadev.org/rules.txt
   unsubscribe: gbadev-unsubscribe@yahoogroups.com



   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
         intY has automatically scanned this email using Sophos Anti-Virus
(www.inty.net)



[Non-text portions of this message have been removed]

For Boycott Advance Online:
http://baonline.emuunlim.com/


--- In gbadev@y..., "Salevsky, Sascha" <Sascha.Salevsky@i...> wrote:
> Hi fellow coders,
>
> I currently write an "VisualC like" development environment around
the
> DevKitAdvance. Surely at the end of this month I have a first stable
> alpha-version. I've heard, there is a Java-Emulator for the GBA.
Maybe
> someone can point me to the homepage? As I am currently searching
for an
> emulator that I can integrate into the GUI, which is written in
Java (yes,
> Java works damn fine for tools and userinterfaces). So anyone have
the URL?
>
> And btw, my other problem is makedepend.
> Arghl, unix tools are nothing for me :-)
> Thats why I write this IDE :)
>
> And can someone enlighten me about the linkerscript and crt0 file
used in
> devkit advance? Is it Jeff Frohweins nice work?
>
> Thank you very much,
> Sascha.

Hi fellow coders,

I currently write an "VisualC like" development environment around the
DevKitAdvance. Surely at the end of this month I have a first stable
alpha-version. I've heard, there is a Java-Emulator for the GBA. Maybe
someone can point me to the homepage? As I am currently searching for an
emulator that I can integrate into the GUI, which is written in Java (yes,
Java works damn fine for tools and userinterfaces). So anyone have the URL?

And btw, my other problem is makedepend.
Arghl, unix tools are nothing for me :-)
Thats why I write this IDE :)

And can someone enlighten me about the linkerscript and crt0 file used in
devkit advance? Is it Jeff Frohweins nice work?

Thank you very much,
Sascha.

I posted a fairly well comented mode 7 demo on www.thepernproject.com .  I
will be adding a short tutor on the matter in the next few days but that
should at least get you started.
-dovoto
----- Original Message -----
From: <owaincole@...>
To: <gbadev@yahoogroups.com>
Sent: Thursday, November 29, 2001 9:18 AM
Subject: [gbadev] Re: "mode7" effect


> I have tried a variety of formulas for my precalculated table, but I
> just can't get it correct. Could you paste your formula in, or at
> least give us a hint..
>
> Hang on, if you're just altering PA and PC (which are the x scale and
> the x offset per scanline) then does your ground texture stretch
> towards you as you get closer? I would have thought that you would
> want to set your PD the same as your PA so that the pixels
> remain 'square' the closer you get... Or have I missed something. In
> otherwords what you are doing is forming a parrallelagram, where the
> texture is just scaled horisontally... eg (excuse the poor ascii art
> please!)
>
> If ground texture is
>
> AAABBBCCC
> AAABBBCCC
> AAABBBCCC
> DDDEEEFFF
> DDDEEEFFF
> DDDEEEFFF
> GGGHHHIII
> GGGHHHIII
> GGGHHHIII
>
> Then by altering PA per scan line you get this (ignoring sub letter
> scales!!!)(and PC too!)
>
> ABCABCABC
> ABCABCABC
> ABCABCABC
> DDEEFFDDE
> DDEEFFDDE
> DDEEFFDDE
> GGGHHHIII
> GGGHHHIII
> GGGHHHIII
>
> What you actually want is.
>
> ABCABCABC
> DDEEFFDDE
> DDEEFFDDE
> GGGHHHIII
> GGGHHHIII
> GGGHHHIII
>
> Ie scaled in the Y direction too!
> Hope that made sense....
>
> Anyway It'd be great if you could post your code snippet to see what
> it does do!
>
> Owain
>
>
>
>
>
>
> --- In gbadev@y..., "Chris" <csenjaya2001@y...> wrote:
> >     I rewrite the PA, PC, source X and Y registers to do the trick.
> You'll have to precalculate it at the beginning, and store it
> somewhere. So in the H-Blank, you just DMA the corresponding values
> for that scanline.
> >
> >   ----- Original Message -----
> >   From: DekuTree64@h...
> >   To: gbadev@y...
> >   Sent: Thursday, November 29, 2001 3:13 AM
> >   Subject: [gbadev] "mode7" effect
> >
> >
> >   Would anyone happen to know the equations for the pa and pc
> registers
> >   for each line of the screen to make nice smooth ground? I've been
> >
> > ...
> >
> >   Come to think of it, are the pa and pc registers the only ones
> that
> >   have to be changed every line, or do you have to calculate the
> >   pb/pd/x/y regs too? That seems like it'd be awfully slow though
> >
> > [cropped by mod]
>
>
>
>
> list rules: http://www.gbadev.org/rules.txt
> unsubscribe: gbadev-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

hy fellow gba devrs,

and thanks to all that replied on my previous BG Rotation
questions. Now, I managed to rotate the BG, as well as offset
the BG to say, rotate in the center of the screen, however, I
had a really close look at the regs available, and have one question
left. Say I have this Screen Data in mode1 BG2 256*256 Rot map:

  +------------------------------+
  |tst                           |
  |                              |
  |                              |
  |                              |
  |                              |
  |                              |
  |                              |
  +------------------------------+

When I offset the Rotation X and Y Offset to the middle of the
screen, without doing rotation, it (obviously) looks like this:

  +------------------------------+
  |                              |
  |                              |
  |                              |
  |            tst -  -  -  -  - |
  |            .                 |
  |            .                 |
  |            .                 |
  +------------|-----------------+

However, the Rotation center now is at the top left edge of the
first "t" in "tst". Looking at the registers available, it seems
to me like its impossible to actually change the rotation center
"into" the display screen (I would like to rotate the "tst" around
the middle of the "s"). But if theres only one x and y register
for setting the offset, and the rest deals with the actual rot/scaling,
how could I achieve this? I could rearrange the map to at least rotate
around other tiles, but isn't there some way to offset the rotation
center at an arbitrary position, as opposed to setting a scroll offset?

Thanks for any help on this, ist highly appreciated.

Yours
Emanuel
http://www.ngine.de

ps: this is the best/most productive email list ever.

Um.  It's because at 8-bit the sampling frequency is 64khz, but at 9bit it's
32khz; similarly, at 7-bit it's 128khz, and at 6-bit it's 256khz.

Well, it's 262.144, because it's 65.536, not 64, but you get the idea.  You're
not throwing resolution away.  You're just applying the time differently.  I
think it's rather elegant, but unfortunately, I don't know enough about sound to
know why you'd want one over the other (I presume it's gonna be sample depth for
music to get better tonality, but rate for voice to get better specifics, but
I'm really not sure).
   ----- Original Message -----
   From: uze666@...
   To: gbadev@yahoogroups.com
   Sent: Monday, November 19, 2001 11:47 AM
   Subject: [gbadev] Re: Sound Bias Register - 9bit samples????


   > AAxxxxBBBBBBBBBB
   >
   > A=Amplitude resolution in bits, whereas:
   >
   > 00 = 9bit
   > 01 = 8bit
   > 10 = 7bit
   > 11 = 6bit

   How anything else than 8bit is supposed to work anyway??? Considering
   the FIFO has 128bits (16 bytes), 128/9 gives 14.22222 9bit-"bytes"!?!
   Or...is it ignoring some bits in order to "fit" to 8 bits? huh?!?

   > B= Bias level , set by system, do not change this.

   Ok, but do you know what is this BIAS? Voltage bias or perhaps
   frequency BIAS like a treble/bass sort of thing?

   > hope this helps
   Sure, thanks! :-P





   list rules: http://www.gbadev.org/rules.txt
   unsubscribe: gbadev-unsubscribe@yahoogroups.com



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



[Non-text portions of this message have been removed]

You have access to WarioWorld?

Um.  So I was going to rant about how it was really just an issue of cost and
such, but at the last minute I decided to ask one of my real developer friends
at Ye Olde Unnamed Major Development House.

It turns out that only the big N is allowed to even make 16m carts right now;
other dev houses are limited to 8.  Man: 1/4th the size.  What crap.

I presume that this limitation is gonna go away over time, but I don't actually
know.

Huh.
   ----- Original Message -----
   From: Dima
   To: gbadev@yahoogroups.com
   Sent: Thursday, November 29, 2001 5:15 AM
   Subject: Re: [gbadev] card size?


   yes, official documentation says that the maximal possible size is 32Mbyte /
   256Mbit. but the actual question is - which card sizes are in production?
   i.e. what's the max size available to publishers from nintendo? even on
   warioworld i couldn't find any clear answers..


[Non-text portions of this message have been removed]

> Can someone explain windowing: how it works, what the registers do
> and how to set it up?
>
> Much thanks in advance!
>
> (i.e. WIN0_BG0, WIN1_SPRITES, REG_WININ, etc.)

Windows are very different than they were on the GBC, which caused me no small
amount of confusion for the week it took me to find someone able to explain to
me the difference.

On the AGB, Windows are there to define areas.  That's really about it.  That
said, you can do some very cool things with windows.

There are 3 windows: Window 0, window 1, and the Object Window.

Windows 0 and 1 are pretty straightforward: you give them corners, and they
demarcate a rectangle.  Then, you can use that rectangle to change the way the
AGB display works, turning special effects or even display at all on or off for
each window region.

An example: say you want a thin rectangle in the middle of your screen that
reaches almost top to bottom, which shows backgrounds 2 and 3.  Background 0
should show everywhere else.  (Say you're trying to write a castle siege game,
and you're looking out of an arrow slit - the wall is background 0, and the
outside is the other group of backgrounds.)  I'm saving background 1 for my
later example.

Normally, you'd just draw transparent blocks.  Let's say that there's a reason
you can't do it that way.  Instead, set the window to the size of the arrow
slit, and turn background 0 display off for within the bounding rectangle.  I'll
give a better example later.

The object window is similar, except for one thing: rather than to specify
coordinates for the window, you use objects to specify the shape.  This is where
OBJ mode 2 (binary 10) becomes useful.

Say, for instance, that you're writing a first-person shooter.  You want to make
a gun whose scope allows you to see through walls.

First, you set object window on.  Next, you draw a sprite whose shape is
identical to that of your scope (presumably round, unless you know what military
scopes look like).  Set that sprite to OBJ window mode (the same register that
turns blend special effects on).

The OBJ window should behave like the other windows, except that its size is
determined by any sprites who're set to OBJ Window mode.  That way, you can have
non-square windows, or even windows which change shape.  Using color 0
(transparent) is how you mask the shape; any non-zero value will be considered
window content.  Color shoudn't be shown.

So back to our example.  We set the OBJ window to deny drawing of background 0
(castle wall).  We set the *outside* of the window layer not to show sprites, so
that you can only see them through the scope.  This is what WINOUT is for:
controlling the stuff outside of the window.  If you're crafty, you can make
*three* windows from the overlap of window 0 and 1 and using winin and winout
carefully (though it's limited to their intersection).

So, okay.  BG0 is off inside of the scope.  Objects are off outside of the
scope.  Now, let's set BG1,2,3 not to show outside of the scope, either.  Set
the object window to do transparency processing on BG1, and draw your aiming
lines on B1.  Also, fill the area with green, so it looks kinda like a
night-vision scope (if you're in 16x16color mode, you might set the palettes for
BG2 and 3 to greyscale, to make the effect look right).

Draw one more sprite, to make the edge of the scope (they have a metal casing
that you can see when you're looking into them), and bang, you've got a scope
which sees through walls without any funky on-the-fly intersection processing
stuff.

Windows are great for lots of stuff, but they're pretty much cruft-only: you can
only use them in bizarre fashions.

That's why I like them.

- Fattroo of Deneb

(Yahoo! is being funny, taking my mail.  I responded to an audio question last
night, and Yahoo! won't take the mailing.  Has anyone else started having
problems with Yahoo!, Outlook, and getting their responses through, since about
a week and a half ago?  For a bit it was telling me that I had to log in through
POP to get my SMTP out, and that my problem was that the account I was logging
in through wasn't my Yahoo! account, which wasn't true.  Now it just sucks.  Any
ideas?)


[Non-text portions of this message have been removed]

The floor works here... and sprites too.. :)
But do I really need to do inverse transformation with view matrix and
then transform with projection matrix?
Oh well.. Only 128 sprites when I'm not doing sprite-multiplexing..

D.F.


> -----Original Message-----
> From: owaincole@... [mailto:owaincole@...]
> Sent: donderdag 29 november 2001 15:18
> To: gbadev@yahoogroups.com
> Subject: [gbadev] Re: "mode7" effect
>
>
> I have tried a variety of formulas for my precalculated table, but I
> just can't get it correct. Could you paste your formula in, or at
> least give us a hint..
>
> Hang on, if you're just altering PA and PC (which are the x scale and
> the x offset per scanline) then does your ground texture stretch
> towards you as you get closer? I would have thought that you would
> want to set your PD the same as your PA so that the pixels
> remain 'square' the closer you get... Or have I missed something. In
> otherwords what you are doing is forming a parrallelagram, where the
> texture is just scaled horisontally... eg (excuse the poor ascii art
> please!)
>
> If ground texture is
>
> AAABBBCCC
> AAABBBCCC
> AAABBBCCC
> DDDEEEFFF
> DDDEEEFFF
> DDDEEEFFF
> GGGHHHIII
> GGGHHHIII
> GGGHHHIII
>
> Then by altering PA per scan line you get this (ignoring sub letter
> scales!!!)(and PC too!)
>
> ABCABCABC
> ABCABCABC
> ABCABCABC
> DDEEFFDDE
> DDEEFFDDE
> DDEEFFDDE
> GGGHHHIII
> GGGHHHIII
> GGGHHHIII
>
> What you actually want is.
>
> ABCABCABC
> DDEEFFDDE
> DDEEFFDDE
> GGGHHHIII
> GGGHHHIII
> GGGHHHIII
>
> Ie scaled in the Y direction too!
> Hope that made sense....
>
> Anyway It'd be great if you could post your code snippet to see what
> it does do!
>
> Owain
>
>
>
>
>
>
> --- In gbadev@y..., "Chris" <csenjaya2001@y...> wrote:
> >     I rewrite the PA, PC, source X and Y registers to do the trick.
> You'll have to precalculate it at the beginning, and store it
> somewhere. So in the H-Blank, you just DMA the corresponding values
> for that scanline.
> >
> >   ----- Original Message -----
> >   From: DekuTree64@h...
> >   To: gbadev@y...
> >   Sent: Thursday, November 29, 2001 3:13 AM
> >   Subject: [gbadev] "mode7" effect
> >
> >
> >   Would anyone happen to know the equations for the pa and pc
> registers
> >   for each line of the screen to make nice smooth ground? I've been
> >
> > ...
> >
> >   Come to think of it, are the pa and pc registers the only ones
> that
> >   have to be changed every line, or do you have to calculate the
> >   pb/pd/x/y regs too? That seems like it'd be awfully slow though
> >
> > [cropped by mod]
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~--> Break free. Great American Smokeout
> http://us.click.yahoo.com/3vN8tD/.pSDAA/ySSFAA> /cPRolB/TM
>
>
> --------------------------------------------------------------
> -------~->
>
> list rules: http://www.gbadev.org/rules.txt
> unsubscribe: gbadev-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>

i thought the same thing at first, but then i realised what was going on.

The gb bridge looks like a normal GB/GBC cart - inside, it has a custom MBC
that maps flash memory from the GBA cart into the GB memory space.

It doesn't dynamically switch between GBC and GBA mode... that would be
really be something if it did :)

dennis

-----Original Message-----
From: mick.h [mailto:hechen@...]
Sent: Wednesday, November 28, 2001 11:10 PM
To: gbadev@yahoogroups.com
Subject: [gbadev] gba+gbc+gb


hi:
in http://www.taswegian.com/thepernproject/
I saw these lines:
  There is a new 256mb cart and a little adapter called a gb brige...Whats
this mean. Not only can you store more on your linker but you can now store
gb\gbc roms as well. And you can have both at the same time! Pretty tricky.
Anyway check it out. If you dont have a linker yet you may want to get this
cart.

that's really?

is it possible that combine GBA CARTS+GB CARTS+GBC CARTS?
HOW CAN THEY DO THAT?

someone who has a 256M flash cart can tell me it is true or not?

I have tried a variety of formulas for my precalculated table, but I
just can't get it correct. Could you paste your formula in, or at
least give us a hint..

Hang on, if you're just altering PA and PC (which are the x scale and
the x offset per scanline) then does your ground texture stretch
towards you as you get closer? I would have thought that you would
want to set your PD the same as your PA so that the pixels
remain 'square' the closer you get... Or have I missed something. In
otherwords what you are doing is forming a parrallelagram, where the
texture is just scaled horisontally... eg (excuse the poor ascii art
please!)

If ground texture is

AAABBBCCC
AAABBBCCC
AAABBBCCC
DDDEEEFFF
DDDEEEFFF
DDDEEEFFF
GGGHHHIII
GGGHHHIII
GGGHHHIII

Then by altering PA per scan line you get this (ignoring sub letter
scales!!!)(and PC too!)

ABCABCABC
ABCABCABC
ABCABCABC
DDEEFFDDE
DDEEFFDDE
DDEEFFDDE
GGGHHHIII
GGGHHHIII
GGGHHHIII

What you actually want is.

ABCABCABC
DDEEFFDDE
DDEEFFDDE
GGGHHHIII
GGGHHHIII
GGGHHHIII

Ie scaled in the Y direction too!
Hope that made sense....

Anyway It'd be great if you could post your code snippet to see what
it does do!

Owain






--- In gbadev@y..., "Chris" <csenjaya2001@y...> wrote:
>     I rewrite the PA, PC, source X and Y registers to do the trick.
You'll have to precalculate it at the beginning, and store it
somewhere. So in the H-Blank, you just DMA the corresponding values
for that scanline.
>
>   ----- Original Message -----
>   From: DekuTree64@h...
>   To: gbadev@y...
>   Sent: Thursday, November 29, 2001 3:13 AM
>   Subject: [gbadev] "mode7" effect
>
>
>   Would anyone happen to know the equations for the pa and pc
registers
>   for each line of the screen to make nice smooth ground? I've been
>
> ...
>
>   Come to think of it, are the pa and pc registers the only ones
that
>   have to be changed every line, or do you have to calculate the
>   pb/pd/x/y regs too? That seems like it'd be awfully slow though
>
> [cropped by mod]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> vgba has a native FreeBSD version which works great and yesterday I whipped
> up a Gimp plugin that would save images in a format suitable for easy Mode
> 4 loading... GBA devkit makes building arm-agb GNU tools a breeze... looks
> like Linux/*BSD are very viable platforms for GBA development.

Any chance of making the gimp plugin public?

- --
Tom "Tomahawk" Badran
Department of Computing, Imperial College
- -------------------------------------------------
PGP Key available from certserver.pgp.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8BiB5XCpWOla2mCcRAiQFAKCXxoVClWuzv+TaWhMnmlQkeouCagCfcogW
FpJENoIlTwlFWU+anAGkhK4=
=SfW1
-----END PGP SIGNATURE-----

I rewrite the PA, PC, source X and Y registers to do the trick. You'll have
to precalculate it at the beginning, and store it somewhere. So in the H-Blank,
you just DMA the corresponding values for that scanline.

   ----- Original Message -----
   From: DekuTree64@...
   To: gbadev@yahoogroups.com
   Sent: Thursday, November 29, 2001 3:13 AM
   Subject: [gbadev] "mode7" effect


   Would anyone happen to know the equations for the pa and pc registers
   for each line of the screen to make nice smooth ground? I've been

...

   Come to think of it, are the pa and pc registers the only ones that
   have to be changed every line, or do you have to calculate the
   pb/pd/x/y regs too? That seems like it'd be awfully slow though

[cropped by mod]

Im using FreeBSD 4.4 for GBA developing. Just as a hobby dooh.

Im very interessed to get the flash linker port, cause im been tranfering my
app's to a win32 machine before uploading :(

//maq



2001-11-29 02:21:58, "Toby Hutton" <vjfaq5yxe12s001@...> wrote:

>Hello,
>
>I'm new here, thought I'd delurk.  I'm curious - does anyone use FreeBSD for
GBA dev?  I am just starting out, and the first thing I did was port

[cropped by mod]

A window defines a bounding area that can be used to clip background layers
or sprite objects.

At its' simplest, consider the whole of the LCD to be a window.  Any item
that has co-ordinates outside of (0,0)-(239,159) is not visible.  If you
were to define a window of (10,10)-(229,149) and set it so that only BG2
were allowed to be visible inside the window, then you would not see any
part of BG2 that would be displayed outside that area.

The range of possibilities is quite good; you can define two windows, and
you have control over what is displayed both inside and outside the window.

   REG_WIN0H   = 0x0100 | 0x00AE;
   REG_WIN0V   = 0x0100 | 0x009F;
   REG_WININ   = 0x0038;
   REG_WINOUT  = 0x3800 | 0x0037;
   REG_DISPCNT = (MODE2 | OBJ_ENABLE | BG2_ENABLE | BG3_ENABLE | WIN0_ENABLE
| OM1D);

These lines define window 0 to be at (1,1)-(0xAE,0x9F) (REG_WIN0H and
REG_WIN0V), and to display only BG3 and Objects inside the window
(REG_WININ).  REG_WINOUT defines BG2 and Objects to be visible outside the
window co-ordinates.

More information and/or code available if you want it...
NetSlut

-----Original Message-----
From: arciuolo@... [mailto:arciuolo@...]
Sent: 29 November 2001 06:35
To: gbadev@yahoogroups.com
Subject: [gbadev] Windowing


Can someone explain windowing: how it works, what the registers do
and how to set it up?

Much thanks in advance!

(i.e. WIN0_BG0, WIN1_SPRITES, REG_WININ, etc.)

yes, official documentation says that the maximal possible size is 32Mbyte /
256Mbit. but the actual question is - which card sizes are in production?
i.e. what's the max size available to publishers from nintendo? even on
warioworld i couldn't find any clear answers..

John Q. Pretentious wrote:

> I believe that the largest possible AGB cart is 32 megabytes.  Well, 32.5,
if you're a psycho and want to use the SRAM.
>

[cropped by mod]

i'm trying to use virtual methods and i get the following

c:/devkitadv/bin/../lib/gcc-lib/arm-agb-elf/3.0.2/../../../../arm-agb-
elf/lib/in
terwork/libstdc++.a(pure.o): In function `__cxa_pure_virtual':
../../../../../gcc-3.0.2/libstdc++-v3/libsupc++/pure.cc:49: undefined
reference
to `write'
collect2: ld returned 1 exit status
make: *** [ispy.elf] Error 1

i'm including -lstdc++ when i go to link.

does anyone have a clue?

-nik

p.s. i'm using the latest devkit advance on win2K

hi:
in http://www.taswegian.com/thepernproject/
I saw these lines:
  There is a new 256mb cart and a little adapter called a gb brige...Whats this
mean. Not only can you store more on your linker but you can now store gb\gbc
roms as well. And you can have both at the same time! Pretty tricky. Anyway
check it out. If you dont have a linker yet you may want to get this cart.

that's really?

is it possible that combine GBA CARTS+GB CARTS+GBC CARTS?
HOW CAN THEY DO THAT?

someone who has a 256M flash cart can tell me it is true or not?

/mick.h

Can someone explain windowing: how it works, what the registers do
and how to set it up?

Much thanks in advance!

(i.e. WIN0_BG0, WIN1_SPRITES, REG_WININ, etc.)

Hello,

I'm new here, thought I'd delurk.  I'm curious - does anyone use FreeBSD for GBA
dev?  I am just starting out, and the first thing I did was port ('translate' is
probably a better word) Jeff F's flash linker client for Linux to FreeBSD.  I
straight port would be a little difficult (due to the state of the code - sorry
Jeff :)) so I've rewritten it to use the ppi(4) interface, and in C++.  Is
anyone interested in it?

vgba has a native FreeBSD version which works great and yesterday I whipped up a
Gimp plugin that would save images in a format suitable for easy Mode 4
loading... GBA devkit makes building arm-agb GNU tools a breeze... looks like
Linux/*BSD are very viable platforms for GBA development.

Cool.  I like that.

Anyway, back to fiddling with DMA... and the final boss on Wario Land. :)

Toby.