jump problems

[elsalvador]

I am trying to make a block jump as natural as possible and also my direction to be accurate
I do understand a little bit about gravity read about it and kind of got it but i am having a problem with the jump while walking its like its flying ,instead of a natural jump while walk..
I want a natural jump but I cant get it to work ? also my direction is not accurate can someone help me solve this problem ...
here its the .love

[Ranguna259]

Coding physics are we ?
This is actualy one of the hardest things to in 2D games, so I'm going to save you loads of trouble and I'll reedirect you to these physics libraries: bump, HardonCollider and the good old [wiki]love.physics[/wiki] module.

[micha]

Ranguna, I disagree with you in that implementing physics is difficult. It is a good idea to use others' libraries for collision detection, but implementing physics is straight forward.

Elsalvador, to clean up your code and make it work, I suggest two changes:

• Create a variable that tells you, if you can jump or not. Currently, you have the l.direction, which you could use for that, but you could also create a new variable. You could for example call it "canJump".
• Move the jump event from the update to the keypressed event. The jump happens at one point in time, not over many frames.

A while ago I wrote a little bit about jumping implementations. This could also help you. In the implementation there, I didn't have a "canJump" variable, but a "mode" variable instead. This is equally fine, as long as you cover all possible combinations (your l.direction variable fails, because you did not cover all possibilities).

[Ranguna259]

It's straightforward until a certen point, sooner or later your are going to find a bug (usually when a body is colliding near the vertex of rectangles, or when a body is moving really fast, that same body gets teleported to the wrong side of the colliding rectangle), and when you find that bug you will not be able to fix it unless you've studies physics ( to the point of knowing all the rules of quantum physics, jk )

Yeah, simple physics are easy but when you start coding you'll always try to go further than that, so you'll always find that god awful bug that you can't get rid of, even the libraries that I posted have that bug and the only tool that I've found that doesn't have this bug is the physics module (Box2D).

If you just want to code physics to learn how it's done then by all means do but be prepared for the worst. In my experience, coding physics from scratch is a wast of time unless you know what your messing around with, since I didn't, in the end my code looked like a bug's nest

[kikito]

I would like to point out that neither HardonCollider nor bump implement physics. They just do collision (AFAIK). Also:

even the libraries that I posted have that bug and the only tool that I've found that doesn't have this bug is the physics module (Box2D).

Care to ellaborate? Did you find that bug on bump?

[Ranguna259]

I remember testing a demo of bump and I encounter the bug, the player'd teleport to the wrong side of the rectangle when colliding near a vertex, but your current demo seems to be free of this bug, how are you resolving collisions ?

[kikito]

how are you resolving collisions ?

TL;DR: Very carefully

