K, so when we want to create a 3D environment, we need to have some way to store the world as data.  if we wanted, we could store every coordinate of every triangle that makes up the walls and floor and objects.  BUT, since we want to be as memory efficient as possible, we will store the world as a simple matrix.  The world well be made up of a series of blocks that lay on a grid.  A 1 in the matrix might represent a block, and a zero might represent an empty space:

[1,1,1,1,1,1,1,1]
[1,0,0,0,0,0,0,1]
[1,0,0,0,0,0,0,1]
[1,1,1,1,1,1,1,1]
 
Now, in order to render the image on screen, we need to consider how it will look.  There are 96 pixels from left to right, and that is 96 times we need to decide what kind of column to draw (remember, every pixel in a single column is responding to the same distance, so we don't have to go pixel by pixel, only column by column)

If we consider a view of a wall, we can see the farther it gets away, the smaller it gets.  The actual formula is aparentHeight = Arctan(ActualHeight/Distance) , but this is almost exactly equal to aparentHeight = ActualHeight/Distance, and this way is faster.

So in each column of pixels, we will draw a single slice of wall that is a certain distance away.  We have the formula, now all we need is the distance.  This is where the raycasting comes in.

We are at a certain position, and we are facing a certain direction.  In order to find the distance in front of us until we hit a wall, we just need to move us forward until we hit a wall.  You can then do this many more times at many slightly different angles to get all the distances you need (96).

It is then a simple matter to use your information and the formulas to create an amazing, texterless wall!  Textures are MUCH harder, and will be the subject of another lesson if you are still confused.

Hope that helped!  I made a raycasting game in java a while back, so I know a thing or too 

No prob, Hope you get it working!

well, the trickiest part is finding your offset in the picture in the first place, and then scaling the image (Assuming that your writing this for a TI and you are writing your own scale function)

Ah, you did your casting that way.  I was writing mine in java, so i was a bit lazy and just incremented the ray by .02*Unit Vector every time.  Unfortunately that menas it didn't get the exact intersection at the wall, and so both the x offset and the y offset were large enough so that it got confused between the two.

Your way is a lot better, but after programing in TI basic for a while, i was a bit overwhelmed with the speed

"You mean I can cast 300 rays, do 3000 trig functions, increment each ray thousands of times, and still get 60 frames per second!?!?!?"

Ah, you did your casting that way.  I was writing mine in java, so i was a bit lazy and just incremented the ray by .02*Unit Vector every time.  Unfortunately that menas it didn't get the exact intersection at the wall, and so both the x offset and the y offset were large enough so that it got confused between the two.

Your way is a lot better, but after programing in TI basic for a while, i was a bit overwhelmed with the speed

"You mean I can cast 300 rays, do 3000 trig functions, increment each ray thousands of times, and still get 60 frames per second!?!?!?"

Yeah, I know what you mean, haha.

@DJ_Omnimaga: Very true.