# SOLVED! I have a pelicular bug in my game, needing help

Get help using Construct 2

### » Tue Apr 15, 2014 3:54 pm

Got it! The problem is, by using Move at angle, you are not guaranteed nice integer Player position values. If you dump the player coordinate, you see they are not always even multiples of 32. As a quick fix, do:

Every tick -> Set Player position to round(Player.X), round(Player.Y)
B
71
S
22
G
279
Posts: 3,839
Reputation: 153,880

### » Tue Apr 15, 2014 3:56 pm

Oooh, thank you, that one I would not have caught myself! I will look at my capx and implement your fix and see if it helps.

EDIT: It helped!!! Thank you so much, @Blackhornet

And while at it, I might add that rounding to all the moveable objects.
B
60
S
18
G
13
Posts: 449
Reputation: 10,811

### » Tue Apr 15, 2014 4:00 pm

Got it.
The problem was a rounding error when setting the player's X position when moving UP in the first column.
It was being set to 63.99999999999 instead of 64.
This is likely due to using the "move at angle" action not being precise enough.

The bug is fixed by replacing those actions with "Set Position" actions and manually adding/subtracting from X/Y coordinates.

It would also be fixed if you replaced your int() logic with round() logic, but that would be more akin to masking the bug than to actually fixing it.

A better solution would be to not rely on the player's X/Y position on the canvas to determine it's X/Y position on the grid. Set the player's X/Y position on the canvas based on it's X/Y position on the grid, not the other way around.

To see the bug in action, open your broken capx and:
1. select the player object in the debugger
2. Watch it's X position, it should be TILESIZE (in this case, 64)
3. Move down. It's X position should still be the same (64)
4. Move up. It's X position should be slightly lower than TILESIZE (63.999999999)
5. Your expression evaluates GridX to int((63.999999999/64)-1) -> int(0.99999-1) ->int(-0.00001) -> 0
6. You expected it to evaluate to 1, so your code breaks.

That was a tough one! @Ashley, we have a rounding error here, possible bug?
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

### » Tue Apr 15, 2014 4:03 pm

And thank you, @fimbul (and for your more in depth solution/explanation too so it will help other people too if needed.)

I am so thankful of the help of this excellent forum.

"proper" bug or not, I am happy that this got solved with your help, at least found the actual error. I almost considered making a *very ugly* solution of only for column 1 up, but no need for that now.
B
60
S
18
G
13
Posts: 449
Reputation: 10,811

### » Tue Apr 15, 2014 4:09 pm

I forgot to upload the fixed version. Here you go.

Also @helena, don't just "round" the values, please, otherwise this bug might come back to haunt you.

My "fixed" version is a better workaround than rounding, but it's even better to implement the proper fix like I described (by using gridX and gridY as basis for player.x and player.y).
You do not have the required permissions to view the files attached to this post.
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

### » Tue Apr 15, 2014 5:49 pm

Looking at your version, you changed from Move to Set Position, I see. That's better.

I might actually want more smooth moving but that's for future, when I have gotten the base nice. Smooth moving and smaller "window". No you do not have to help me with that one, I like to try things myself first.

Thank you again,
@Fimbul
B
60
S
18
G
13
Posts: 449
Reputation: 10,811

### » Tue Apr 15, 2014 7:09 pm

Very slight inaccuracies or rounding of floating-point numbers happens at the CPU level on all architectures and affects all the software on your computer. You simply have to design your game to tolerate slight inaccuracies, for example instead of comparing X = 64, compare abs(X - 64) < 0.01, so there's a small amount of tolerance.
Scirra Founder
B
413
S
244
G
92
Posts: 25,073
Reputation: 199,682

Previous