Yeah, I know. I was just complementing your skills.
How do you do Gravity in C?

First you should really understand how gravity works in physics; I assume you haven't taken a physics class yet or learned kinematics. Once you know bits of math or physics, and you know a language well, a mark of a good programmer is being able to translate that math or physics into code. So, assuming that you know physics and you know C, you would use the following equations for an object moving in 2D space, with gravity:

- Variables needed: x_pos, y_pos, x_vel, y_vel
- Constants assumed: x_accel = 0, y_accel = -9.8 [m/s^2]

On every physics tick:

- y_accel, x_vel remain unchanged
- y_vel += y_accel
- x_pos += x_vel
- y_pos += y_vel

Code:


That's my code. How do I make it stop at a certain limit? Like have a platform to stand on. Oh, and jump.

Hmm, your variable names are extraordinarily non-descriptive, which is not great and made me confused. y should be vel_y, and x should be vel_x. Or vy and vx. Or velocity_y and velocity_x. Longer variable names in C don't make your program larger, so there's no point in trying to be overly concise. When the y-position reaches some value, you'll probably want to set the y velocity to zero, and not let it apply the gravity until it's not on the "platform" anymore, right? You're asking me questions more about thinking and logic than programming, to be honest.

Most of the time you'll be having a map in some sort of 2D array form, and each array entry will correspond with an actual tile on the screen. What you'll essentially do is convert from the x/y coordinates of the player to the x/y position in the array, through subtraction of the screen viewing offset and a division of the pixel size, and test to see if you can walk on the block below you in the array or not.

Well, I'll change the var. names. So I just put something like,
Code:
?

And Ashbad is saying like if I want different height platforms?

Indeed. And you'll also want to make it not apply gravity if the cursor is "standing" on the bottom of the screen:

Code:

But how would I make it jump?

With a negative value in velocity_y.

Now it won't jump when it's moving left or right.


Code:

Why does your Coord struct not include values for vel_y and vel_x? Also, there's no point to having a vel_x variable if you never use it in the code. The point of the vel_x variable is to be able to replace:


Code:

with

Code:


If you don't want to do that, just get rid of the vel_x variable.

Besides these suggestions, I don't know what's causing your character not to jump while you're holding Left or Right. I'm guessing it has something to do with the way you're mixing up the two ways of getting key input. Like, you're using this method:

Code:

early in the code, and

Code:

later on...try changing all of them to the same method (probably the latter, but that's just a guess) and see if that works.

His input method is a bit unorthodox, and he should just use keydown(), but what he currently has should work just fine, concerning input methods.

And to then do cur.x += vel_x on each physics tick, of course.

Well, if I do that, it will just keep the cursor moving forever. It won't stop. How do I do what Ashbad was saying?

As soon as it hits your boundaries set your velocity variables back to zero, so they stop.

Code:

Another thing you can do, if you don't want your character to move forever, is to apply friction when your character is touching the ground.


Code:


See how when the character is touching the ground, 1/6 of the current x velocity is lost?

Okay, so I tried to display a Nyan Cat animation on my Prizm, but it didn't work. It reboots the calculator. Can you fix?


Code:

The reason is simple, you copied a code without understanding it.
What do you think this line means ?
Code:

I'm not sure. When you add to the frames variable, it changes the frames to the one after. The 12 tells how many frames are used. I'm not sure what the "24*24" or the "color_t*" does.

This sounds like you may be undertaking more than you can handle? idk. Maybe you should start really small, with less of an established goal in mind - however, that's a touchy thing to say because you need to have an idea of what the end product will look like. This is a little bit rude, but the only real way to learn how to program is to figure things out, by yourself - going through your code on a case-by-case basis, understanding every denotation of every line.