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.

Coding > staringmonkey's modifications to gba.h

#6148 - Daedro - Sun May 18, 2003 8:31 am

I was just wondering which people prefer and why. The original files by eloist which are:

Code:

///////////////////Bits///////////////////
#define BIT0          1
#define BIT1          (1<<1)
#define BIT2          (1<<2)
#define BIT3          (1<<3)
#define BIT4          (1<<4)
#define BIT5          (1<<5)
#define BIT6          (1<<6)
#define BIT7          (1<<7)
#define BIT8          (1<<8)
#define BIT9          (1<<9)
#define BIT10          (1<<10)
#define BIT11          (1<<11)
#define BIT12          (1<<12)
#define BIT13          (1<<13)
#define BIT14          (1<<14)
#define BIT15          (1<<15)

while the rest is inputed manaully:

#define KEY_A         1
#define KEY_B         2
#define KEY_SELECT         4
#define KEY_START         8
#define KEY_RIGHT         16
#define KEY_LEFT         32
#define KEY_UP         64
#define KEY_DOWN         128
#define KEY_R         256
#define KEY_L         512


as to staringmonkey's changes to referals:

Code:

/////////////////Bits////////////////
#define BIT00          1
#define BIT01          2
#define BIT02          4
#define BIT03          8
#define BIT04          16
#define BIT05          32
#define BIT06          64
#define BIT07          128
#define BIT08          256
#define BIT09          512
#define BIT10          1024
#define BIT11          2048
#define BIT12          4096
#define BIT13          8192
#define BIT14          16384
#define BIT15          32768

while the others call upon:

#define KEY_A          BIT00
#define KEY_B          BIT01
#define KEY_SELECT         BIT02
#define KEY_START         BIT03
#define KEY_RIGHT         BIT04
#define KEY_LEFT         BIT05
#define KEY_UP          BIT06
#define KEY_DOWN         BIT07
#define KEY_R         BIT08
#define KEY_L          BIT09


It seems the changes are useful in recall, but when:

Code:
#define ROTBG_SIZE_1024x1024           0xC000


that, is now this:

Code:
#define ROTBG_SIZE_1024x1024           BIT14 | BIT15


I dont know all these bits, and numbers to call yet but I have gotten errors over things like these. I like the recall method, but what happens here and how does bit14 and 15 which are 32768 and 16384 = 0xC000 or is a choice, if so how do I choose?

Anyway which way do you prefer or use, or do you do your own style.

#6157 - SmileyDude - Sun May 18, 2003 3:26 pm

I have my own -- I started with eloist's version, but I quickly expanded it with more macros, and library functions. Also, eloist had different names for registers than the Cowbite doc, so I changed it to match.

Personally, I say use what works for you... you don't really care much how the bits are represented in the header file while your working with your game code, so use the header file that has what you need, and add anything that might be missing.
_________________
dennis

#6161 - antysix - Sun May 18, 2003 5:55 pm

I prefer to use the numbers, not the bits because I just like that better.
But really, it doesn't matter.
_________________
Currently playing: NGC: Metroid Prime
GBA: Golden Sun: The Lost Age

Currently developping: Project ~ [ Phail ]

#6165 - Maddox - Sun May 18, 2003 6:52 pm

Daedro done wrote:
Quote:

Code:

#define ROTBG_SIZE_1024x1024           BIT14 | BIT15



You might want to try putting parentheses around your macro bodies. And it might be helpful for you to purchase and read a good introductory programming book or maybe a computer engineering book so you can understand bits better. Then you'll get less errors. (I think all those decimal numbers in those #defines should be hexadecimal.)

~MADDOX!

#6169 - Daedro - Sun May 18, 2003 8:17 pm

Okay, will do, I just need to save up some money. I still need to buy a flash linker. Anyone know any trading communities? I bought Zelda: A Link To The Past, and D&D Eye of The Beholder unknowning that they were converted old games and I cant even play Four Swords.

One other problem I have is with #include <math.h> and #include <string.h>
These are to be included from the compiler right? well I get errors saying they cannot be found. Also I have commands like sprintf, rand, srand, and ads that are first functions and I cant find them anywhere, it must be from the string.h. Anyone know how this can be solved?

I get these errors from the RPG demo at thepernproject that was made by staringmonkey.

#6203 - antysix - Mon May 19, 2003 7:42 pm

I think you should download the newest version of DevKitAdv, if the compiler can't find math.h en string.h

