My Character sprite disappears when he's facing right.

R

Rabid Guineapig

Guest
So, I started remaking a game I've worked on since about the GM6 days, using GM Studio 2 now, took a while to get used to the new interface after so long using older versions and being too stubborn to try the new one. That's not important though...

What IS important is I have a very strange glitch regarding my main character's animations. Basically, when ever he faces right he flat out disappears! He's still physically there, he just goes invisible! All of the sprite names are correct. I use a variable "face", =1 for right, =0 for left. Pretty standard stuff I think. Again, the character is physically there, he interacts as normal, collision is correct, he just goes invisible! EVERYTHING that happens when he's facing left works just fine.

Here is the code for animation so far:

//Animation------------------------------------------------------
if(vmove=1)
{
if (face=1) {sprite_index=s_cherry_jumpR if(vsp>0){image_index=1} if(vsp<0){image_index=0}}
if (face=0) {sprite_index=s_cherry_jumpL if(vsp>0){image_index=1} if(vsp<0){image_index=0}}
}

if(vmove=0)
{
if(face=1)
{
if(hmove=0)
{sprite_index=s_cherry_standR image_speed=0.1}
{
if(hmove=1)
{sprite_index=s_cherry_runR image_speed=abs(hsp)/6}
if(hmove=-1)
{sprite_index=s_cherry_skidL image_speed=0.1 instance_create_depth(x,y,random(2),o_poof)}
}}

if(face=0)
{
if(hmove=0)
{sprite_index=s_cherry_standL image_speed=0.1}
{
if(hmove=-1)
{sprite_index=s_cherry_runL image_speed=abs(hsp)/6}
if(hmove=1)
{sprite_index=s_cherry_skidR image_speed=0.1 instance_create_depth(x,y,random(2),o_poof)}
}
}

}

vmove and hmove check whether he's moving vertically or horizontally respectively.
As you can see, if vmove=1 then he's in the air. animate accordingly. Image index checks either going up or down, 1 for falling, 0 for jumping. that's all well and good. But why is he invisible when he faces right?!

The funny thing is, it was working just fine before! Can someone please help!? It's driving me nuts!
 

Attachments

Slyddar

Member
If you do this at the end of your code, what is the value when it is not visible?
Code:
show_debug_message(image_xscale)
 
R

Rabid Guineapig

Guest
If you do this at the end of your code, what is the value when it is not visible?
Code:
show_debug_message(image_xscale)
I'm not sure exactly to apply this as I am still new to GMS 2 and the debug mode is weird and new to me. However, I really don't think it's an xscale issue, it shouldn't be anyway, The left and right facing sprites are independent from each other so that I have more control if the hit box so I have no need to mess around with xscale at the moment. however I will still try something and see if it helps anything.
Thank you for your help!

Edit: I put image_xscale=1 at the very beginning of the begin step event just to be absolutely sure it's always 1 and nothing has changed.
 

Slyddar

Member
Ah ok. Thought you might of been doing something else with image_xscale, as image_xscale being 0 is a common reason for the instance vanishing sometimes. Show_debug_message is very handy, and it's not running in debug mode. It's just a way to output variables to the output window to see what their value is. You can place the line anywhere you need to see a variables value.

Are the left and right facing sprites different animations/sprites, or are they just flipped versions of each other?
 
R

Rabid Guineapig

Guest
Ah ok. Thought you might of been doing something else with image_xscale, as image_xscale being 0 is a common reason for the instance vanishing sometimes.

Are the left and right facing sprites different animations/sprites, or are they just flipped versions of each other?
basically just flipped over.
Do you think if I just used xscale instead of separate sprites it would fix it?
 

chirpy

Member
As Slyddar said, a common mistake is to set image_xscale = sign(move_direction) when move_direction is sometimes 0.
Yours didn't sound like the case, but you also did not handle other vmove values, nor vsp == 0 nor floating point hmove cases; perhaps you should use proper "if else" to see if there's any unexpected cases you did not catch?
 
D

Deleted member 13992

Guest
you won't have to make sprites for left and sprites for right if you use xscale.

use the same sprite sets for both directions and set image_xscale=1 when moving one direction, and image_xscale=-1 for the other.
 
R

Rabid Guineapig

Guest
As Slyddar said, a common mistake is to set image_xscale = sign(move_direction) when move_direction is sometimes 0.
Yours didn't sound like the case, but you also did not handle other vmove values, nor vsp == 0 nor floating point hmove cases; perhaps you should use proper "if else" to see if there's any unexpected cases you did not catch?
This is how I handle hmove:

// Check whether moving horizontally or not------------------------------------
if(hsp>0.1){hmove=1}
if(hsp<-0.1){hmove=-1}
if(hsp<0.1 and hsp>-0.1){hmove=0 hsp=0}
that should cover all bases right? Also, hmove is separate from face so that I can have him do a cool skid effect when turning around
vmove is solely based on whether he's touching the ground or not.
 

