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 > Move Sprites

#9422 - iuiz - Mon Aug 04, 2003 2:33 pm

Hiho,

i found the following Code, for moving Sprites:

Code:
void moveSprite(OAMEntry* sp, int x, int y){
                                    //moving the sprite
   sp->attribute1 = sp->attribute1 & 0xFE00;   //clear the old x value
   sp->attribute1 = sp->attribute1 | x;      //new value

   sp->attribute0 = sp->attribute0 & 0xFF00;   //clear the old y value
   sp->attribute0 = sp->attribute0 | y;      //new value
}


I think it is realy Popular. But isn't it faster to move a Sprite this way:
Code:

void GetInput()
{
   if(!(*KEYS & KEY_UP))
   {
      pacman.y--;
      sprites[pacman.OAMSpriteNum].attribute0 = COLOR_256 | SQUARE | pacman.y;
   }
   if(!(*KEYS & KEY_LEFT))
   {
      pacman.x--;
      sprites[pacman.OAMSpriteNum].attribute1 = SIZE_16 | pacman.x;

[...and so on]


The first one is from GbaJunkie, the other uses code from the tutorial, too, so I hope that there is no problem in understanding the Code.



Cu,
iuiz

#9424 - niltsair - Mon Aug 04, 2003 4:02 pm

Yes, but it implies that you already know the sprites attributes and that it stays the same. If you had many sprites to move, with different properties you couldn't use the second method.

#9425 - iuiz - Mon Aug 04, 2003 4:09 pm

hmmm, and if a define some global vars to hold the Other Infos (I mean "COLOR_256 | SQUARE ")?

#9426 - niltsair - Mon Aug 04, 2003 4:20 pm

Then you save on 1 read will need to write those 4 lines of codes for every type of sprites instead of calling 1 function.

#9427 - Sweex - Mon Aug 04, 2003 4:27 pm

Besides the above mentioned reason, it is also a lot more maintainable. With the top function, you don't need to worry about the exact functioning of the GBA.
_________________
If everything fails, read the manual: If even that fails, post on forum!

#9430 - tepples - Mon Aug 04, 2003 4:58 pm

You can gain readability and speed by using a function and then making it inline.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#9431 - iuiz - Mon Aug 04, 2003 5:19 pm

Ok thank you ;) I think I will use the first Version in future.


Thx,
iuiz

#9432 - col - Mon Aug 04, 2003 6:11 pm

Just thought i'd add my tuppence worth :)


A good rule of thumb to help you work out the right way to go in these situations:

the name of the function should describe what the function does.

moveSprite(...) should move a sprite
getInput(...) should get input

reason: if someone(or you) is reading some code that uses the function, and that person reads: getInput(...); , they will assume that input has been got - not that a sprite has been moved :)

this general rule can be useful in other ways:
say you have a fuction that reads input and moves a sprite - what do you call it?
you could call it: getInputAndMoveSprite(...);. Hmm, that seems overly long, it also highlights the fact that the two routines are not closely related... these issues are a very good indication that the two routines belong in seperate functions :)

there is a school of thought that says a function should only ever do one thing.
Personally i think that that is a little inflexible, but it does enforce good coding style.

...

ok enough :)

cheers

Col

#9434 - iuiz - Mon Aug 04, 2003 6:31 pm

hmm, somehow you are right ;)

I came to my mehthode, as I had only done the first tutorials for displaying a Sprite. When I added my GetInput Function I had not read the other tut, but when I saw it I asked myself why it is done this way.


I optimized my code now ;). I hope that other Peole will be able to read it now *g*.


Cu,
iuiz