#96150 - jfolk - Tue Aug 01, 2006 6:37 pm
Hello all.
My question lies in the math.
I have several sprites making up one big sprite(no changing this fact).I would like to scale this one big sprite (to pulsate). The problem is the sprites overlap eachother, and cause warping. I believe it is fixed point rounding errors, which cannot be prevented. Any ideas on how to do this? If so, please describe it mathematically.
#96207 - jfolk - Tue Aug 01, 2006 9:11 pm
I am wondering if this question is too broad, or the readers may think that I want them to do it for me... I'm just puzzled where to start, any response will be appreciated
#96218 - crossraleigh - Tue Aug 01, 2006 10:06 pm
Translate the sprites as you scale them.
#96226 - jfolk - Tue Aug 01, 2006 10:45 pm
yes, but by how much?
you can scale a sprite from (1<<6) to (1<<10), inclusively, but you at what points do you have to translate it? I made a small demo game which you increment the scaling factor by one every time you press a key, to watch when it physically changes size. It seems that, every 16 increments it changes size, although it didnt' map out to a function where it was ALWAYS 16.
I have a scale, scale_velocity(which increments the scale every frame), a max_scale, and min_scale variables.
ex:
u16 scale = 1<<8;
u16 scale_velocity = 1;
u16 max_scale = 1<<10;
u16 min_scale = 1<<6;
void update(){
if(scale<=min_scale || scale>=max_scale){
scale_velocity=-(scale_velocity);
}
scale+=scale_velocity;
/*Apply the scaling*/
/*Translate the sprites when necessary*/
}
So um... when is it necessary.
Any help would be appreciated.
P.S.
The sprites positions are in 24.8 fixed point
#96372 - crossraleigh - Wed Aug 02, 2006 10:40 pm
If I were you I'd write some fixed-point ops so I could step away bit farther away from the registers. After that just remember that the scaling value is a factor. s = 2.0 means the sprite's size should be doubled. You get a new width and height by w' = sw and h' = sh.
Since the transformation doesn't move the center of the sprite, one half of the difference in width goes to the left, the other half goes to the right; one half the difference in height goes to the top, the other half goes to the bottom. So for example if you wanted to keep the top-left corner of a sprite stationary, translate (w' - w) / 2 units right and (h' - h) / 2 units down.
#96579 - thegamefreak0134 - Thu Aug 03, 2006 11:41 pm
Calculate the scale yourself. Calculate exactly where the bottom right pixel will be (use fixed point math so any errors in the GBA hardware are reflected properly.) when scaled, and then draw the next sprite down-right one pixel from that. (or right or down, depending on positio and stuff.)
Why do you need a huge sprite anyway? Is 64x64 just too small? It seems like for something like this you might want to consider mapping the image to a background. Course, that depends entrely on what it's being used for and the circumstances and stuff.
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#96635 - Cearn - Fri Aug 04, 2006 9:40 am
The general equations for correct affine object placement can be found here, with examples. Also, I strongly recommend you NOT to use u16 for variables here, not only because they are slower, but in affine calculations overflow can happen very quickly and when there are any negative numbers anywhere the whole thing will blow up. Use ints.