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 > sprite coordinate question & multiplication cost

#23924 - underthesun - Sat Jul 24, 2004 8:26 am

hi, just wondering:

how do most people handle this situation:

suppose you have a sprite. the OAM registers stores the topleft edge of the sprite as the coordinate (i.e on attribute0 and attribute1), and all is fine.

you have a sprite that needs to walk off-screen, i.e gradually get (move) out of the screen, from topleft. That means the x and y value has to decrease (moving topleft) slowly, and all is fine.

The problem is, when the x and y value reaches 0, and the sprite is at the topleft. but then the actual sprite hasn't moved outside the screen yet. however, the x and y value can't decrease anymore, since it's at it's lowest limit now.

How do most people handle this kind of problem?

oh and just wondering whether multiplication (*) operations are costly, like the mod (%) and division (/) operations.. since i heard about that.

cheers
_________________
I am just a gba noob. be gentle :p

#23925 - DiscoStew - Sat Jul 24, 2004 9:09 am

The whole moving off the screen in the top-left direction is simple. When wanting to go below 0 (for the screen), you need to either start subtracting (adding the negative number) from 512 (for X-axis), or 256 (for Y-axis). For instance, a sprite at point (-10, -20) would need to have its coordinates in OAM with values of (502, 235) to make it look like it is at (-10, -20). However, I guess there is some problem with sprites along the Y-axis if the sprite is 64 pixels long (vertical), and the DOUBLE flag is enabled. Placing one of these kind of sprites at 160 on the Y-axis would make the sprite show at max about 32 pixels on the top portion of the screen, and less as the sprite is displayed further up than 160. I imagine
filling out that particular sprite's data at V-Count 32 by way of a V-Count interrupt (and then empty that sprite section during the V-Blank) would fix this. It would come with the price of a manditory enabling of OAM_H_BLANK in REG_DISPCNT, which shortens the number of sprite rendering cycles per scanline. Anybody have other ideas about this?

From my knowledge, multiplication is not nearly as costly as div/mod, and yet it does take a number of cycles to complete. Couldn't tell you the count though. If you are worried about speed, take a look around on the boards. There are many threads relating to things like faster division and optimization.
_________________
DS - It's all about DiscoStew

#23927 - poslundc - Sat Jul 24, 2004 3:12 pm

If you are storing the sprite's coordinates as signed variables, eg. if you have x == -10 and y == -20, simply do a bitwise-AND with 511 for x and 255 for y to get the correct values to use in the OAM coordinates.

Multiplication by a constant will be optimized automatically by GCC. Multiplication by a variable depends on the complexity of the variable, and can take anywhere between 1 and 4 cycles longer than a regular arithmetic operation. (There is also long-long multiplication which only gets used with the long long datatype in C; this takes an additional cycle.) This is not a lot to worry about in most cases, and comes nowhere near the cost of division or modulus.

Dan.

#23937 - underthesun - Sun Jul 25, 2004 1:00 am

thanks for the info people, I really appreciate it :). thanks again
_________________
I am just a gba noob. be gentle :p