The rpg demo made by staringmonkey was made for ARM SDT, the compiler most used before DevKitAdv, the differences between the two are not much but I thought ARM SDT uses boot.asm and another name for main()
_________________
Currently playing: NGC: Metroid Prime
GBA: Golden Sun: The Lost Age

Currently developping: Project ~ [ Phail ]

#6212 - Drago - Tue May 20, 2003 12:16 am

I think this is a general advice from the GBA community:
Math.h is totally useless in GBA programming, because is focused on floating point operations. The hardware lacks of floating point unit and all operations are emulated by software, making them a lot slow. Use fixed point instead.
About string.h, it has some text processing functions that could be usefull if your program makes intensive use of text. The rest are mainly functions for memory operations, but the best performance is achieved by using DMA and BIOS functions.
My personal advice is: avoid using any external library, make your own.

Anyway, if you are still interested in using the math and string headers (and you are using DKA): try adding the -I option to the gcc command line like this:

gcc -I <path_to_include_files> ... other options and files

In my DKA installation the path is /devkitadv/arm-agb-elf/include
Probably you will also need to link the math library by adding the -lmath option.

#6213 - Daedro - Tue May 20, 2003 12:38 am

antysix wrote:
I think you should download the newest version of DevKitAdv, if the compiler can't find math.h en string.h

The rpg demo made by staringmonkey was made for ARM SDT, the compiler most used before DevKitAdv, the differences between the two are not much but I thought ARM SDT uses boot.asm and another name for main()


Yeah I have the most recent version of DevKitAdv, and I noticed its for ARM.

Quote:
Math.h is totally useless in GBA programming, because is focused on floating point operations. The hardware lacks of floating point unit and all operations are emulated by software, making them a lot slow. Use fixed point instead.


I will do that for my own code. I only have 4 commands that lead from no where, but the problem is that I dont know what they are suppose to define. I cant very well add numbers and things in when I have no clue what it does. If I could see what this command 'abs' and 'sprintd' and 'rand' and 'srand' were suppose to be, maybe I could do that. These were made by staringmonkey in ARM, but he switched to devkitadv, and said he cant remember what they were now as theres too much other coding in his head.

Should I just define 'srand' as 1 and let it go at it to see what it does? seriously dont know what to do. Antysix, you want to take a crack at it? reply to my emails.

Side question, if I copy a background to DMA3 lets say, and then I copy another background to DMA3 later does it overwrite that data and erase the old data?:

Lets say I have LAYER01 on DMA3, then if I press start I now have LAYER02 on DMA3 is that background then erased or are they both on there? It may be in the beginning tutorials, but how do I delete DMA? I will go check, but their are a lot and not a lot tell.

#6214 - niltsair - Tue May 20, 2003 12:43 am

DMA's are just a method to quickly transfert a big chunk of valuee from 1 point in memory to another one.

So, when you use DMA3, you dn't store any value in it, you have to specify get what data(src address) to where(dst address) and how many to copy (and soe other little options). So, unless you specify the same destination address, no, your data don't get overwritten.

Unless you meant somethign else by DMA.

#6215 - Daedro - Tue May 20, 2003 1:03 am

Yes I did mean to same address. Like if I did:

Code:
DMA_Copy(3,(void*)testMap.pal,(void*)BGPaletteMem,256,DMA_16NOW);

DMA_Copy(3,(void*)testMap.tiledata,(void*)CharBaseBlock(0),testMap.tileDataSize/4,DMA_32NOW);


Then I later wanted to use a different palette and tiles and did:

Code:
DMA_Copy(3,(void*)newMap.pal,(void*)BGPaletteMem,256,DMA_16NOW);

DMA_Copy(3,(void*)newMap.tiledata,(void*)CharBaseBlock(0),newMap.tileDataSize/4,DMA_32NOW);


same position just different data.. im sure this would overwrite the old data.

But I mixed them up, I was wondering if I did this:

Code:
void BlitBG(u16* bgMap, const u16* data, int dataw, int x, int y)
{
   int loopx,loopy;
   
   //x and y are pixle locations...we need tile locations so divide by eight (>>3)   
   x = x >> 3;
   y = y >> 3;

   for(loopy = 0; loopy < 32; loopy++) //loop through all 32x32 tiles
   {
      for(loopx = 0; loopx < 32; loopx++)
      {
         //this is were the data from our map editor is copied to video memory
         bgMap[loopx + loopy * 32] = data[(loopx+x) + (loopy+y) * dataw];
   
      }

   }
}


