game-editor.com

Hey fellas!

So I am now working using the approach suggested by Game A Gogo here:
viewtopic.php?f=6&t=9992

However, I have now faced a problem. This concerns the speed of jump. The higher it gets, the more chance that at certain distances your character will get stuck in the platform above.
I have attached a pic and a ged file for you to look at. Jump with the 'z' button.
Those platforms, which have a C-like block above them, are platforms in which you will get stuck. As I change the distance slightly, the CollisionFree engine implemented in this exact game does not allow any more sticking in.

So the question is this: how does yvelocity work? In this code yvelocity is +=.16 So it is increasing by that amount. Obviously, there comes a point in which at a certain distance it becomes more than what is specified in the code, in this case y + yvelocity - 8 and so the game does not stop the actor in time before it is stuck in the platform above.

The reason I want to understand how yvelocity works is that it would then be probably possible to come up with a generic formula which will allow to eliminate any sticking into the platforms or other objects on top. So far this is the only immediate downside of this CollisionFree approach.

Do you mean that you wish to eliminate the "collision event" ?

savvy

No. Are you familiar with what CollisionFree function does and the approach, implemented by Game A Gogo? I put the link in the post.

yvelocity in most cases acts like any other variable. When you increase an int i, it increases. Next frame you increase it again, and it will even larger. I'm not sure what the complication is. yvelocity is a variable, that at the end of draw (when the frame's update happens) moves the actor along the y axis based on what it equals).

Code: Select all

yvelocity=0; // at this point yvelocity is equal to 0

yvelocity++; // yvelocity now equals 1
yvelocity+=2; // yvelocity now equals 3

There is however some complications when you are trying to use y+= and yvelocity at the same time, as in the case of y+=, it sets yvelocity equal to the actor's y displacement.

So yvelocity is really just a displacement along the y axis? If so, why have yvelocity instead of just a variable y which can be incremented?

Do you know the difference between displacement and velocity? That's the reason. yvelocity isn't set to 0 every frame. So, if you set yvelocity to 2 in an actor's create actor, every frame that actor will move 2 pixels down. This allows you to easily deal with acceleration (gravity for the most part).

But, yvelocity can also be updated in a different way (if you aren't actually setting yvelocity).
actor -> Draw Actor -> Script Editor

Code: Select all

y+=5;

That uses displacement, but if you use a text actor to display actor's yvelocity, it will say 5. This is useful at times, and it makes sense, but since there are two ways of setting the variable, it can get a bit confusing.

skydereign wrote:There is however some complications when you are trying to use y+= and yvelocity at the same time, as in the case of y+=, it sets yvelocity equal to the actor's y displacement.

Thanks for the explanation, I understand. IN fact, this is how I understood it before, just wanted to make sure. yvelocity is constant displacement which, until set to 0, will be active.

In my code I do not use both yvelocity+= and y+=. The code in the original post simply checks the top - current position y, plus the current yvelocity, minus a number which basically gives you a safety margin.
Seems like in my example certain distances at certain jump speeds make the formula "skip" the safety margin and the actor ends getting stuck. I am trying to figure out how to fix that effect once and for all...

Your problem is that you are setting yvelocity equal to 0 before you check for the ceiling. Just move it after the if.

Hey, man, thanks so much for the help! It works - no more sticking into the ceiling at any speeds!

I want to summarise the problem, just to make sure I understood the reason: was it in the fact that the gravity was turned off earlier than jumping stopped?

You were using yvelocity in your CollisionFree code, but before that you set it to 0. So any further references to yvelocity were set to 0. In your case you were using yvelocity to check above the player (checking for a ceiling) but since it was set to 0, you were actually only checking 8 pixels above the player (instead of 8+yvelocity). So, yeah, you could say the gravity was turned off before you check the jump.

Okay, got it

In fact, now this thing fixed, there is no need to have such a large number (8) as an offset. 4 or even 2 is enough.

Fixed in the original topic by Game A Gogo.