Had a video on ray casting pass by in my Youtube feed the other day and thought I'd play around with it a bit.
There are the four outer walls and then four randomly generated interior walls. It's casting 27 rays so, when moving, that's 216 intersections calculated per frame at 60 fps. Either more walls or more rays forces it down to 30 fps so it's a bit of a performance hog (okay, a huge performance hog.) I'm sure it could be optimized somewhat, though I'm unlikely to do it.
Edit: Okay, so apparently I lied. I realized that I could have my rays do double duty by calculating two intersection points each, one in each direction along the line. So I get effectively twice as many rays for virtually no extra cost.
Here's a quick little modification I made which uses the same logic to handle actual collisions with the walls. It's only casting one ray in the direction of movement so you could add a lot more walls before you notice performance issues. It's not perfect. Every once in a while the red dot will zip right through a wall. I suspect this is just because of decimal precision errors and in an actual game could be fixed by checking more than one point for collisions: the four corners of the sprite for instance. But, again, I probably won't bother.
Oh, and the video:
I'm thinking top down stealth game and use raycasting to give the gaurd/police/what ever flashlight you have to avoid, lest they see you.
@Jodipijoo I really like that idea actually! The code as it exists now is nowhere near efficient enough to manage it but if you don't mind me running with your idea I might be able to switch it up for something more performant and throw together a little prototype.
Watching this makes me think of a spider game, @jasondelaat. Where the vertices you have are actual spider-legs, limited by length and number. Perhaps you have to climb some edifices and avoid enemies.
. . .
You've got something interesting here. I may try this out on a grid, considerably simpler than you are doing.
[Please log in to post a comment]
