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 coordinates and scaling issues

#10465 - poslundc - Fri Sep 05, 2003 9:08 pm

OK, so I have a situation where I want to create a sense of perspective by showing a sprite smaller if it's further away from the player and larger if it's closer.

The problem I'm having is that the sprite's coordinates in OAM represent the upper-left corner of the sprite, and as I scale the sprite downwards it shrinks towards the centre of the 32x32 area the sprite holds. This means that if I want to keep the character's "feet" planted on the same y-coordinate, I need to manually adjust the y-coordinate of the sprite.

Even worse is if I scale the sprite upwards, in which case I need to invoke SIZE_DOUBLE and adjust both the y-coordinate and x-coordinate by (dimension / 2) just to keep the new sprite centred over the old sprite.

I can do all of this if need be... I'm just wondering if there's a better way. For that matter, is there any penalty if I decide to just leave SIZE_DOUBLE on for the sprites that need scaling (it'll be about 20 sprites altogether)?

Thanks,

Dan.

#10467 - sajiimori - Fri Sep 05, 2003 10:54 pm

It sounds like you have the right idea. However, it would be difficult to adjust the screen coordinates of a sprite every time it moved in the world. So, instead of storing the screen coordinates of a sprite, store its position in the world, then generate its scale and screen coordinates on a frame-by-frame basis.

I don't know of any penalty of having SIZE_DOUBLE on all the time.

#10472 - tepples - Sat Sep 06, 2003 1:29 am

sajiimori wrote:
I don't know of any penalty of having SIZE_DOUBLE on all the time.

There are only about 950 sprite pixels available on each scanline. A scaled sprite uses three times as many sprite pixels as an unscaled sprite; a doubled scaled sprite uses double that, for a total of six times. If the display controller runs out of sprite pixels, it will drop some sprites on that line. (This is the cause of the flicker on NES games; the NES supported only 64 sprite pixels per scanline.)

Details in gbatek.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#10476 - sgeos - Sat Sep 06, 2003 2:07 am

tepples wrote:
sajiimori wrote:
I don't know of any penalty of having SIZE_DOUBLE on all the time.

There are only about 950 sprite pixels available on each scanline. A scaled sprite uses three times as many sprite pixels as an unscaled sprite; a doubled scaled sprite uses double that, for a total of six times.


Would having your scaled sprites SIZE_DOUBLEed all the time result in more battery usage? If so, is the increase significant?

-Brendan Sechter

#10500 - sajiimori - Sat Sep 06, 2003 5:23 pm

Thanks for the info, tepples.

With that limitation in mind, you'll probably want to make sure sprites are never dropped. The easiest way to do that is to figure out a worst-case scenario, with the most sprites you'll ever want on screen, and all of them as close as they can get.

If sprites are dropped at that point, you can either:

- reduce your maximum number of sprites,
- automatically drop sprites that are closer than a certain distance,
- or (more difficult and not as logical) make sure that only some of them can get close to the camera.