Jump to content
  • Advertisement
Sign in to follow this  
menyo

A very VERY bad int.

This topic is 2498 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So i almost completed my a* smoothing algorithm a couple of hours ago. But sometimes it went through walls somehow, some way.

After debugging very long, and letting all the colision rectangles show up i noticed i was moving my rectangle by (int)0.96 since multiplied normalized X vector of 0.16 with 6(1/5 of my tiles). So it never bumped into the wall and figured the next straight path should be above the wall.

Now i am just multiplying my normals with 1/2 of my tile size, and i should not foresee any problems with what i currently have, it does ocasionally go slightly across a non walkable tile but it's not very noticable. But what if i have really long straight walls so my normalized vector times the full tile size would be below 0. I can 't simply increase the normal since it's used for direction.

I should probably tell how i am doing my smoothing.

I get the path list from a regular A*.

I then "for" loop through it and see what the first path is i can not reach straight.

I check the distance and direction of both tiles and let a test rectangle test the path until it reaches the destination.

testrec.X += (int)(direction.X * velocity);
testrec.Y += (int)(direction.Y * velocity);
// a rectangle only excepts ints, hence the cast so if the direction*velocity of testing rectangle is not above 1 it won't move that direction and thinks the path is ok. I really like this velocity as low as possible so my paths are not intersecting.


I put the tile [i - 1(since i is not reachable)] as a vector in a new list.

Repeat until the list is done.

Share this post


Link to post
Share on other sites
Advertisement
If you are using tiles, your speeds and positions (at least the ones you use for pathfinding and physics) should be integers.

Fractions can be used to break an "official" move into several interpolated frames of animation: the worst that can happen is a practically invisible error in sprite position.

On the other hand, when you use floating point for equality comparison (like in your tests for touching walls) slight errors are amplified.

Share this post


Link to post
Share on other sites
Not sure what your saying....

It's like this

My character hugs a wall to the right and clicks 20 tiles above player and 1 tile to the right (where the wall ended after 20 tiles up).

Now i calculate the direction by:
direction.normalize(tileclicked - playerlocation);

Now the normalized vector has a X value of .05 (don't get me on my math please :D), so i let this collision rectangle traverse the path rectangle by doing:
rectangleX += direction * 15pixels;

Now since the rectangle only excepts int's i have to vast a int on it. and since .05 * 15 == .75 that rectangle will never move into the wall and detect colision. And 15 pixels are pretty long steps to check for colision on 32*32 tiles. I rather use something like 5 or 6 so things never move through walls.

One way to solve it is to make for each angle a sepperate statement but this feels like overkill.

Share this post


Link to post
Share on other sites
Sorry for misunderstanding your code, I didn't notice you rounded coordinates to integer values. This is, however, as wrong as using fractional positions: your integer positions have a random perturbation of up to 1 unit, which can cause all sorts of biased and incorrect pathfinding (errors can accumulate arbitrarily along the steps of the path) and unpredictable collision detection.

Correct and predictable tile-based movement requires moving from tile A to tile B in a whole number of turns, altering actual movement speed (for example, adjacent tiles in 2 turns and diagonally adjacent tiles in 3 turns rather than the "natural" 2.828... turns); you might need to break down tiles or turns into smaller units to reduce error, but the cost of a move should be a whole number of turns.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!