I am trying out an approach to 3d-looking simulations. Basically, the player sends out a massive ray of light that reports how far it took for an object to hit a wall and puts it in a list. The simulator uses this list to create depth, changing the brightness and size of the “wall” sprite to make a giant “wall” . However, there is an issue about this. Since the light departs from the other light particles, they all take very different parts of the wall, creating this warped effect on the edges. I don't want this, as I want the rooms and halls to look straight while the warp effect makes the walls and rooms look curved. I do not know how to fix this and I want help.

Here is the link to the simulation so far. It is not finished, so it may not look the best. : https://scratch.mit.edu/projects/1236137796/

After somebody assisted me, it looks better. However, it feels off in a way and it slightly curves still. here is the link the new one: https://scratch.mit.edu/projects/1236599222

try griffpatches method

Com_engineer_Tom wrote:

try griffpatches method

What exactly do you mean? If you are talking about the ray tracing method, no I wont do that. But if you are talking about the particles, please drop the link to it and I'll see.

Nice work on the ray caster so far! This is actually a real effect of cameras. It is especially noticeable for wider fov cameras. To see why this happens, we can take this to the extreme case. Imagine if you had 180-degree FOV vision and you were looking directly at an infinitely wide wall in front of you. If you traced the outline of the top and bottom of the wall, they would not be straight. They would converge to points off in the distance, which means that the lines would have to be curved.

I'm not sure exactly how to compensate for this distortion, but multiplying all X Dis values by cos(direction of sprite 1 - direction) sort of helped.

define Move
repeat until <<touching [Map v]?> or <touching [Map2 v]?>>
    change [Z v] by (4)
    move (4) steps
    if <touching [Enemy v]?> then
        broadcast [Show v]
    end
end
replace item (id) of [X Dis v] with (([cos v] of (([direction v] of [Sprite1 v]::sensing) - (direction))::operators) * (Z))
if <touching [Map2 v]?> then
    replace item (id) of [Type v] with [d]
else
    replace item (id) of [Type v] with []
end
stamp
delete this clone

What this does is it uses the distance along the axis of the player direction, disregarding left to right distance in position.

N8_D_GR8_1 wrote:

Nice work on the ray caster so far! This is actually a real effect of cameras. It is especially noticeable for wider fov cameras. To see why this happens, we can take this to the extreme case. Imagine if you had 180-degree FOV vision and you were looking directly at an infinitely wide wall in front of you. If you traced the outline of the top and bottom of the wall, they would not be straight. They would converge to points off in the distance, which means that the lines would have to be curved.

I'm not sure exactly how to compensate for this distortion, but multiplying all X Dis values by cos(direction of sprite 1 - direction) sort of helped.

define Move
repeat until <<touching [Map v]?> or <touching [Map2 v]?>>
    change [Z v] by (4)
    move (4) steps
    if <touching [Enemy v]?> then
        broadcast [Show v]
    end
end
replace item (id) of [X Dis v] with (([cos v] of (([direction v] of [Sprite1 v]::sensing) - (direction))::operators) * (Z))
if <touching [Map2 v]?> then
    replace item (id) of [Type v] with [d]
else
    replace item (id) of [Type v] with []
end
stamp
delete this clone

What this does is it uses the distance along the axis of the player direction, disregarding left to right distance in position.

Thank you! I will try this out and see if it helps with the curving.