On each collision, there are two objects involved: I call them self and other. self can be moving or static, while other is always static (that is why I say that bump is gameistic instead of realistic - only 1 object can move at a time; but that's ok for most videogames anyway).

When self is static, I just resolve "by the shortest distance"; self determines if the shortest way to stop colliding is up,left,up or down, and moves there. Not very interesting.

When self is moving, however, things get interesting. The first thing I do is calculating the Minkowsky Difference between self and other. The MD is a space transformation. It looks like another rectangle, but it has several interesting properties. For example, if the MD contains the point {0,0}, then the two rectangles are interstecting; otherwise, they don't.

The MD makes other "bigger" and self "smaller" (it collapses into a point). So instead of intersecting one static rect with a moving one (which is hard), I intersect one rect with a line (which is easier). The algorithm I use for this is called Liang-Barsky. Once I have the intersections, I can "undo the transformation" and get where the boxes intersect. Then I can resolve by "sliding one on top of the other", by "bouncing" or just by "making them stick" (bump has 3 resolving options because of this).

I must mention that the problems at the borders that you mention haunted me for months. Getting the equals and less-than-or-equals of the Liang-Barsky algorithm was quite complex.

All this is however just half of the problem. The other half is sorting the collisions in the right order, so a character walking over a tiled floor does not get "stuck" on the corners of the tiles. The demo has a "tiled floor" at the bottom just so that I can test this easily.

I am not going to lie to you: The "stuck" problem still happens on bump; it's just very rare. I experience it maybe once per forthnight. This is because bump sorts collisions according to make sure that "you get the right tile to collision with first" (this is based on the direction you are moving, as well as the surface of the overlapping areas). Other libraries, box2d included, don't sort collisions this way (it's much more difficult to do that when you are moving all objects simultaneously instead of 1 after the other) and that's why they get "stuck" more often.

[elsalvador]

wow .. after this not sure what to do?
I don't want any bug in my code not sure what to change in my code now after reading your messages
as a beginner do I need to just borrow libraries from pro programmers and add them to the future games i want to make?
and while doing that learn from it? is that how pro programmers learned?

P.S i do need more information related to love 2d like michas site its pretty awesome the wiki don't have details for beginners
any other site similar to michas please let me know

[kikito]

I don't want any bug in my code not sure what to change in my code now after reading your messages

The only way to not have bugs in your code is not writing code. You are human. You will have bugs in your code. That's how it is.

But you can aspire to have gradually less bugs in your code. It requires a lot of learning.

and while doing that learn from it? is that how pro programmers learned?

Indeed. Not just using libraries; looking at their source code, too. That's one of the nice things about open source. I have written about this before, here (near the end):

http://kiki.to/blog/2012/04/03/cool-stu ... k-shaving/

Keep in mind that that's just one way to learn. You can always read, ask questions, etc. Also, the simple act of programming makes you learn stuff (or should).

Regards!

[Ranguna259]

wow .. after this not sure what to do?
I don't want any bug in my code not sure what to change in my code now after reading your messages
as a beginner do I need to just borrow libraries from pro programmers and add them to the future games i want to make?
and while doing that learn from it? is that how pro programmers learned?

P.S i do need more information related to love 2d like michas site its pretty awesome the wiki don't have details for beginners
any other site similar to michas please let me know

What kikito said.

TL;DR: Very carefully

TL;DR: Indeed

When self is static, I just resolve "by the shortest distance"; self determines if the shortest way to stop colliding is up,left,up or down, and moves there. Not very interesting.

This, this is what causes most of the bugs, in my collision code I used this for everything. Bad times..
But since your just using this for static objects I think it's fine, but how can two static objects collide, Probably only if the coder coded two static objects on top of each other by mistake, right ?

When self is moving, however, things get interesting. The first thing I do is calculating the Minkowsky Difference between self and other. The MD is a space transformation. It looks like another rectangle, but it has several interesting properties. For example, if the MD contains the point {0,0}, then the two rectangles are interstecting; otherwise, they don't.

Minkowski difference, I remember playing with it a few months back and it had a little glitch, a rare one and it usualy wouldn't appear when testing with moving objects.
I managed to replicate it in Oren's JS demo:

min.PNG (5.63 KiB) Viewed 2418 times

The MD makes other "bigger" and self "smaller" (it collapses into a point). So instead of intersecting one static rect with a moving one (which is hard), I intersect one rect with a line (which is easier). The algorithm I use for this is called Liang-Barsky. Once I have the intersections, I can "undo the transformation" and get where the boxes intersect. Then I can resolve by "sliding one on top of the other", by "bouncing" or just by "making them stick" (bump has 3 resolving options because of this).

Interesting approach, I actualy use this algorithm in my geometry lib to check intersection points between a line and rectangles. I never thought about using it to resolve collisions.

I must mention that the problems at the borders that you mention haunted me for months. Getting the equals and less-than-or-equals of the Liang-Barsky algorithm was quite complex.

I guess this bug happens no matter what algorithm you use, maybe physics is hunted by a ghost that doesn't let people code it without this damn bug appearing

All this is however just half of the problem. The other half is sorting the collisions in the right order, so a character walking over a tiled floor does not get "stuck" on the corners of the tiles. The demo has a "tiled floor" at the bottom just so that I can test this easily.

I am not going to lie to you: The "stuck" problem still happens on bump; it's just very rare. I experience it maybe once per forthnight. This is because bump sorts collisions according to make sure that "you get the right tile to collision with first" (this is based on the direction you are moving, as well as the surface of the overlapping areas). Other libraries, box2d included, don't sort collisions this way (it's much more difficult to do that when you are moving all objects simultaneously instead of 1 after the other) and that's why they get "stuck" more often.

I had this bug to, the player would just get stuck on the front tile, it was like it was colliding into a little pixel on the floor, this was one of the main reason I dropped my physics project and started looking into the physics module.
In Box2D this happens all the time not just more often but it's easily fixed, instead of using rectangle bodies to make the tiles I use [wiki]love.physics.newEdgeShape[/wiki] and then I attach all EdgeShapes to a single static body, thank you Omar for telling me how this is done
It something like this (see v2):

asd.png (1.05 MiB) Viewed 2418 times

And the collision map is loaded from a file:
{ collision

Code: Select all

6 	2 	2 	2 	2 	2 	2 	2 	2 	2 	2 	2 	7 	
1 	- 	- 	- 	- 	- 	- 	- 	- 	- 	- 	- 	3 	
1 	- 	- 	- 	- 	- 	- 	- 	- 	- 	- 	- 	3 	
1 	6	2	2	2	2	2	7	- 	- 	- 	- 	3 	
1 	9	4	4	4	4	-	3	- 	6 	f 	c 	3 	
1 	- 	- 	- 	- 	- 	9 	3	- 	d 	- 	- 	3 	
1 	- 	- 	- 	- 	- 	- 	d	- 	- 	- 	- 	3 	
1 	- 	- 	- 	- 	- 	- 	- 	- 	- 	- 	- 	3 	
9 	4 	4 	4 	4 	4 	4 	4 	4 	4 	4 	4 	8 	
} collision

Output:

(Hmmm.. the gif got chopped)

TL;DR: Very carefully

Indeed