#22927 - Wriggler - Thu Jul 01, 2004 1:09 pm
When doing all of this tutorial stuff, there's something that confuses me a little bit.
Where does OAM stuff get stored? Is it in EWRAM, or IWRAM, or anywhere else? And where does the actual bitmap data for a sprite go? Video memory?
It's not really obvious where each bit goes. I know that bitmaps are loaded into EWRAM, and then the front buffer is located in the video memory. Is that right?
Can anyone summarise for me please? I'm so confused... :)
Ben
#22928 - poslundc - Thu Jul 01, 2004 1:38 pm
| Wriggler wrote: |
When doing all of this tutorial stuff, there's something that confuses me a little bit.
Where does OAM stuff get stored? Is it in EWRAM, or IWRAM, or anywhere else? |
OAM is stored in OAM - Object Attribute Memory, that is. It's a 1 KB memory chip specifically tasked with storing and retrieving sprite attributes for the video processor.
| Quote: |
| And where does the actual bitmap data for a sprite go? Video memory? |
Yes. There are two sections of VRAM: one for storing backgrounds/bitmaps and one for storing sprite tile data.
| Quote: |
| It's not really obvious where each bit goes. I know that bitmaps are loaded into EWRAM, and then the front buffer is located in the video memory. Is that right? |
You can load bitmaps/sprites into EWRAM if you really want to, and this is sometimes a useful/necessary step if you've compressed the images before storing them in the ROM. If your data is uncompressed, though, there is nothing stopping you from copying it directly in from the ROM to VRAM. Although it is recommendable that you restrict yourself to doing it:
- when your game starts up
- during the VBlank period (if you only have some changes to make from one frame to the next)
- (if you have a lot to change) with the screen faded to a solid colour (eg. when switching from one level/bitmap to the next)
... so that you don't create screen artifacts.
| Quote: |
| Can anyone summarise for me please? I'm so confused... :) |
http://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm#Memory%20Map
Dan.
#22934 - Wriggler - Thu Jul 01, 2004 4:07 pm
Dan,
Thanks for the reply. I didn't realise that OAM was actually a separate memory chip, I thought it was just a small piece of working ram that was set aside for holding the sprite stuff.
Ok, and so now I understand that the bitmaps are loaded straight from ROM memory to video memory. Gotcha.
Two more quick questions:
1. If I just make a normal variable, of whatever type, is that stored by default into IWRAM (the faster of the two rams)?
2. It's my understanding that to store something in EWRAM (slower speed, more space), you simply declare it as "const" and the compiler does the rest. Is that right?
Thanks for the help, I really do appreciate it. It's always best to be 100% sure about these kind of things, and never make assumptions...
Thanks again,
Ben
#22935 - alek - Thu Jul 01, 2004 4:28 pm
| Wriggler wrote: |
1. If I just make a normal variable, of whatever type, is that stored by default into IWRAM (the faster of the two rams)?
|
Yes, that is correct
| Quote: |
2. It's my understanding that to store something in EWRAM (slower speed, more space), you simply declare it as "const" and the compiler does the rest. Is that right?
|
I think you have to use malloc or new if you want to store something in EWRAM and if you declare something as const it will be stored into ROM
#22936 - poslundc - Thu Jul 01, 2004 4:33 pm
| Wriggler wrote: |
| 1. If I just make a normal variable, of whatever type, is that stored by default into IWRAM (the faster of the two rams)? |
Both local and global variables are, by default, stored in IWRAM.
| Quote: |
| 2. It's my understanding that to store something in EWRAM (slower speed, more space), you simply declare it as "const" and the compiler does the rest. Is that right? |
All of the data you want loaded into the game must be stored on the physical cartridge, which means storing it in the ROM.
Declaring a variable as "const" indicates to the compiler to leave it in ROM, versus variables you declare with initial values, which are copied from ROM to IWRAM when the GBA is booted up.
EWRAM is only used in three situations:
1. If you have a multiboot game, in which case there is no cartridge and no ROM, so all of the code and data (including const data) is transmitted over the link cable to the GBA's EWRAM. This is why multiboot games are small: they are limited to 256 KB, which is the size of EWRAM.
2. I think most devkits implement the malloc() function so that it uses EWRAM instead of IWRAM. Some may use IWRAM, though, so you ought to check if you want to use malloc (many people, myself included, do without it, though).
3. If you manually access EWRAM in your code by declaring a pointer in the EWRAM address space (easiest IMO), or using an attribute tag on your variable declaration (someone else would have to give you the syntax to do this).
Dan.
#22937 - isildur - Thu Jul 01, 2004 4:40 pm
| poslundc wrote: |
3. If you manually access EWRAM in your code by declaring a pointer in the EWRAM address space (easiest IMO), or using an attribute tag on your variable declaration (someone else would have to give you the syntax to do this).
Dan. |
this is how I do it:
| Code: |
// in an .h file
#define CODE_IN_IWRAM __attribute__ ((section (".iwram"), long_call))
#define CODE_IN_ROM __attribute__ ((section (".text"), long_call))
#define IN_IWRAM __attribute__ ((section (".iwram")))
#define IN_EWRAM __attribute__ ((section (".ewram")))
// in a module
IN_IWRAM u32 someData[128];
IN_EWRAM u32 someMoreData[128];
|
#22939 - poslundc - Thu Jul 01, 2004 4:50 pm
I would think that the IN_IWRAM macro would be unnecessary, since that is where all non-const data defaults to.
CODE_IN_ROM should also be generally unnecessary, since all code defaults to ROM. The only place it would make sense is in the prototype for a function being called from IWRAM/EWRAM, and IIRC there was a discussion in another thread about how devkitadvance apparently doesn't support that format of long_call yet.
Dan.
#22945 - Wriggler - Thu Jul 01, 2004 6:39 pm
I see. Const leaves it on the cart. That makes sense.
So EWRAM wasn't nearly as useful as I first thought! Fair enough. Thank you to all those who responded, you really are helping out a novice in the ways of Gameboy!
Cheers,
Ben