Game Development Community

Tile Hitching Fix

by Ray Gebhardt · in Torque Game Builder · 08/02/2005 (10:08 pm) · 12 replies

I believe I have fixed the tile hitching issue T2D 1.02. Can a few people test it, and look at the code, to see if it might cause any issues? I played with it in my physics / puzzle / platformer game for about 10 minutes without issues. To implement the fix, just do the following:

Replace the following in fxPhysics2D.cpp (line 1205 - fxPhysics2D::findMinimumSeperation):
// Iterate Axes.
	for ( U32 i = 0; i < axesCount; i++ )
	{
		// Check for Collisions.
		if ( pTimeAxis[i] > 0.0f && pTimeAxis[i] > collisionTime )
		{
			// Note Index.
			minimumIndex = i;
			// Note Time.
			collisionTime = pTimeAxis[i];
			// Note Normal.
			collisionNormal = pVertexAxis[i];
			collisionNormal.normalise();
		}
	}

With:
// Iterate Axes.
	for ( U32 i = 0; i < axesCount; i++ )
	{
		// Check for Collisions.
		if ( pTimeAxis[i] > 0.0f && pTimeAxis[i] > collisionTime )
		{
			// Note Index.
			minimumIndex = i;
			// Note Time.
			collisionTime = pTimeAxis[i];
			// Note Normal.
			collisionNormal = pVertexAxis[i];
			collisionNormal.normalise();
			return true;
		}
	}

You are really only adding the 'return true;' at line 1217, but I just wanted to make the post as clear as possible.

#1
08/03/2005 (7:38 am)
Quote:fxPhysics2D::findMinimumSeperation

This is totally off topic (although it should be considered a bug report), and I hate to be pedantic, but "separation" is misspelled in that function name. This would have me pulling my hair out if I was trying to call that function without looking it up first. So I vote to correct the spelling of function calls unless they are a British spelling (like colour instead of color). :)
#2
08/03/2005 (11:03 pm)
Is the hitching bug the same as if i had a map of tiles and I want to move a sprite of the same size inbwteen two
and it will not go cause the collisions seem to be off by a small amount?

Is that realated?
#3
08/03/2005 (11:07 pm)
Its possible it might make a difference, although it might not help. If you want you can try it out, since its only one line of code.
#4
08/04/2005 (9:40 am)
Yeah its one line.
But when looking over the function its its Im not sure why you wanted to exit it early.
It looking like it shoudl exit just fine after the loop?
Cause minimumIndex lets set above -1 ?

So I was not sure what effect this fix was having.
Of course it was late and I had been working on T2D for like 9 hours at the time ;)
Just wondering
#5
08/04/2005 (11:52 am)
Well if it doesn't early out, the values of collisionTime and collisionNormal may be different in certain cases. It solves my issue, in my game, but honestly I am not exactly sure why.
#6
08/05/2005 (8:22 am)
I would have thought that if you didn't early out you could get multiple axis collisions and only the very last one would be reported.

As a result you can potentially get a normal returned, that faces the wrong way! I.e. you collide with both the tile below and the tile in front but, the returned normal is for the collision with the tile in front. Such a collision would be reported back as being side on!

I think this is what causes the skipping.

Without testing any code, I would think a side effect of an early out will be that you can collide with a floor tile but, potentially walk through a wall tile (if you happen to be hitting both at the same time)!
#7
08/05/2005 (11:12 am)
The default functionality can get multiple collisions, but it only saves the one with the smallest collision time. So my guess is that since I early out, it bypasses the incorrect collision I was getting (that would cause the tile hitching). A better fix would be to have a threshold for the collision time values, so that it would not accept values under a certain number (like when you are just barely not touching a tile). Or maybe there is just a different way this function could be written to avoid that issue.

So essentially by doing the early out, I am just getting lucky. Since its not doing the sorting, it just happens to work in my circumstance. I wouldn't mind seeing what Melv has to say though, and see if his new fix for the issue would make changes it unnecessary to modify this function.
#8
08/05/2005 (11:15 am)
Oh, and BTW, you can't walk through walls or anything after applying the code above.

EDIT: LOL, or I haven't been able to yet.
#9
08/05/2005 (3:55 pm)
:o)

Hey I read the code in isolation at my desk at work!

Dry running it I assumed that as the last normal is used, you would sink (all be it by one pixel) into the floor if you hit both the floor and the wall at the same time. You would then appear to bounce out of the floor when the intersection code ran.

A dry run through with the early out would suggest that is reversed i.e. you sink one pixel into the wall and appear to bounce out of the wall when the intersection code runs.

meh without running it I can't say for certain that the code does anything :o)
#10
10/10/2005 (4:12 pm)
Thank you very much @Ray, your fix suppressed the slow down walking backwards that I was having :)
Somebody knows a caveat about this fix?
#11
10/10/2005 (6:04 pm)
Slow down walking backwards does not work for me. =( I wonder how you tiles are set up.
#12
10/11/2005 (9:17 am)
This way:

/ --------------------------------------------------------------------
// Immovable Collision Material.
// --------------------------------------------------------------------
datablock fxCollisionMaterialDatablock2D(immovableMaterial)
{
	friction = 0.0;
	restitution = 0.0;
	relaxation = 0.5;
	density = 0.01;
	forceScale = 0;
	damping = 0.0;
};


// --------------------------------------------------------------------
// Standard Collision Material.
// --------------------------------------------------------------------
datablock fxCollisionMaterialDatablock2D(standardMaterial)
{
	friction = 0.0;
	restitution = 0.0;
	relaxation = 0.5;
	density = 0.01;
	forceScale = 1;
	damping = 0.0;
};