That is the starter script, this is the recall:

Code:
u16* bg0map =(u16*)ScreenBaseBlock(31);

BlitBG(bg0map,testMap.layers[1].data, testMap.layers[0].w,0,0);


now I have a map copied to video memory called bg0map, then I also do another with bg1map... after they are both loaded I press start and no longer need bg0map, how exactly do I delete the video memory block that holds the bg0map data ( wouldn't that make it slower being there when not being showed ) or do I just overwrite it later if I need it? I dont really know what I am talking about, so just ignore my ignorance if you can. I just know there is data being copied, and I might not need it later, how would I delete it. I know this becuase I sometimes dont copy the data and just place the data and as I move the map and then move back the data is gone.. an eraseble map :)

#6216 - Drago - Tue May 20, 2003 1:20 am

Im not sure if this will help: if you dont need to show the data on bg0 just switch off its corresponding bit on REG_DISPCNT.

#6219 - Daedro - Tue May 20, 2003 1:56 am

Okay..

So turn on BG01, and BG02
then turn off BG01, leave BG02
then replace BG01 and turn on, then turn off BG02

That works...

I dont exactly know the code, but knowing I can do that helps. .. BIT09 is BG01 and REG_DISPCNT is 0x4000000... any help? lol

also, with code from a tutorial I get an error:


Quote:
start.cpp: In function 'void Flip()':
start.cpp:60: non-lvalue in assignment
start.cpp:65: non-lvalue in assignment


I could sware it was an error for 59 and 64 before.. wierd. From code:

Code:
55: void Flip(void)
56: {
57:    if(REG_DISPCNT & BACKBUFFER)
58:    {
59:       REG_DISPCNT &= ~BACKBUFFER;
60:       VideoBuffer = BackBuffer;
61:     }
62:     else
63:     {
64:       REG_DISPCNT |= BACKBUFFER;
65:       VideoBuffer = FrontBuffer;
66:    }
67: }


Ignore the numbers as code obviously. This code is used in a tetris game and in a tutorial.. but I get errors.

#6221 - niltsair - Tue May 20, 2003 3:04 am

Having the map still loaded waste no resource, you just need to stop displaying it with the Dispaly register and that's it. When you need to display something else, just overwrite it. Deleting it when not need would actually waste Cpu Time.

For your errors message, pasting the value of the define that are used in the fonction woudl help. So we can see what's wrong with how they're used,

#6224 - Daedro - Tue May 20, 2003 4:13 am

Good to know, thanks.

The defines:

Code:
#define VideoBuffer                    ((volatile u16*)0x6000000)
#define BackBuffer                   ((volatile u16*)0x600A000)
#define REG_DISPCNT       (*(volatile u32*)0x4000000)


from start.cpp:

u16* FrontBuffer = (u16*)0x6000000;


Wonder if it matters that I dont have a BACKBUFFER.. lol. And I notice this "volatile" in front, some gba register have this and some dont.. I am using these. In the file I got this code, the video, back, and front buffer's were in the start.cpp but I already had the back and video in gba.h so I deleted the ones in the start.cpp.

#6227 - niltsair - Tue May 20, 2003 4:25 am

Ok, VideoBuffer, BackBuffer and FrontBuffer are pointers to data, to modify the content, you need to add an '*' in front.
Code:
55: void Flip(void)
56: {
57:    if(REG_DISPCNT & *BackBuffer)
58:    {
59:       REG_DISPCNT &= ~*BackBuffer;
60:       *VideoBuffer = *BackBuffer;
61:     }
62:     else
63:     {
64:       REG_DISPCNT |= *BackBuffer;
65:       *VideoBuffer = *FrontBuffer;
66:    }
67: }

#6231 - Daedro - Tue May 20, 2003 6:03 am

Very nice, thank you a lot. It works right now, accept for the whole changing

Code:
if(REG_DISPCNT & BACKBUFFER)


to

Code:
if(REG_DISPCNT & *BackBuffer)


I just didnt change it and it works fine, just to let you know it says its a "invalid type argument of 'unary *'"

Thanks a lot. Now if you could be of if possible any more of help to me, could you check out this topic: http://forum.gbadev.org/viewtopic.php?t=1253

It has to do with typedef struct and how I cannot rename the variables without syntax errors.

Thanks niltsair, drago, and maddox.