So I wasn't sure if this should go in advanced topics or not, seeing how most of those are about modding Scratch and such, so I put it here. Here's my idea:
Instead of scanning from the person to the wall, it scans from the wall, to the person. So:
1 1 1 1 1 1 1 1 1 1
1 0 0 0 1 0 0 1 0 1
1 0 1 0 0 0 1 1 0 1
1 0 0 0 0 0 0 0 0 1
1 1 0 1 1 1 0 1 0 1
1 0 0 0 1 0 0 1 0 1
1 0 1 0 0 0 1 1 0 1
1 0 1 0 1 0 1 0 0 1
1 0 0 0 0 0 0 0 0 1
1 1 1 1 1 1 1 1 1 1
So if this is your map (1's are walls), 10 sprites scans from 10 spots each (or 20 from 5), testing first if they are on the corner of a wall, then if they're in the field of view, and finally if they ever would be stopped by another wall. If they pass all of those tests, they add a rather exact distance and display x position to two lists to be drawn. After all of those calculations are done, two rays are sent out to the extremes of the field of view so that the walls can be drawn to the very edges of the screen at all times.
The hard part is making sure it draws the right sections of walls (i.e. don't connection 2 corners that shouldn't be connected.
Hopefully I'll be able to post an early version tomorrow to try and help explain what I mean.
Please give me suggestions on methods for drawing the right walls and anything else you can think of.
Offline
cygene wrote:
Wouldn't that be slower than the traditional method, though, as you would have much more tests than the normal way?
Not necessarily. I would have about 10-20 sprites that each have about 4-8 locations to scan from. I can set it up so that I know every corner it has to scan from instead of it testing all 81 possible locations. Also, it's very fast to test if it's in the FOV, so if it's not, that one is skipped. It can also determine distances faster than the old method, and much more accurately seeing as how it finds the total distance before it even scans. I still have to figure out a couple of things with it, but if I do, it should look a lot better.
Offline
I didn't understand quite well... Why do the 10 sprites test whether they're on a corner? The FOV test is pretty obvious, but why the corner?
I never really understood raycasters at all though Still it's pretty impressive that this kinda stuff is being done in Scratch. Feels like we've progressed a lot since '07.
Offline
Oh, so you only test the corners of a wall instead of every column, and just fill in the gaps between corners? That is ingenious! That would be much faster as it only calculates distances on corners (approx 5 calculations per screen) instead of each column (approx 60 columns per screen). Interesting approach. Mind if I use that sometime?
Offline
cygene wrote:
Oh, so you only test the corners of a wall instead of every column, and just fill in the gaps between corners? That is ingenious! That would be much faster as it only calculates distances on corners (approx 5 calculations per screen) instead of each column (approx 60 columns per screen). Interesting approach. Mind if I use that sometime?
Nope, not at all.
Offline
cygene wrote:
What's your algorithm for testing whether a wall in inside FOV?
It finds the direction it would point in to point towards the player by using atan(x-x/y-y) and then compares it to the direction of the player +-30.
Offline
AtomicBawm3 wrote:
cygene wrote:
What's your algorithm for testing whether a wall in inside FOV?
It finds the direction it would point in to point towards the player by using atan(x-x/y-y) and then compares it to the direction of the player +-30.
I'm using the exact same algorithm! Finds slope, then converts it to degrees. Of course you'll have to manually convert the 91-269 degrees, since its slope is exactly the same as the slopes of 0-89 and 271-359. Also, convert the undefined and 0 slopes to 0, 90, 180 and 270 degrees.
Offline
cygene wrote:
AtomicBawm3 wrote:
cygene wrote:
What's your algorithm for testing whether a wall in inside FOV?
It finds the direction it would point in to point towards the player by using atan(x-x/y-y) and then compares it to the direction of the player +-30.
I'm using the exact same algorithm! Finds slope, then converts it to degrees. Of course you'll have to manually convert the 91-269 degrees, since its slope is exactly the same as the slopes of 0-89 and 271-359. Also, convert the undefined and 0 slopes to 0, 90, 180 and 270 degrees.
Nope, you don't have to do it manually. Use this:
if y<playery:
set direction to atan(x-playerx/y-playery)
else
set direction to atan(x-playerx/y-playery)-180
This makes sure it's always right. If you don't understand, look at my trig tutorial, it explains it more in depth.
Last edited by AtomicBawm3 (2011-08-10 14:58:24)
Offline
AtomicBawm3 wrote:
cygene wrote:
AtomicBawm3 wrote:
It finds the direction it would point in to point towards the player by using atan(x-x/y-y) and then compares it to the direction of the player +-30.I'm using the exact same algorithm! Finds slope, then converts it to degrees. Of course you'll have to manually convert the 91-269 degrees, since its slope is exactly the same as the slopes of 0-89 and 271-359. Also, convert the undefined and 0 slopes to 0, 90, 180 and 270 degrees.
Nope, you don't have to do it manually. Use this:
if y<playery:
set direction to atan(x-playerx/y-playery)
else
set direction to atan(x-playerx/y-playery)-180
This makes sure it's always right. If you don't understand, look at my trig tutorial, it explains it more in depth.
That IS what I'm doing. By manually, i meant that you need a separate script to fix it.
Offline
cygene wrote:
Do you have a fix for a wall being in front of a wall? I mean when the wall is not continuous. Eg: there is a pillar in front of a wall, make the wall behind the pillar not be rendered.
That was the problem I was trying to fix.
Offline