• Hey! Guest! The 40th (!!!) GMC Jam will take place between February 25th, 12:00 UTC to March 1st 12:00 UTC. Why not join in this very special anniversary jam! Click here to find out more!

Scaling on different origin point

Misbug

Member
Hello everyone,
A little prologue: I'm not a coder so please be gentle with my lack of knowledge and poor wording on technical matters.

I have a grid and turn based game that I'm using as a base idea to learn GML and different features of GMS2. In this game all the sprites have their origin point anchored on the top left corner; movement and collisions are basically using that origin point and the grid to make the game happen.
During my studying sessions I decided to explore the possibility of adding code based animations on the player object when it moves by trying to add a squash and stretch animation (picture it as a blob sliding from a tile to another). My problem here is that I can't just image_xscale /yscale at the origin point as the image will stretch toward at an anchor point that doesn't make the movement look natural and changing the origin point will break both collision and grid structure.

Is there any other way to basically scale the sprite attached to that object via code using an origin point different from the one set in the sprite editor? Is just sprite frame by frame animation the only option?

I searched for a solution here on the forum, but I wasn't able to find one; I apologise for the redundant post if this has already been answered somewhere.
 

TheouAegis

Member
Since you won't want the coordinates to actually change, you can create your own scaling variable(s). You could still use image_xscale and image_yscale if you want if you don't base collisions off the sprite. Either way, use draw_sprite_ext() to draw the sprites scaled. Personally, I would try to stick with image_xscale, because GM will calculate some things for you automatically. The sprite_* variables (except sprite_index) are based on image_xscale and image_yscale. So sprite_xoffset will be different from sprite_get_xoffset(sprite_index). Can you see where I am going with this? The difference between those two values will be what you need to add to the x coordinate for draw_sprite_ext(). Or you might want to use sprite_width vs. sprite_get_width(sprite_index). Likewise with y.
 

Fielmann

Member
Instead of drawing the sprite at x, y, draw it at x + (1 - image_xscale) * grid_size / 2, y + (1 - image_yscale) * grid_size / 2

where grid_size is a variable (or a macro ;) ) that holds the side length of your grid cell.
 

Misbug

Member
Thank you both for the help!

Especially for this because it opened my mind on the possibility to use variables instead of image_xscale / yscale to make the value of scaling change over time.
Instead of drawing the sprite at x, y, draw it at x + (1 - image_xscale) * grid_size / 2, y + (1 - image_yscale) * grid_size / 2

where grid_size is a variable (or a macro ;) ) that holds the side length of your grid cell.
The draw_sprite option seems to do the trick without breaking the rest. I'll keep studying this and after that I'll also try a collision structure not based on the sprites so that I can explore the direct usage of image_xscale / yscale.
Thanks again!
 
Top