next »

[Daniel Pellicer]

Im not sure why this happens.

Sometimes when my character have enough velocity he enters in earth (or in the walls). The problem is that this seems to be non-reproducible. I changed my code not so long ago (see this thread => http://forums.tigsource.com/index.php?topic=46275.0) so that the update of the world is done in the same step size each time so I supposed everything would be reproducible.

Where can I start? How can I debug something that is non-reproducible? Anyone had this issue before?

Thank you!

[oahda]

Sounds like your character falls so fast that in the actual simulation it never actually touches the ground. One frame above the ground and one frame below it, but never actually touching it.

See picture number two on this page:

https://www.aorensoftware.com/blog/2011/06/01/when-bullets-move-too-fast/

The bullet never actually touches the block because it is moving so fast. This is called tunnelling and there are various ways to solve it.

You could for example calculate where the character should be next frame and check whether it collides with anything in between that position and the current position.

This could be done by dragging a line between the two positions and seeing if that line intersects with anything, for example. Or a line on either side of the character. Or both sides and the middle. For ground that's probably enough. For small objects it might not be.

[Daniel Pellicer]

I understand. but this would be kind of reading the future.

What do I have to do if I predict that it actually can collide? reduce the speed? in the webpage you gave me it says do more simulations if you detect a problem could happen but this would change the repetibility of events and I'm not sure I want that

What if something happens (my character get hits with an enemy shot) and actually I was never going to land there anywhere?

[oahda]

I understand. but this would be kind of reading the future.

Well, that is what it is. But you can read the future. If you have the falling velocity of your character, you know that the next frame your character's y position will be set to y + vertical velocity, because that's how you're calculating it in your physics code anyway (or at least so I presume).

What do I have to do if I predict that it actually can collide? reduce the speed? in the webpage you gave me it says do more simulations if you detect a problem could happen but this would change the repetibility of events and I'm not sure I want that

I didn't read the rest of the page, so I don't know if the rest of the information there is useful. Maybe I should have just linked the image. Sorry about that.

If you predict that it would collide then you call your normal collision code as you are already doing when your current code detects a collision.

What if something happens (my character get hits with an enemy shot) and actually I was never going to land there anywhere?

That's up to you. If you check all collisions before you update and find both a collision with the ground and a collision with a bullet at the same time, you will have to write your own code to decide if one collision is more important then the other and perhaps not even handle the other one.

You should probably handle both, however, and first treat the collision with the ground and push the character back up and then check whether the bullet hit after that.

If you want to get really complex, tho, you can calculate which collision happened first and make your decision based on that, but you should probably make it simple first. Fix the ground bug to begin with and then move on to this sort of stuff.

[Daniel Pellicer]

I think I'm still not getting it sorry

I do already something like seeing the future

Code:

if (character.velocity.y < 0) {
			startX = (int) Math.floor(character.getX() / 16f); // lo que viene
			finalX = (int) Math.floor((character.getX() + character.getWidth()) / 16f); // donde
			startY = (int) Math.floor((character.getY() + character.velocity.y * deltaTime) / 16f);
			finalY = (int) Math.floor((character.getY() + character.getHeight()) / 16f);

			Rectangle playerRect = this.rectPool.obtain();
			playerRect.set(
					character.getRect2().x,
					character.getRect2().y + character.velocity.y * deltaTime,
					character.getRect2().width - 2,
					character.getRect2().height
							+ Math.abs(character.velocity.y * deltaTime));

			Vector2 tileCollision = checkThisTilesGeneral(layerTiles, startX, finalX, startY, finalY, playerRect, deltaTime);

I add the velocity and multiply by the time occurred since last update and I check all the tiles in this range. Are you suggesting to check also one more step ahead?

[BorisTheBrave]

Just put a cap on the max speed of your player, which should solve the problem. Prinsessa's solution is a rather advanced technique for if you really need very fast small objects.

As for general advice about debugging difficulty to reproducible circumstances:
 - Try to make your program as reproducible as possible. Use a fixed seed for random numbers, reduce the processors available to 1 and replace your timer methods with fake ones that return exactly the same results each time.
 - Log your program to the wazoo. Most logging libraries allow you to add debug logs that are very cheap to leave in your program when you are not using them. But when attempting to reproduce something, you can turn up the log level.
 - Improve the save/load ability of your program, and get a save immediately prior to the problem (perhaps by saving every frame). Does the problem persist when you reload? What does that tell you about the nature of the problem?

[oahda]

Max speed and perhaps thicker ground collider might be enough too, yeah. Depends on your needs.