pico 8 is the best thing thats happened to me as a beginner who always wanted to get into game dev, its simple enough that i can learn and let my creativity loose but powerful and capable enough that i can still do challenging projects and really put my determination and skills to the test.
Interesting. Some idea I used: You can just draw boxes where there are boxes in a fashion you define. Like a special render of a string array: (1)"wwwwwddwwwwww" (2)"w w" (3)"w ii w" (4)"w w" Any turn is just an angle and you limit the drawing to the angle (viewport) and update when changes happen. It's important to update visible monsters, though.
Is there a code for the player movement? It looks like there's some code that was already assumed to be implemented (i.e. player x/y and player angles).
A raycasting game(this is technically ray marching, but it doesnt matter) is just a 2d game built on a grid. Like looking at a 3d game top down. Just add to the x and y, with a little rotation sin()/cos() magic, and it moves like normal!
Sorry about that, I'm not very good at explaining things. The goal of the algorithm is to check every point where the ray intersects the grid, and then see if there's a wall tile at that intersection point. That way we can find the closest point where the ray hits a wall, and then we will know what to draw on the screen. It turns out that if you count the horizontal and vertical intersections separately, it's easier to iterate through them all. That's what the pink and orange markings are, the intersections with vertical lines and the intersections with horizontal lines, respectively. The distance from one pink marking to the next is always the same, so we can just add that amount to our distance over and over to keep finding the next pink marking along the line. We can do the same for the orange markings as well, with a separate variable, and that way we know we'll check every possible intersection point. When I talk about moving up and moving to the right, that's because we're also keeping track of the tile that the ray is hitting at our current distance. If the tile the ray hits is empty, we can move on to check the next tile. We're always working with the shorter of the two distances I talked about earlier, whichever one that happens to be. Which one of the two we just checked can tell us whether the tile above or the tile to the right is the correct next one along the ray. If we do all this correctly, what we end up with is an algorithm that keeps track of a tile location, and every iteration it moves to the next tile along the ray, using two distance variables to make sure it is checking the right tiles. As soon as it finds a wall tile, the loop stops because that's the point where the ray hits a wall. At that point, the shorter of the two distance variables is the total distance the ray has traveled uninterrupted before hitting the wall, so we can use that knowledge to draw it on the screen properly. Sorry for the essay, I just wanted to be thorough. I hope this clears things up at least a little. Thanks for the feedback.
Lets goooo, the pico 8 community needed a updated video on raycast
pico 8 is the best thing thats happened to me as a beginner who always wanted to get into game dev, its simple enough that i can learn and let my creativity loose but powerful and capable enough that i can still do challenging projects and really put my determination and skills to the test.
same dude, I love this thing
This is underrated.
No cap
I legit know nothing about raycast or how this works but this is definitely helping a lot, i cant wait to see future videos.
I'm glad it helped, more is on the way.
Como é possível um sistema 8 bits fantasia manipular um sistema 3d melhor que sistemas 16 bits como Mega e SNes??
VERY helpful. Please carry on doing these kinds of videos
Can't wait for part 2. I think this channel will be one of my favourites!
This is awesome! Really well explained.
part 2: rtx in pico 8
Interesting.
Some idea I used:
You can just draw boxes where there are boxes in a fashion you define. Like a special render of a string array:
(1)"wwwwwddwwwwww"
(2)"w w"
(3)"w ii w"
(4)"w w"
Any turn is just an angle and you limit the drawing to the angle (viewport) and update when changes happen. It's important to update visible monsters, though.
I watched javidx9s video on ray tracing using this same method but wasnt able to translate his code so this helps alot
Amazing video. Wolfenstein3D looks less like coding black magic and more like math now
rly good video, i understand being awkward on a video cuz ur new, dont worry, its rly good, u got this :D
Cool wolf3d recreation in the start ;)
amazing!! keep it up my mannn thank you!
You are a madman
we are closer to doom on pico 8
look up poom
HELLOOOOOOO I'VE BEEN WAITING FOR SOMETHING LIKE THIS
Impressive!
I'm not even using pico-8, but that's good shit, thanks
you can remove the fisheye effect.
spacecat?
Is there a code for the player movement? It looks like there's some code that was already assumed to be implemented (i.e. player x/y and player angles).
A raycasting game(this is technically ray marching, but it doesnt matter) is just a 2d game built on a grid. Like looking at a 3d game top down. Just add to the x and y, with a little rotation sin()/cos() magic, and it moves like normal!
This, and I kid you not, is pretty much exactly how the old doom arcade games work
No shit, sherlock...
DooM arcade games??? Where?????
@@charbomber110 is you are have the stupids?
amazing, thank you!
somebody will recreate wolf-3d on pico 8
They've already done Doom, I'm sure pico-8 Wolfenstein is out there somewhere too.
pico from game
Great.
*Now make Wolfenstein 3D.*
I'm not quite there yet, but I think you'll approve of the textures I used in section 2.
im blinking fast and looking confused
lost me at 2.35
Sorry about that, I'm not very good at explaining things. The goal of the algorithm is to check every point where the ray intersects the grid, and then see if there's a wall tile at that intersection point. That way we can find the closest point where the ray hits a wall, and then we will know what to draw on the screen.
It turns out that if you count the horizontal and vertical intersections separately, it's easier to iterate through them all. That's what the pink and orange markings are, the intersections with vertical lines and the intersections with horizontal lines, respectively. The distance from one pink marking to the next is always the same, so we can just add that amount to our distance over and over to keep finding the next pink marking along the line. We can do the same for the orange markings as well, with a separate variable, and that way we know we'll check every possible intersection point.
When I talk about moving up and moving to the right, that's because we're also keeping track of the tile that the ray is hitting at our current distance. If the tile the ray hits is empty, we can move on to check the next tile. We're always working with the shorter of the two distances I talked about earlier, whichever one that happens to be. Which one of the two we just checked can tell us whether the tile above or the tile to the right is the correct next one along the ray.
If we do all this correctly, what we end up with is an algorithm that keeps track of a tile location, and every iteration it moves to the next tile along the ray, using two distance variables to make sure it is checking the right tiles. As soon as it finds a wall tile, the loop stops because that's the point where the ray hits a wall. At that point, the shorter of the two distance variables is the total distance the ray has traveled uninterrupted before hitting the wall, so we can use that knowledge to draw it on the screen properly.
Sorry for the essay, I just wanted to be thorough. I hope this clears things up at least a little. Thanks for the feedback.
you should fix the fisheye effect
Errant was here