chirpy

Member
This is how I handle hmove:

// Check whether moving horizontally or not------------------------------------
if(hsp>0.1){hmove=1}
if(hsp<-0.1){hmove=-1}
if(hsp<0.1 and hsp>-0.1){hmove=0 hsp=0}
that should cover all bases right? Also, hmove is separate from face so that I can have him do a cool skid effect when turning around
vmove is solely based on whether he's touching the ground or not.
Strictly speaking it did not cover all bases since nothing is done when hsp==0.1 or hsp==-0.1, but these cases probably just don't happen.
What I'd recommend doing is like:
Code:
if (hsp>0.1)
{
//...
}
else
if (hsp<-0.1)
{
//...
}
else
{
//...
}
 
R

Rabid Guineapig

Guest
Strictly speaking it did not cover all bases since nothing is done when hsp==0.1 or hsp==-0.1, but these cases probably just don't happen.
What I'd recommend doing is like:
Code:
if (hsp>0.1)
{
//...
}
else
if (hsp<-0.1)
{
//...
}
else
{
//...
}
Just thought, what about if(hsp<=0.1 and hsp>=-0.1){hmove=0 hsp=0}
would that work?
 

Slyddar

Member
If it's the same sprite, the easiest way I've found with just one sprite, is to use a facing direction which is either -1 (left) or 1 (right). You set facing with this :
Code:
if hsp != 0 facing = sign(hsp)
(or hmove, or whatever your horizontal movement is)

You can then draw the sprite in the draw event using the facing variable with :

Code:
sprite_draw_ext(sprite_index, image_index, x, y, facing, image_yscale, image_angle, c_white, image_angle);
Setting the image_xscale to facing directly can lead to sprites getting stuck in walls when flipping, if not done correctly, so it's better to just leave that at 1.
 
Last edited:

chirpy

Member
Just thought, what about if(hsp<=0.1 and hsp>=-0.1){hmove=0 hsp=0}
would that work?
Yes, that should work the same. A tiny difference being, without "else", the computer will check whether (hsp<=0.1 and hsp>=-0.1) even after it runs the code block for (hsp>0.1). (Note I'm just being paranoid here; we still don't see your real bug yet)
 
R

Rabid Guineapig

Guest
Yes, that should work the same. A tiny difference being, without "else", the computer will check whether (hsp<=0.1 and hsp>=-0.1) even after it runs the code block for (hsp>0.1). (Note I'm just being paranoid here; we still don't see your real bug yet)
yeah... well at this point I'm tempted to redo the player object from scratch to see if I can fix it that way. It'd be a real pain but the game's still very early so there's not too much I'd have to account for. I'll probably take slyddar's advice and have all the flipping be done from the draw event.
Unless someone's willing to look through the entire code of the character himself (which isn't that much yet honestly) and probably tell me I just misplaced a bracket somewhere or something painfully simple like that.
Thanks for your support and wish me luck!
 
R

Rabid Guineapig

Guest
Okay, guys, I have an extremely weird problem here. I created the new character object from scratch, no code added yet, only the initial create sprite. He's still invisible when I run the game! I'm starting to think something's funky with game maker itself! This is the single strangest thing I've ever experienced! The sprite is there in the sprites group clear as day!
 
R

Rabid Guineapig

Guest
Maybe submit a bug report and your project if that's the case.
I actually did earlier. I don't know how else to explain it other than it being a bug. thanks for your help though!
 
If it is indeed a bug with GM, it sounds like it might relate to some sort of issue 2.3 has with sprites. I rearranged the order of some menu box sprites a couple weeks ago and then none of them would draw anymore.. I cleaned the cache and then absolutely nothing except for a couple vertex buffers would draw. I think I ended up fixing it by cleaning the cache, restarting GameMaker, and then cleaning the cache again if running the game didn't work. I wouldn't say it's a guarantee as I probably got lucky, but give it a shot.
 
R

Rabid Guineapig

Guest
If it is indeed a bug with GM, it sounds like it might relate to some sort of issue 2.3 has with sprites. I rearranged the order of some menu box sprites a couple weeks ago and then none of them would draw anymore.. I cleaned the cache and then absolutely nothing except for a couple vertex buffers would draw. I think I ended up fixing it by cleaning the cache, restarting GameMaker, and then cleaning the cache again if running the game didn't work. I wouldn't say it's a guarantee as I probably got lucky, but give it a shot.
I will thank you!
 
R

Rabid Guineapig

Guest
Just an update: I did file a bug report and got a response the next day. They said they've received similar problems from other users and are actively working on patching it out in the near future.
I just want to say that the GM community is just as great as is was way back in the day when I was using GM8 and I appreciate everyone who were willing to help me as well as other people. Also the devs, even during covid are willing to reach out to users and work with them and are also very much appreciated!
 
Top