Raycast2D getting the wrong coordinates on collision with Tilemaplayer | Godot Engine | Page 1

dense shell Sep 6, 2025, 11:06 PM

#

i'm just copying my question from [here](#❓┃quick-help message)
is there a known issue with raycast2d's GetCollisionPoint() getting the incorrect coordinates for tilemaplayers?
this is my code:

    private void CheckRaycast()
    {
        if (!PlayerRayCast.IsColliding())
        {
            return;
        }

        Vector2 collPos = PlayerRayCast.GetCollisionPoint();
        MineTile(collPos);
    }

    public void MineTile(Vector2 coords)
    {
        Vector2 localPos = tileMapMain.ToLocal(coords);
        Vector2I cell = tileMapMain.LocalToMap(localPos);
        //GD.Print("hitting " + coords + " " + localPos + " " + cell);
        tileMapMain.EraseCell(cell);
    }

i can mine the tile below the player, from the right of the player, and downright of the player. tiles are 16x16 px, tilemaplayer's coordinates are 0 0.
but when i try to mine a tile to the left of the player, it gets the tile off by 1 to the right
as you can see in the console it's off by 1 to the right when i'm next to it on the left, but not when i'm on top mining down, or on the left side mining to the right
mining up also does not work, it's also off by 1 down

rapid orchid Sep 6, 2025, 11:33 PM

#

I'm just guessing here, but it looks like your collision point is just short of a full number, so maybe it get's lost in rounding?

#

if all tiles are just cubes i would use the target position (way inside the tile) to find the coord

#

or round the coord, instead of floor 🤷‍♂️

dense shell Sep 6, 2025, 11:36 PM

#

i also tried it by rounding the hitposition, and dividing that by 16 (tilesize) and rounding that Vector2 roundedPos = (collPos / 16).Round();
which is the last value you can see in the logs (GD.Print("hitting " + coords + " " + localPos + " " + cell + " " + roundedPos);)

#

it's basically the same output like Vector2I cell = tileMapMain.LocalToMap(localPos);

azure drum Sep 6, 2025, 11:40 PM

#

Do you ever change the target position of the raycast?

#

When it's changed, if you want to check if it's colliding in the same physic frame, you have to call force_raycast_update, or whatever it is in C#

dense shell Sep 6, 2025, 11:43 PM

#

i mean i'm moving around, so ig i'm changing the target constantly, should i force the raycast update every frame?

rapid orchid Sep 6, 2025, 11:44 PM

#

Also.. is your raycast starting exactly at the center of your character? (0,0)

azure drum Sep 6, 2025, 11:45 PM

#

Only if you do exactly this sequence in one frame :

set the raycast's target_position to something else
and then get the collider or collision point
Otherwise no

rapid orchid Sep 6, 2025, 11:46 PM

#

But tbh.. i would just use the target pos instead of collision pos as soon as there is collision to do the finding/erasing

azure drum Sep 6, 2025, 11:47 PM

#

You'd have to set the target_position, call force_raycast_update, then query the collision point.
Also what micro said.

rapid orchid Sep 6, 2025, 11:48 PM

#

this one is also .. soo close

dense shell Sep 6, 2025, 11:50 PM

#

public override void _Process(double delta)
{
    PlayerRayCast.TargetPosition = direction * 16;
    PlayerRayCast.ForceRaycastUpdate();
    CheckRaycast();
}

i added ForceRaycastUpdate() to it, since i'm doing what sankto said, but it's still off

dense shell Sep 6, 2025, 11:53 PM

#

rapid orchid Also.. is your raycast starting exactly at the center of your character? `(0,0)`

no it's at x0 y-8, 0,0 would be on the floor

rapid orchid Sep 6, 2025, 11:54 PM

#

dense shell no it's at x0 y-8, 0,0 would be on the floor

What if you round first and then divide by 16? .. as it's that coordinate which is close..

roundedPos = collPos.Round() / 16

dense shell Sep 6, 2025, 11:55 PM

#

the rounded one is this one, but i can try

rapid orchid Sep 6, 2025, 11:55 PM

#

or just

collPos = collPos.Round()

#

hm

#

rounded after division and rounded again = 0.0

#

rounded before division and rounded again = 1.0

#

which might jump to 1 in vector2i .. idk 🤷‍♂️

#

but.. 0.5 rounded is 1.0 which is what you would expect there (16,1), no?

azure drum Sep 7, 2025, 12:01 AM

#

At this point I would recommend going with the target_position's endpoint :

