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 > Sprite Animation - General Questions

#14343 - CcSoccer881 - Mon Jan 05, 2004 6:39 pm

Alo all, I've recently picked up my GBA stuff again, after stopping for several months, but I deleted everything I used to have (which wasn't much).

Now for my question. I'm trying to animate sprites, and I've tried a few ways, but it doesn't work.

First, I tried making a 64x64 sprite with 4 frames, each frame being 32x32. I copied this into an array, and tried loading the data at offsets for each of the frames, however this isn't working.

Hopefully someone can give me some general guidelines.

-B.DePesa
_________________
www.rsstudios.net

#14348 - poslundc - Mon Jan 05, 2004 6:54 pm

You need to give more thought to the way the data is stored in memory. In 1D mode, anyway, the first quarter of a 64x64 sprite will be the top 16 scanlines (top two rows of 8x8 tiles) of the sprite. Try using that as the data for a 32x32 sprite and you'll get a shuffled combination of the top-halves of your first two sprites.

Try encoding all four sprites separately, then putting them in memory in that order.

Dan.

#14350 - CcSoccer881 - Mon Jan 05, 2004 7:02 pm

poslundc wrote:
Try using that as the data for a 32x32 sprite and you'll get a shuffled combination of the top-halves of your first two sprites.


That's exactly what I was getting ;)

Quick Question (I'm at school, my code is at home, got about 3 hours before I get home..) :

Would I be able to convert separate files into header files, combine them into one header file (per animation),in their own arrays (given that the palette stays the same), and then just swap the array that's loaded, given the current frame of animation?
_________________
www.rsstudios.net

#14359 - poslundc - Mon Jan 05, 2004 8:18 pm

First of all - don't use header files. This is a bad, bad habit encouraged by many tutorials and converter programs. Save them as .c files, then construct your header files as follows:

Code:
#ifndef SOME_TAG_TO_DEFINE_YOUR_SPRITE
#define SOME_TAG_TO_DEFINE_YOUR_SPRITE

extern const whatever mySpriteData[];

#endif


Where "whatever" should be the data type used in the .c file, whether it's u16 or u32 or int or what have you.

If you don't understand why it should be done this way you can search the forum or ask and I'll post an explanation, but suffice it to say you will live to regret it if you don't start doing it this way early on. :)

Second of all - realize that declaring the array of data doesn't put it into VRAM. It's up to you to do that, and up to you to decide how you want to manage VRAM. If you want to, when you first load in the sprite you can copy all four arrays sequentially into VRAM. Then to display the first sprite, set the tile number of attribute 2 to zero. To display the second one, set it to 16 if you are 16-colour mode, or 32 if you are in 256-colour mode. etc.

Dan.

#14376 - yaustar - Mon Jan 05, 2004 10:33 pm

ok, now I am interested why header files are bad for storing the graphics data. Id it something to do with how header files and source files are defined in the compilar?
_________________
[Blog] [Portfolio]

#14379 - sajiimori - Mon Jan 05, 2004 10:37 pm

This is answered in many threads. Short answer: if you create symbols in a header and include the header in more than one C file, you get duplicate definitions.

Don't:
Code:

// file.h
int a;
void f() {}

Do:
Code:

// file.h
extern int a;
void f();

// file.c
int a;
void f() {}

#14381 - poslundc - Mon Jan 05, 2004 10:47 pm

To slightly expand on that: C files are meant to contain data, whereas header files contain meta-data (structs, prototypes, definitions, no actual content).

Basically, anything in a header file should be information on how to gain access to the stuff in its corresponding C file.

Even if you shield your .h files from multiple inclusion, as your project gets larger and larger you will inevitably include the same data file in two separate modules, and everything will compile fine but the linker will choke on it because when it sees a reference to a variable that same variable will be defined twice, and it won't know which one you're talking about. (If you happen to be using a shoddy Mac compile of gcc you will get a mysterious and untraceable bus error that will haunt you for days. Or at least, uh... that's what some guy told me happened to him. Yeah.)

Dan.

#14389 - yaustar - Mon Jan 05, 2004 11:19 pm

Thanks that explains a few things...what would happen if you had the same #define in two seperate header files
Code:

//1.h
#define HELLO 1

//2.h
#define HELLO 1

//main.c
#include 1.h
#include 2.h

_________________
[Blog] [Portfolio]

#14392 - sajiimori - Mon Jan 05, 2004 11:38 pm

#define is a preprocessor directive. "#define x y" tells the preprocessor to replace all instances of x with y for the rest of the file. It's a lot like "search-and-replace" in a text editor, and it's totally different than creating variables.

Generally, preprocessors don't like it when you #define something twice during the course of compiling a C file, so if you #include two headers that #define the same thing, the preprocessor will probably complain.

But this is a very different problem than multiple data and function definitions.

Anyway, you could have just tried what you described to see what happens.

#14395 - CcSoccer881 - Mon Jan 05, 2004 11:50 pm

poslundc wrote:

Second of all - realize that declaring the array of data doesn't put it into VRAM. It's up to you to do that, and up to you to decide how you want to manage VRAM. If you want to, when you first load in the sprite you can copy all four arrays sequentially into VRAM. Then to display the first sprite, set the tile number of attribute 2 to zero. To display the second one, set it to 16 if you are 16-colour mode, or 32 if you are in 256-colour mode. etc.


I understand about the .c/.h file issue, I've been programming for about 2-3 years now, I'm just new to GBA programming, and in this case, it's a small demo where I'm only using 1 .c file, so I figured it was safe to use it in a header.

As for the array, I also realize that just declaring it doesn't put it into VRAM, I'd have to load it in first.
_________________
www.rsstudios.net

#14406 - yaustar - Tue Jan 06, 2004 1:32 am

It is just wierd since DKA has no problems with it (that I can see) but Visual HAM goes along the multiple definition error route.
_________________
[Blog] [Portfolio]

#14413 - CcSoccer881 - Tue Jan 06, 2004 3:37 am

I got teh animation working, so my next task is to do a sprite-handler class, so I can keep track of everything :) Thanks for your help, and sorry if I sounded like a prick in my last post, it's been a bad day.. brother locked himself out of the house so I had to come home from having a good time after a bad day at school heh.
_________________
www.rsstudios.net

#15240 - dagamer34 - Mon Jan 19, 2004 6:09 pm

Does Visual HAM use a later version of GCC anyway, version 3.3.2 i think compared to 3.0.2 in v4 of DKA.

Maybe you are just getting away with things you're not supposed to!
_________________
Little kids and Playstation 2's don't mix. :(