mr2meows wrote:

you could use the backdrop

mmhmBeans wrote:

For the ceiling lights, you should do a grid, such as on the floor of this project. I don't think there is any efficient way to texture the floor/ceiling. In my raycaster, I just put the lights on walls.

pkhead wrote:

that'd probably require some complicated math.

i think essentially for each pixel, you make a ray based on the position of that pixel and calculate the distance it would take for the ray to reach the floor. i think the formula would be something like “Y distance from floor to camera divided by ray delta y” since the distance should become larger than smaller ray delta Y is. (0 = parallel to the floor)

and then you get the floor pixel the player is on (probably doesn't require fancy math, just use the player x and player y variables divided or multiplied by some constant) and then, based on the ray distance and player rotation, offset the position of that pixel on the texture. then draw this pixel on the texture on the screen.

if you want a less confusing explanation i can probably try drawing some visuals when i get home

if <(ray dz) < [0]> then // if ray is pointing downward
  set [ray dist v]  to ((cam z) / (ray dz)) // calculate ray distance to floor plane (z=0)
  set [ray floor x v] to (((ray dx) * (ray dist)) + (cam x)) // calculate intersection point between ray and floor plane
  set [ray floor y v] to (((ray dy) * (ray dist)) + (cam y))
  set [ray floor z v] to [0] // = ray dz * ray dist (since floor plane is at z=0)
  set [tex u v] to ((ray floor x) mod (tex width)) // tex u and tex v are the texture coordinates
  set [tex v v] to ((ray floor y) mod (tex height)) // using mod makes it repeat
  draw pixel at (tex u) (tex v :: variables) from texture to current screen pixel :: custom
end

pkhead wrote:

i made a proof of concept in p5.js here
(i made in p5.js and not scratch because p5.js runs faster. hopefully you can read javascript code)

this is a snippet of code which is involved in calculating which pixel to draw on screen, given a ray direction (ray dx, ray dy, ray dz), and the camera position (cam x, cam y, cam z)

X is left-right, Y is front-back, and Z is up-down.
ray dx is equal to the cosine of the camera angle. and ray dy is equal to the sine of the camera angle.
other than that, i will leave the calculation of the ray direction for each pixel up to you.

if <(ray dz) < [0]> then // if ray is pointing downward
  set [ray dist v]  to ((cam z) / (ray dz)) // calculate ray distance to floor plane (z=0)
  set [ray floor x v] to (((ray dx) * (ray dist)) + (cam x)) // calculate intersection point between ray and floor plane
  set [ray floor y v] to (((ray dy) * (ray dist)) + (cam y))
  set [ray floor z v] to [0] // = ray dz * ray dist (since floor plane is at z=0)
  set [tex u v] to ((ray floor x) mod (tex width)) // tex u and tex v are the texture coordinates
  set [tex v v] to ((ray floor y) mod (tex height)) // using mod makes it repeat
  draw pixel at (tex u) (tex v :: variables) from texture to current screen pixel :: custom
end

PutneyCat wrote:

If you start casting rays up/down as well as left/right you will get severe lag.

So better to stick to left-right.

If you have a list-based raycaster, you can can still create the grid effect shown in the cool project linked above in the post by @mmhmBeans, for floor or ceiling or both.

That's because a list-based raycaster uses a grid system. The ray travels in a straight line through the grid, checking whether each square is occupied or not. So the rays cast from left to right allow you to draw walls and also a floor/ceiling grid. If a square is filled: draw a wall and stop. If it is empty, put a small dot down as part of the gridlines, and continue.

But this won't work with a sprite-based raycaster, because that doesn't use a grid system. The sprite/ray just keeps going till it hits something.

when I receive [talk v]
speak (talk)

forever
Jesus Loves you::#ddddff

play sound [gasp v] until done

answer [Type in the reply.]::#0000ff

Scratch Maker{
Entertainment
Fun
Info
}Pashes1

(ver.::#0000ff)

Did you know that the Scratch blocks in forum are [Scratch 2.0 v] blocks.//Tip for you.

immememe wrote:

i suppose you could just make it whatevet texture you want across the whole screen then just draw everything else on top (and make the texture move and stuff