invert sprite without affecting the mask?

Megax60

Member
when i do image_xscale *= -1 sprite changes, but mask too, i dont want the mask to change, it gives me problems, how to fix
 

Slyddar

Member
Draw the sprite with the flip, instead of flipping it directly.
Use a variable like facing, and set that to the direction, either 1 or -1. To show that on the sprite, just draw the sprite using draw_sprite_ext() and set the image_xscale to facing.
 

Megax60

Member
Draw the sprite with the flip, instead of flipping it directly.
Use a variable like facing, and set that to the direction, either 1 or -1. To show that on the sprite, just draw the sprite using draw_sprite_ext() and set the image_xscale to facing.
and what about the animation
 

Megax60

Member
You can just use the built-in image_index for the animation. I believe the game will use the current frame as the mask.
im using iindex to replace image_index, because if i use that last one i would need to use sprite_index too, but that would make the game slower, but hey, the less code the better
 

dannyjenn

Member
I think image_index will work, even if you're not using sprite_index. (I could be wrong though... I haven't really needed to use collision masks before...)

But anyway, I don't think that sprite_index is any slower than any other sort of variable. (It may even be faster...)
 
Why do you think image_index and sprite_index are linked? Also, if you use draw_sprite_ext you WOULD use sprite_index to draw it...And why would that be any slower than drawing a sprite any other way? I'm not sure you understand how the draw_sprite function works. Any of the arguments in the draw_sprite function are literally just arguments. Drawing a sprite using sprite_index doesn't mean your mask would change, it simply means you are drawing a sprite of whatever sprite name is currently attached to the object. Using image_index in the arguments simply means it will attempt to draw whatever frame of the sprite in the sprite argument slot you've provided that the native sprite is currently on. It doesn't affect the native sprite or the mask at all. They are all just variables that can be referenced or not, but referencing them does not effect anything else.

For instance, let's say you have a sprite attached to an object called obj_not_bug and then do this in the Draw Event:
Code:
draw_sprite_ext(spr_bug,image_index,x,y,image_xscale,image_yscale,image_angle,image_blend,image_alpha)
That will attempt to draw the sprite named spr_bug with all of the statistics of spr_not_bug, but it will not effect spr_not_bug at all. If you set image_xscale to something else (let's say image_xscale = 2) it will effect BOTH the native sprite being drawn (spr_not_bug as well as the collision mask) AND the drawing of the sprite you are doing in draw_sprite_ext (the image being drawn of spr_bug). If you change any of these arguments to non-native arguments (for instance, change image_xscale to a variable you have created called xscale), it will not effect the statistics of the native sprite (spr_not_bug) and also will not effect the collision mask.
 
Last edited:

NightFrost

Member
It is important to understand that instance mask and sprite are not permanently linked to each other. In default state, when you just attach a sprite to an object and don't touch the draw event (or just do draw_self which is the same thing) they reflect each other. But any change you implement afterwards can detach them. When instance is created, it gains its mask properties from the attached sprite; these become instance properties. If you make a draw event that draws nothing, the mask still exists and responds to collision events, because instance still carries those properties. You can change the mask separately too (the command escapes me right now). Whatever you draw in draw event will not reflect back on the instance and won't change its properties. Same goes for image_index and other variables, they are instance properties. Drawn sprite (or sprites, since you can draw as many as you want to) are just visuals, they may or may not reflect instance properties (but most of the time you want them to, especially if collisions are involved) depending how you wrote the draw command.
 
Top