MineTile(collPos);```
Something like that

dense shell Sep 7, 2025, 12:03 AM

#

this works fine and i really appreciate that, but now this situation can happen,,

#

also i plan to extend the raycast as a purchaseable upgrade

rapid orchid Sep 7, 2025, 12:04 AM

#

so rounding fix then :P

#

aka..

Vector2 collPos = PlayerRayCast.GetCollisionPoint().Round();

dense shell Sep 7, 2025, 12:08 AM

#

#

still off

dense shell Sep 7, 2025, 12:08 AM

#

rapid orchid aka.. ``` Vector2 collPos = PlayerRayCast.GetCollisionPoint().Round(); ```

with this solution

rapid orchid Sep 7, 2025, 12:12 AM

#

hm

dense shell Sep 7, 2025, 12:12 AM

#

i'm pretty confident it's not a rounding issue

#

should we ping the voluntary helpers?

#

<@&1349109171240439858>

#

oops did i mess up?

rapid orchid Sep 7, 2025, 12:23 AM

#

actually.. i was looking at the wrong value.. it's X that's off

#

it should be (2,0) in the screenshot above, but 48/16 is 3, so that is correct 🧐

dense shell Sep 7, 2025, 12:27 AM

#

you got it

#

if it's helpful, this is my player

rapid orchid Sep 7, 2025, 12:30 AM

#

looks fine

#

maybe something with the tileset?

#

maybe tileset just 1px to the right?.. or the collision shape of the tile?.. i mean.. still guessing :P

dense shell Sep 7, 2025, 12:34 AM

#

tilemap and tilesets are all generated via code,, i come from a monogame environment, but checking the remote view it all looks fine

rapid orchid Sep 7, 2025, 12:37 AM

#

well.. i tried :( .. hope a solution will be found

dense shell Sep 7, 2025, 12:37 AM

#

thx a lot, i appreciate your help

#

and uh, how do i ping the happy to help? maybe they got a solution?

rapid orchid Sep 7, 2025, 12:40 AM

#

i think you did it correctly

#

dense shell Sep 7, 2025, 12:43 AM

#

i did that, but it said that some people weren't pinged (probably all of them)

rapid orchid Sep 7, 2025, 12:43 AM

#

dunno never used it 🤷‍♂️

pallid coral Sep 7, 2025, 12:54 AM

#

dense shell i did that, but it said that some people weren't pinged (probably all of them)

Yeah, for some reason I was pinged in the quick help, but not here. Must have to do with membership to the thread I guess.

dense shell Sep 7, 2025, 12:54 AM

#

oh quirky discord

pallid coral Sep 7, 2025, 1:12 AM

#

I mean, I think a fair question is how important is it to use a raycast for this functionality? If this is still prototyping this kind of mining, it might be easier to hold the player's tilemap posision (the very end of the print statements in question) and use simple math to see which tile to remove.

timid pawn Sep 7, 2025, 1:15 AM

#

It really does sound like a floating point error, since your bounding boxes would sit on exact values 0.0, 16.0, 32.0 which aren't truely possible to capture.

I'd add a little extra kick in the direction of the raycast. gdscript psuedo code;

var final_coord = collision_point + (ray_target - ray_origin).normalized() * 0.01

#

*if you wanted to keep the raycast. I agree with the others though, pixel-line drawing algo's are pretty straight forward and may actually give you more precise control when mining diagonally over > 1 tile lengths. eg, you might want to avoid mining a block diagonally when the ray only just barely clips the corner of another block

dense shell Sep 7, 2025, 1:19 AM

#

interesting, i will try that first, and then i'll try the pixel line thing if it still doesn't work

dense shell Sep 7, 2025, 1:24 AM

#

timid pawn It really does sound like a floating point error, since your bounding boxes woul...

yes this worked! thanks a lot, i really appreciate it
but now i do be curious about the other solution you two mentioned

#

oh oops, external emotes not allowed here?

timid pawn Sep 7, 2025, 1:31 AM

#

if you pretend a tile is one pixel, you can use pixel-line-drawing to determine which pixels to "fill". applied to your tiles that would tell you which were hit or not. Those algos typically include a value for how much of the pixel the line passes through - typically they're used to color lines dark/light grey but you could tweak that value to figure out how much you want corners to clip.

#

with that same approach you could look into using two lines with a slight offset, to give some thickness/buffer to the target, to avoid the case where a perfectly diagonal direction, pointed at a corner / overhang, could mine a block that isn't exposed

#

idk, kind off feels like the sort of thing that might be useful when you're extremely deep into the design and want to obsesively tweak the game feel, but otherwise might end up being overkill

dense shell Sep 7, 2025, 1:36 AM

#

i like overkill, is there a tutorial or any resources on how to do that (preferably in godot and/or c#)?

timid pawn Sep 7, 2025, 1:48 AM

#

there's a few listed here;
https://ocw.unican.es/pluginfile.php/2539/course/section/2654/03-LineAlgorithms.pdf

the main go-to is bresenham;
https://ghost-together.medium.com/how-to-code-your-first-algorithm-draw-a-line-ca121f9a1395

Medium

How to Code Your First Algorithm — Draw A Line

A new project always starts with a problem-solving question.

#

this one incorporates better aliasing, to give you control over which "pixels" to include/exclude
https://en.wikipedia.org/wiki/Xiaolin_Wu's_line_algorithm

Xiaolin Wu's line algorithm

Xiaolin Wu's line algorithm is an algorithm for line antialiasing.

#

I'm pretty confident there'd be more than a few c# implementations out there - probably included in line/shape/path drawing libraries. It's been a while since I touched c# so I don't have any references left

#Raycast2D getting the wrong coordinates on collision with Tilemaplayer