gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Beginners > trying to teach myself. verbatim demo doesn't work.

#46276 - pr0vidence - Wed Jun 22, 2005 6:26 pm

Greetings all.
Been trying to teach myself via all of the tutorials out there to program for the GBA with some success.

I am currently trying to get a basic picture to display on screen. I have copied the example from the tutorial verbaTim but it does not work.

Code:
#include "gba.h"
#include "background.h"

int main()
{
   u8 x,y;
   u16 loop;
   
   SetMode (MODE_4 | BG2_ENABLE );
   
   for(loop=0;loop<256;loop++)
   {BGPaletteMem[loop]=backgroundPalette[loop];}

   /*for(x=0;x<(120*160);x++)
      {

         FrontBuffer[x]=backgroundData[x];
      }*/
   for (y=0;y<160;y++)
   {
      for(x=0;x<120;x++)
      {
         FrontBuffer[ (y*120)+x] = backgroundData[(y*120)+x];
      }
   }
         
   return(0);
}


The tutorial I used offers two examples to perform the same task, as you can see form the commented secion, I have tried both examples. Both give the same result. When I compile (no errors) and run it in VisualBoy Advance, it throws up a solid green screen. What have I dont wrong???

Thanks all in advance.

-pr0v

Last edited by pr0vidence on Wed Jun 22, 2005 8:48 pm; edited 1 time in total

#46277 - poslundc - Wed Jun 22, 2005 6:31 pm

Copied it verbatim...? Are you sure there wasn't a "while (1)" in there?

Dan.

#46280 - pr0vidence - Wed Jun 22, 2005 6:42 pm

Positive.

This is the tutorial I was copying from:

http://home.no/neogeo/HOVEDSIDE_INDEX/GBA_HOVEDSIDE_INDEX_ENGELSK/GBA%20HTML%20LEKSJONER%201-5/GBA_Lek3_english.htm

all the way at the bottom

I should say NEARLY verbaTim because I had to chance BG_PaletteMem to BGPaletteMem to coincide with the gba.h that I am using.

also I added "return(0);" to keep the compiler from complaining.

Thanks
-pr0v

EDIT: for spelling verbaTIM, I don't know why I kept missing the T.

Last edited by pr0vidence on Wed Jun 22, 2005 8:47 pm; edited 1 time in total

#46281 - yaustar - Wed Jun 22, 2005 6:48 pm

have you checked the VRAM using VBA to see if everything has been loaded properly?

#46284 - poslundc - Wed Jun 22, 2005 6:57 pm

Try adding a "while (1);" on the line before "return (0);".

Dan.

#46286 - strager - Wed Jun 22, 2005 7:05 pm

Code:
#include "gba.h"
#include "background.h"

int main()
{
   int x,y;
   int loop;
   
   SetMode (MODE_4 | BG2_ENABLE );
   
   for(loop=0;loop<256;loop++)
   {BGPaletteMem[loop]=backgroundPalette[loop];}

   /*for(x=0;x<(120*160);x++)
      {

         FrontBuffer[x]=backgroundData[x];
      }*/
   for (y=0;y<160;y++)
   {
      for(x=0;x<120;x++)
      {
         FrontBuffer[ (y*120)+x] = backgroundData[(y*120)+x];
      }
   }

        while(1);
   return(0);
}


What are FrontBuffer, backgroundpalette, BGPaletteMem, and backgroundData defined as? Make sure than in background.h and .c that your arrays are defined as const.

#46299 - pr0vidence - Wed Jun 22, 2005 9:04 pm

yaustar wrote:
have you checked the VRAM using VBA to see if everything has been loaded properly?


ok, just did that, the VRAM seems to match the data that's in background.h at least the first dozen or so do.

background.h was created from a PCX file using PCX2GBA, yes both arrays are const.

Dan, adding the while(1); produces the same result.

strager:
FrontBuffer = #define FrontBuffer ((u16*)0x6000000)
BGPaletteMem = #define GBPaletteMem ((u16*)0x5000000)
the gba.h I am using is the one supplied by dovoto in his tutorial set.

Here is the image I am trying to display, I know it's nothing fancy just something I blotched on with colors as a test pattern:

http://www.boomspeed.com/pr0vidence/gba/background.pcx

and here is the background.h that PCX2GBA created:
http://www.boomspeed.com/pr0vidence/gba/background.h

Thanks for trying to help me everyone, I do appreciate it

-pr0v

#46302 - strager - Wed Jun 22, 2005 9:49 pm

Odd.

Did you try setting the rotation/scaling parameters? That might be the reason why only green is displayed, because the top-left pixel is green...

#46304 - pr0vidence - Wed Jun 22, 2005 10:01 pm

I don't believe I have, how would I go about doing that?

-pr0v

#46306 - pr0vidence - Wed Jun 22, 2005 10:22 pm

ok... some nosing around with VBA presented some interesting things.

here is the compiled ROM, if you wish to take a look

http://www.boomspeed.com/pr0vidence/gba/imagedisp.gba

If you open it in VBA you get the green screen.

If you open the Palette Viewer, you get the palette as it should be, there's only four colors in the test pattern I threw together.

If you open Tools -> Map Viewer, my image shows up, so it's IN there as it should be.... yet for some reason is not being displayed properly on screen. Maybe that gives someone a hint?

-pr0v

#46307 - DekuTree64 - Wed Jun 22, 2005 10:33 pm

Yep, your rotation values are set wrong. Not sure why though, they should start up initialized to display as normal.

To fix it put this somewhere (anywhere will work, might as well put it by the SetMode for clarity):

Code:
REG_BG2PA = 256;
REG_BG2PB = 0;
REG_BG2PC = 0;
REG_BG2PD = 256;


That will scale to normal size with no rotation.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

Last edited by DekuTree64 on Wed Jun 22, 2005 10:50 pm; edited 1 time in total

#46308 - pr0vidence - Wed Jun 22, 2005 10:41 pm

SUCCESS!

thanks a lot!

(I had to change a few "P"s to "B"s but it works)

now can you tell me what, exactly, those mean what what it did to fix it? Will I need to just include those four lines in any program I write?

-pr0v

#46310 - DekuTree64 - Wed Jun 22, 2005 11:17 pm

pr0vidence wrote:
(I had to change a few "P"s to "B"s but it works)

Oops, sorry about that :)

Quote:
now can you tell me what, exactly, those mean what what it did to fix it? Will I need to just include those four lines in any program I write?

It' sort of a rotation matrix. If you've ever written a rotozoomer effect, you've done what the hardware does.

Basically PA is `x per x', PB is `x per y', PC is `y per x', and PD is `y per y'.
Each time the hardware advances one pixel to the right, it adds PA to x and PC to y in its internal accumulators.
Each time it advances one row down, it adds PB to x and PD to y.

The values are 8-bit fixed-point, so 256 is 1.
When they're set to 1,0,0,1, that means each time it advances one x pixel, it adds PA (1) to x, and PC (0) to y. That just advances one x pixel per x pixel, so no scaling.
Then each y pixel, it adds PB (0) to x, and PD (1) to y, so one y pixel per y pixel, again no scaling.

For rotation, you set them like
PA = cos(angle)
PB = sin(angle)
PC = -sin(angle)
PD = cos(angle)

Which if you look at, when then angle is 0, cos(0) is 1, and sin(0) is 0, so you get 1,0,0,1, same as we hardcoded to before.
At 90 degrees, you get cos(90)=0, sin(90)=1, -sin(90)=-1, cos(90)=0.
Then each X pixel you move 0x, -1y. Each y pixel, you move 1x, 0y. Successfully rotated clockwise around the top left corner of the screen.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku