• 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!

SOLVED Sprite sheet animation issue

Hey all,

I'm making a game with a Diablo style movement system and I'm having issues with the Animation flickering. Im using a sprites sheet and have the Animation running smoothly and as expected most of the time but if the player holds the cursor around the edges of the angle ranges i set up, it rapidly flickers between the two Animations every frame.

I can't post the code atm because I'm at work but I was wondering if someone could point me in a good direction to look into for a solution?

I'm using a nested tree of if/else statements and it works just fine except on the litteral edge case lol.
 

joeygopher

Member
I've encountered similar issues with my enemy pathing - because the direction can rapidly change many times in quick succession, the sprite will keep changing in line with the code. It looked buggy, but was actually doing exactly what I'd told it to. I'm guessing your mouse hover is probably repeatedly crossing the "border" of your angle ranges.

I ended up building in an alarm and a 'canChange' variable so that a direction change could only flip the sprite once every 30 frames or so. More experienced people may have better solutions, but it worked well enough for my needs.
 
I ended up building in an alarm and a 'canChange' variable so that a direction change could only flip the sprite once every 30 frames or so. More experienced people may have better solutions, but it worked well enough for my needs.
Got it in one i think. I know that the code is working exactly as I wrote it to. I was thinking that an alarm event would be one possible solution, but I wanted to see if the hive mind had any other ideas seeing as I have about 11 hours before I can get at my code to do any work.

EDIT: your reply seems to have knocked something loose in my brain meats. Since I'm using if(>a && <b) execute animation, I can widen the ranges so that there's about three degrees of overlap so that if it's in both ranges it will default to the one it was in first?
 
Last edited:

Xer0botXer0

Senpai
It sounds like you're changing the character sprite set depending on the position of the mouse relative to the character ?

Perhaps just reduce the min/max angles per direction so they aren't up flush against one another allowing for more than a few pixels of movement with the mouse.
 
It sounds like you're changing the character sprite set depending on the position of the mouse relative to the character ?

Perhaps just reduce the min/max angles per direction so they aren't up flush against one another allowing for more than a few pixels of movement with the mouse.
There won't be any issues while it's in that null zone between the ranges?

EDIT: disregard that last question, I just remembered while I was testing this that it only changes when another if statement is fulfilled. This seems like the easiest implementation.
 

Xer0botXer0

Senpai
When the ranges overlap it's going to iterate between them as the code is run so adding a null zone should remove smooth out the transitions.
But I do imagine an issue when the mouse is too far from the character since the mouse would then have to travel a greater range ..

It seems either way, if there's no null zone between the angles then having the mouse close to the character would change it very quickly.. having it far away would work better.. but adding a null zone would mean more travel on the mouse when it's further away.

Perhaps you can include something in your code to check the distance from mouse to character which will increase/decrease the ranges the closer/further away the mouse is from the character.

Alternatively if that wasn't really the issue to begin with I imagine that if this code iterates every x steps instead of per mouse click event, and you're setting the image_index without checking if it's already assigned to the expected sprite set, then your sprites going to 'restart' every time it's run.. instead of running through the frames.
 
When the ranges overlap it's going to iterate between them as the code is run so adding a null zone should remove smooth out the transitions.
But I do imagine an issue when the mouse is too far from the character since the mouse would then have to travel a greater range ..

It seems either way, if there's no null zone between the angles then having the mouse close to the character would change it very quickly.. having it far away would work better.. but adding a null zone would mean more travel on the mouse when it's further away.

Perhaps you can include something in your code to check the distance from mouse to character which will increase/decrease the ranges the closer/further away the mouse is from the character.

Alternatively if that wasn't really the issue to begin with I imagine that if this code iterates every x steps instead of per mouse click event, and you're setting the image_index without checking if it's already assigned to the expected sprite set, then your sprites going to 'restart' every time it's run.. instead of running through the frames.
I'm controlling animation steps separately from the sprite selection so that last bit won't be an issue. Im already tracking mouse distance so it should be easy to add a variable that narrows or widens the ranges.
 
Top