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.

Graphics > animation troubles

#38834 - Hacim - Fri Apr 01, 2005 4:57 am

Hello I'm new here so if there is a post that already answers this please tell
me.
Anyway,my problem is trying to load a image into the OAM with DMA to when I press 'right' it will load one sprite and when I press 'left' it will load another.But when i do that it for some reason over writes part of the memory
reserved for a different object.The first object is a 32x32 image and I have the second sprite attribute2 looks like this 'attribute2=544;' is this wrong? It works fine if the attribute2 is set to 'attribute2=576;'.
anybody know?

thanks. -Hacim

#38840 - FluBBa - Fri Apr 01, 2005 9:13 am

You shouldn't load images to the ObjectAttributeMemory, you should load them to the VRAM for objects (0x06010000).
Post some code for us to see.
_________________
I probably suck, my not is a programmer.

#38869 - Hacim - Fri Apr 01, 2005 4:17 pm

I guess I didn't make that very clear.Here's the code I use for changing the sprite:
Code:
if (face!='r')DMAFastCopy((void*)spriteData,(u16*)0x06014000, 512, DMA_32NOW);


and this is what the second object's atributtes look like right now:
Code:
sprites[1].attribute0=COLOR_256|SQUARE|100;
    sprites[1].attribute1=SIZE_16|50;
    sprites[1].attribute2=576;


and the area of memory that the second sprite data is stored is 0x06014800.
Maybe that will help.

#38884 - FluBBa - Fri Apr 01, 2005 5:00 pm

Check in VBA's tileviewer to make sure you get what you expect there, then just click on the tile and you'll see it's number...
_________________
I probably suck, my not is a programmer.

#39082 - Cearn - Mon Apr 04, 2005 10:57 am

Hacim wrote:
Code:

if (face!='r')DMAFastCopy((void*)spriteData,(u16*)0x06014000, 512, DMA_32NOW);

512 words clears 512/8 = 64 tiles, i.e. 512 to 575. Try 256.

#40664 - sgeos - Thu Apr 21, 2005 10:26 am

Cearn wrote:
Hacim wrote:
Code:

if (face!='r')DMAFastCopy((void*)spriteData,(u16*)0x06014000, 512, DMA_32NOW);

512 words clears 512/8 = 64 tiles, i.e. 512 to 575. Try 256.


You should figure out a way to replace that 512 with a sizeof() operation if at all possible. Failing that, a macro will do.

-Brendan

#40670 - Cearn - Thu Apr 21, 2005 11:51 am

But a sizeof() might not work properly. You would need to include the file with the data into the file with the code (which you shouldn't) in order for sizeof() to be able to guess the proper size, or use something like "extern u16 spriteData[512]", for which you need to know the size anyway. If your data files are compiled separately and you're make them visible to the code by declaring pointers to them, you'll get the size of the pointers, not of the array itself.

But regardless of that, the exporter should have a define or constant that shows how big the data is: spriteDataLen, SPRITE_SIZE or something similar.

#40768 - sgeos - Fri Apr 22, 2005 10:31 am

Cearn wrote:
But a sizeof() might not work properly.

sizeof() works properly if you call it on the right "thing".

Cearn wrote:
You would need to include the file with the data into the file with the code (which you shouldn't) in order for sizeof() to be able to guess the proper size, or use something like "extern u16 spriteData[512]", for which you need to know the size anyway.

My point is that magic numbers are bad. I prefer sizeof() over #define because manually tweaking the data will not break the code. You could do something like this:

data.h
Code:
extern const type_t data[];
extern const type_t int DATA_SIZE;
extern const type_t int DATA_MEMBERS;


data.c
Code:
const type_t data[] =
{
};

const int DATA_SIZE = sizeof(data);                     /* size of data (in bytes) */
const int DATA_MEMBERS = sizeof(data) / sizeof(type_t); /* members in array */

DATA_SIZE and DATA_MEMBERS look like macros, and behave like macros, but are assigned using sizeof().

Cearn wrote:
If your data files are compiled separately and you're make them visible to the code by declaring pointers to them, you'll get the size of the pointers, not of the array itself.

Thats a case where a direct sizeof is not possible. Attempting to use sizeof(ptr_to_data) would be an error on the part of the programmer.

Cearn wrote:
But regardless of that, the exporter should have a define or constant that shows how big the data is: spriteDataLen, SPRITE_SIZE or something similar.

I agree. This is always possible. If you always generate your "data" with an exporter, a #define works just fine.

-Brendan

#40789 - tepples - Fri Apr 22, 2005 5:46 pm

Code:
extern const char data[];

size_t sz(void)
{
  return sizeof(data);
}

Wouldn't this make "error: can't take sizeof a variable with incomplete type", or does GCC allow link-time resolution of sizeof() as an extension to the C language?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#41042 - sgeos - Sun Apr 24, 2005 2:25 pm

tepples wrote:
Code:
extern const char data[];

size_t sz(void)
{
  return sizeof(data);
}

Wouldn't this make "error: can't take sizeof a variable with incomplete type", or does GCC allow link-time resolution of sizeof() as an extension to the C language?


I get the same error, but this compiles fine:
Quote:
typedef int type_t;

extern const type_t data[];
extern const type_t DATA_SIZE;
extern const type_t DATA_MEMBERS;

const type_t data[] =
{
1,2,3
};

const int DATA_SIZE = sizeof(data);
const int DATA_MEMBERS = sizeof(data) / sizeof(type_t);

make sizeoftest.o