• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

Issues occurring when using walk animation

ashurlee

Member
I have just created a walk animation for my character, which I initially implemented using this piece of code...
GML:
if (hspd != 0) || (vspd != 0)
&& (sprite_index != spr_hairdresser_walk)
    {
    sprite_index = spr_hairdresser_walk;
    }
else   
if (hspd = 0) && (vspd = 0)
&& (sprite_index != spr_hairdresser)
    {
    sprite_index = spr_hairdresser;
    }
The sprite changes from walk to idle perfectly, however, issues have started appearing in some strange ways.

One of my abilities seems to be forced out of it's animation, or jumps between walk and the ability. It's hard to tell, things happen unusually fast.
And then another of my abilities, the particle object stops following the player half way through its animation. Which is even stranger as the particle is a separate object, with it's own code.

I have tried multiple ways of implementing the walk animation.
- having a separate state that activates on movement,.
- having a variable that is true or false based on movement, and having the sprite switch on based on that variable.
- Having no idle animation and only using the walk sprite.
-And various alteration on the code above.

Due to the issues happening even when i only use the walk sprite, i'm starting to think it's an issue with the sprite itself.
The walk sprite loops over 16 frames. But then all my other sprites also loopbut over varying number of frames, with no issue.

It's an odd one, hence my first time posting. Any advice would be great.
I wanted to upload clips but i'm not sure how best to go about that.

Thanks,
 

Slyddar

Member
Do you know how to use the debugger and breakpoints, as that is your tool for working out why things don't do what you think they should.
 

ashurlee

Member
Do you know how to use the debugger and breakpoints, as that is your tool for working out why things don't do what you think they should.
i've used it before a few times, i find it very tricky to get the hang of, but have found it useful a few times. I haven't attempted to solve this issue using it but i'll open it up and do that now. Not sure where to start as I am truly stumped as to what's causing this issue, but hopefully I can figure something out.
 

ashurlee

Member
i don't think i know enough about the debugger to solve this issue. Ive put breakpoints on the movement sprite, however i need to continuously move for this issue to happen, which i cant do if the debugger activates the break point every time i move.
I'll just keep tinkering with the code and hope i figure out what's going on.
I use gamemaker 1.4 by the way.
 

ashurlee

Member
SOLVED!

Looks like it was a sprite issue. More specifically, an image_index issue.
Having multiple frames for my walk animation, instead of the usual 1 frame...ie, 0 frame. It was messing with the animations of the other states, and so messing with particles related to image_index.
So, at the beginning of all my state switches, i set the image_index back to 0.
 

Vusur

Member
The first thing I see, your first condition is scary.

When you use only || or only && everything is fine. As soon as you mix || and && in one conditon, you should use brackets. && and || behave like "*" and "+". && comes before || (unless it was different in GMS1.4).

What you meant to say: "If I move and the sprite is not walking, change to walking sprite". Move is defined with "I'm moving horizontal or vertical".
Now we put it together like you did.
"If I'm moving horizontal OR vertical and sprite is not walking, change..." vs. what you meant "If I'm moving horizontal or vertical AND sprite is not walking, change...". Sounds the same, but is different when && is stronger.

In code, this happens:

Code:
A. No brackets. && before ||
1. true || true && true: 1
2. true || true && false: 1
3. true || false && true: 1
4. true || false && false: 1
5. false || true && true: 1
6. false || true && false: 0
7. false || false && true: 0
8. false || false && false: 0
---------------------------------------------
B. Brackets. || before &&
1. (true || true) && true: 1
2. (true || true) && false: 0
3. (true || false) && true: 1
4. (true || false) && false: 0
5. (false || true) && true: 1
6. (false || true) && false: 0
7. (false || false) && true: 0
8. (false || false) && false: 0
See the difference? This is important, because all 0s are checked next in the if else condition.
Unfortunaly this might not be the fix for your problem. hspd and vspd are used as contrary statements in your (part)logic. If the hspd part was true in the first condition, it has to be false in the second condition. Same with vspd. Sprite_index might not be a contrary statement. If you are setting the sprite_index somewhere else to something complete different, it can be false in both statements. So the only intresting ones are 7. and 8., because this would make both parts true in the ifelse. They are the same in both versions. So it's not the problem.

The second problem is your image_index. You are swapping sprites, but the image_index carries over. If you were in the 5 frame, swap, then you start at the 5 frame if possible. If your last frame is higher then the frame count of your new animation, you start at 0 (I think).
So set the image_index to 0 each time you swap and it actually starts the animation from the beginning.

Why the particle objects stops following? That's something I dunno. Does it depend on the image_index when swapping?

Edit: Welp, you found it out yourself. I'm to slow. So it was the image_index^^
 
Last edited:

ashurlee

Member
The first thing I see, your first condition is scary.

When you use only || or only && everything is fine. As soon as you mix || and && in one conditon, you should use brackets. && and || behave like "*" and "+". && comes before || (unless it was different in GMS1.4).

What you meant to say: "If I move and the sprite is not walking, change to walking sprite". Move is defined with "I'm moving horizontal or vertical".
Now we put it together like you did.
"If I'm moving horizontal OR vertical and sprite is not walking, change..." vs. what you meant "If I'm moving horizontal or vertical AND sprite is not walking, change...". Sounds the same, but is different when && is stronger.

In code, this happens:

Code:
A. No brackets. && before ||
1. true || true && true: 1
2. true || true && false: 1
3. true || false && true: 1
4. true || false && false: 1
5. false || true && true: 1
6. false || true && false: 0
7. false || false && true: 0
8. false || false && false: 0
---------------------------------------------
B. Brackets. || before &&
1. (true || true) && true: 1
2. (true || true) && false: 0
3. (true || false) && true: 1
4. (true || false) && false: 0
5. (false || true) && true: 1
6. (false || true) && false: 0
7. (false || false) && true: 0
8. (false || false) && false: 0
See the difference? This is important, because all 0s are checked next in the if else condition.
Unfortunaly this might not be the fix for your problem. hspd and vspd are used as contrary statements in your (part)logic. If the hspd part was true in the first condition, it has to be false in the second condition. Same with vspd. Sprite_index might not be a contrary statement. If you are setting the sprite_index somewhere else to something complete different, it can be false in both statements. So the only intresting ones are 7. and 8., because this would make both parts true in the ifelse. They are the same in both versions. So it's not the problem.

The second problem is your image_index. You are swapping sprites, but the image_index carries over. If you were in the 5 frame, swap, then you start at the 5 frame if possible. If your last frame is higher then the frame count of your new animation, you start at 0 (I think).
So set the image_index to 0 each time you swap and it actually starts the animation from the beginning.

Why the particle objects stops following? That's something I dunno. Does it depend on the image_index when swapping?

Edit: Welp, you found it out yourself. I'm to slow. So it was the image_index^^
Thanks for this response. I'm going to give it a proper read when I have more energy and can take it in, as this is something I have been thinking about for some time now. And trying to get this to work I did wonder if it was my understanding of || and && that was causing the issue. This is the first time I have combined || and && in one statement. Although now i have got it to work, i'm not sure I even need to check if the sprite is != to sprite, with an &&. I think it should just work just checking hspd || vspd.

I think the particle effects stopped following as part of animation cycle was based on the player sprites image index, and so not resetting it was messing that up.

Thanks again!!
 
Top