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 > problem with memcpy

#70205 - deltree - Sun Feb 05, 2006 12:52 am

hi
I've got a new problem using memcpy:
I want to fill the palette for my sprite, here's what i do:
Code:
   
   for (i=0;i<256;i++) objpal[i]=roger_Palette[i];

it display that
[Images not permitted - Click here to view it]
and now I try to do it with memcpy, doing this:
Code:

memcpy( (u16 *)0x06014000, &roger_Bitmap,4096 );

it display that:
[Images not permitted - Click here to view it]

so the problem is that the sprite as his palette messed when I use memcpy, and I don't know why.
anyone got a solution ?

#70224 - tepples - Sun Feb 05, 2006 2:49 am

Perhaps the memcpy implementation that you're using assumes that byte writes will always work. Which version of devkitPro are you using?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#70308 - Cearn - Sun Feb 05, 2006 12:37 pm

Point of interest: using lossy compression (jpeg) images to show graphical problems? Not the best way to go.

As far as I know, if the size is larger than 16 and both source and destinations are word aligned, it'll copy via a 4x unrolled loop using word chunks. In all other cases, it uses byte-copies. Which as we all know is bad when it comes to VRAM. I can't be sure if the newlib I got it from is the same one as in devkitPro (because there's no links to where everything comes from), but the problems I've seen with memcpy fit the description.

The problem could be the alignment. You wouldn't be #including the data files, would you? Compile / link them might fix that problem.

Still, what you got here doesn't seem like a memcpy problem at all, actually: if it were we'd see doubled pixels, not color changes. Can we actually find the .gba's somewhere? Screenshots doesn't really help in this case.

#70333 - tepples - Sun Feb 05, 2006 6:40 pm

Cearn wrote:
Still, what you got here doesn't seem like a memcpy problem at all, actually: if it were we'd see doubled pixels, not color changes.

Unless it's the palette that's misaligned.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#70337 - deltree - Sun Feb 05, 2006 7:00 pm

when I use visual boy advance, here's what I see from the palette:
it looks like this with the good color (for loop):
4AF2, 43ED, 5AAE,3A6A....
and with the memcpy, it looks like this:
4A4A, 4343, 5A5A,3A3A....

#70341 - Dwedit - Sun Feb 05, 2006 7:47 pm

Your memcpy is doing byte writes, which get expanded to word writes in vram. So writing 41, 5A would first write 4141, then 5A5A to the palette. If you use 16 bit or 32 bit writes, it won't double the bytes and overwrite adjacent bytes.

Your memcpy implementation is unsuitable for GBA programming, go find a better library.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#70343 - tepples - Sun Feb 05, 2006 8:29 pm

Do you know how to print the address of an array? What is the address of the palette data in your ROM?

You may have to write your own replacement for memcpy() that understands non-byte-writable memory.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#70767 - Cearn - Wed Feb 08, 2006 5:14 pm

0x0601:4000 is the address of the sprite tiles, what we're interested in are the addresses of the palette. The source palette, not where you put them in GBA memory, because that's likely to be 0x0500:0200 anyway. Also, what are the types of the arrays you're using?

We're expecting the problem to be linked to data misalignment, but to be sure we need the source addresses of the arrays -- where the linker actually places the things. The destinations are probably fine. Here is a post that might be interesting to read as well.

As I asked before, are you #including the data files instead of linking them? If so, stop that; compile separately and link them and see if that helps. Or use u32 arrays instead of u16.