#63596 - Cthulhu32 - Wed Dec 14, 2005 9:51 pm
I've been chatting a bit with #gbadev guys, but seems like everyone points away from the libraries that come with the devkitPro package. I'm trying to adjust to using libgba, however I'm slightly confused in the gba_sprite.h file. I've already run doxygen against the package myself and found this was one of the many files without doxygen comments.
So I was wondering if anyone has any examples of using sprites with the libgba library? The best I've found is this: http://paste.atopia.net/157 but I'm not sure what kind of setup he had on the s_piece_bin.h or how he set that up?
Also, what do people do for defines such as TALL 0x8000 and all of those sprite calls? Should I just add this into gba_sprites.h, link my own sprites from gba_sprites.h? any other suggestions?
#63745 - Cthulhu32 - Fri Dec 16, 2005 1:44 am
Does nobody use the libgba library? All I really need to get started is an example of a sprite call, how you copy the memory & palette correctly, and how to update the OAM correctly with libgba to display the sprite.
#63747 - crossraleigh - Fri Dec 16, 2005 2:12 am
Judging from the pasted code, s_piece_bin is an 8x8, 256-color sprite cel. It was probably created using gfx2gba or a similar program.
In libgba, sprite size is set with OBJ_SIZE(), just like shape is set with OBJ_SHAPE(). Use OBJ_SIZE(2) to get the same effect as TALL.
Use memcpy(), DMA, or CpuFastSet() to copy the sprite palette, cel, and attributes. You will usually want to keep a working version of OAM:
| Code: |
OBJATTR shadow_oam[128]; // Change this instead of real OAM.
CpuFastSet(shadow_oam, OAM, sizeof(shadow_oam) / sizeof(int)); // Call this every v-blank. |
_________________
My world is black and white, but if I blink fast enough, I see it in grayscale.
#63792 - Cthulhu32 - Fri Dec 16, 2005 9:36 am
hey thanks a lot, that actually helps considerably. So I have a quick question about that code snippet, he uses the same palette for the background & the sprite correct?
Maybe if I try to put comments on all of these, people can correct me where I'm wrong
| Code: |
memcpy(BITMAP_OBJ_BASE_ADR + 0x1000, s_piece_bin, 64);
|
-------- 8x8 sprite copied to our BITMAP_OBJ_BASE_ADR plus 0x1000, not sure exactly why he chose to move it that far ahead?
| Code: |
// Assuming that DecodePCX loads the background palette into a
// buffer that i can also use for my sprite.
memcpy(OBJ_COLORS, PaletteBuffer, 512);
|
-------- copies the background's palette to the OBJ_COLORS palette, which I understand how to use individual sprite palettes for, but I guess he decided to use the same palettes.
| Code: |
// these should be the only attributes worth setting right now
sprite.attr0 = OBJ_256_COLOR;
sprite.attr2 = 512;
|
-------- all the sprite info, like X/Y coords, palette used for 16 color sprites, etc.
| Code: |
memcpy(OAM, &sprite, sizeof(sprite));
|
-------- copies the data at our sprite pointer to the OAM
so the best way to copy to the OAM is to use the CpuFastSet, the built in gba copier, and call this like
| Code: |
OBJATTR shadow_oam[128]; // Change this instead of real OAM.
memcpy(shadow_oam, sprite, sizeof(sprite)); //something like this?
CpuFastSet(shadow_oam, OAM, sizeof(shadow_oam) / sizeof(int)); // Call this every v-blank.
|
#64411 - Cthulhu32 - Thu Dec 22, 2005 3:56 am
ok, so I got it all figured out & figured out all the shadow_oam & oam business works. If anyone else is curious about this because I honestly did not find any good documentation on the libgba specific way of doing things I'll write my findings. I also noticed something about copying sprites into the shadow_oam, because they use OBJATTR, you only need to increment the BITMAP_OBJ_BASE_ADR + 0x1 to increase which OAM its copying to.
So for example,
sprite1 = some sprite w/ attributes of sprite 1
sprite2 = some sprite w/ attributes of sprite 2
your memory copy would look like
memcpy(shadow_oam, sprite1, sizeof(sprite1));
memcpy(shadow_oam + 0x1, sprite2, sizeof(sprite2));
then after you CpuFastSet your shadow_oam to your oam, it would all match correctly.
now to see if I can figure out how to make Usenti output transparancies from pcx files instead of manually having to go through the .h created.
#64448 - Cearn - Thu Dec 22, 2005 1:15 pm
| Cthulhu32 wrote: |
| If anyone else is curious about this because I honestly did not find any good documentation on the libgba specific way of doing things I'll write my findings. |
Keep in mind that what matters is in terms of tutorials is how you deal with the hardware, which is the same for every library that you may find. The names that the various libs use are irrelevant.
| Cthulhu32 wrote: |
I also noticed something about copying sprites into the shadow_oam, because they use OBJATTR, you only need to increment the BITMAP_OBJ_BASE_ADR + 0x1 to increase which OAM its copying to.
|
May have misunderstood your meaning here, but BITMAP_OBJ_BASE_ADR is not part of OAM, it's part of VRAM. The only connection between the two is oam attribute 2, which specifies which part of VRAM the sprite should display.
| Cthulhu32 wrote: |
So for example,
sprite1 = some sprite w/ attributes of sprite 1
sprite2 = some sprite w/ attributes of sprite 2
your memory copy would look like
memcpy(shadow_oam, sprite1, sizeof(sprite1));
memcpy(shadow_oam + 0x1, sprite2, sizeof(sprite2));
then after you CpuFastSet your shadow_oam to your oam, it would all match correctly.
|
Sprite to shadow_oam to oam ... you're shadowing your shadow_oam? Well, whatever floats your boat I guess :P
One oam buffer is quite enough, and sometimes even that is unnecesary. Furthermore, using memcpy to copy a single OBJATTR is not recommended. Because it's only 8 bytes, memcpy might do it in byte-size steps, which is slow and wouldn't even work when copying to OAM because, like VRAM, it has the no-byte-write restriction. Besides, C allows struct copies so you could just use
| Code: |
shadow_oam[0]= sprite1;
shadow_oam[1]= sprite2; |
Not quite as fast as CpuFastSet when you copy the whole thing, but still pretty fast.
| Cthulhu32 wrote: |
| now to see if I can figure out how to make Usenti output transparancies from pcx files instead of manually having to go through the .h created. |
The transparent color is always that of palette index 0. If you're using a different index, simply swap them first (select both indices in the palette, Alt+S). Oh, and you mean C files; there's no data in Usenti's headers, because that's not what headers are for.
#64497 - Cthulhu32 - Thu Dec 22, 2005 11:18 pm
whoops, yeah I meant OAM + 0x1 to increase which OAM it copies too.
ahh alright, that looks like a much better way of taking care of the shadow_oam.
Ok, quick question about that, so is there a perk to using a shadow_oam then cpufastsetting it? I was mainly following crossraleigh's example, but I couldn't really come up with any reasons to use it besides having a prebuilt sprite set you can just CpuFastSet when changing scenes possibly?
I got the transparent palette part figured out, the CowBite Specs is really useful, and you're right, it doesn't matter which library you use because they're all using the gba hardware for the same purpose. Honestly I just had not had any real experience dealing with pre-built libraries like libgba, all they really taught me in school was how to use the std in C++, and a few built in .NET libraries.
#64531 - tepples - Fri Dec 23, 2005 7:35 am
| Cthulhu32 wrote: |
| so is there a perk to using a shadow_oam then cpufastsetting it? |
It lets you construct different parts of your OAM display list without having to worry about a half-built one showing up on screen. You build the display list in shadow_oam in the draw time and then copy it to OAM during vblank.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.