[General] RayCasting

Post by **CDI** » Thu 17 Aug, 2006 12:20 am

I am looking to make true RayCasting engines in as many languages I know, including BASIC, JavaScript, C (learning it), and finally z80 ASM.

I am looking for detailed help on it, (not those tutorials). It would be best if help was written in somewhat plain english, and chances are I will question everything that I can. psudeocode is best, but chances are I will format this to work in Chipmunk BASIC first (fastest BASIC program for the Mac) and then JavaScript, by then hopefully I would have learned enough C, to make one in TIGCC (or w/e the acryonym is) and begin to make games.

Any help is good, here's what I know already...

RayCasting uses defined things like screen width, to send out "rays" from the players eyes to the walls and objects so you can see them. A ray is "cast" from the player along a grid until it hits 2 walls, then displays the part of the wall that is closer (this is why it is good to have "brick" or "block" walls and is harder to do a DOOM like engine with diffrent angles of walls, and easier to make a W3D game) as a scaled sliver of a bitmap. Then it moved onto the next ray, so if my screen is 90px wide, then I need to cast 90 rays (or however many rays is needed, here the player sees 90degrees, I can always be nifty and make the view narrow as the player moves faster (like when driving) to improve speed). I can simulate looking up and down, by moving the player's viewpoint along the Y axis up and down.

I also know that there is a good bit of trig involved (I should be able to handle it) as well as a bit to reduce the fact that when looking at a flat wall the engine will make it bulge.

As for hit detection, well since it is a grid I can probably use the same method I use in p3d, where the iPart of the number is what is on the wall, and the fPart of the number is what the wall is (so I can make secret doors, fake doors, broken consoles, and hidden consoles, and whatnot)

I do not know how to place enemies and items on the screen.

Hmm, I think that about covers it. Anyone care to help me?

anykey · Post by **anykey** » Thu 17 Aug, 2006 12:37 am

no, but I'll enjoy seeing the screens as this progresses!

kalan_vod · Post by **kalan_vod** » Sun 20 Aug, 2006 6:08 pm

I know you said not the tuts, but have you checked wiki and the ticalc archives? It just might help a little bit while you wait for one to post here of the information?

coelurus · Post by **coelurus** » Sun 20 Aug, 2006 6:49 pm

Quite a hefty request, this would be a two-person project

There's pseudo-code around for raycasting, I can't see the point of letting somebody write yet another routine doing the same thing.

Enemies and items:
You need to save Z-info for each wall column on the screen to clip sprites. Figuring out where an item should be drawn on the screen is just a bit of transforming around. The simplest, crudest way is to calculate the angle between the POV and the item with arctan and use that angle coupled with the player view angle. Arctan is of course the crude thing here, use trigs to optimize it a bit to only get sin/cos with muls. The distance between the POV and the item would be used for scaling obviously.

Alright, that's about sprites

Post by **benryves** » Mon 21 Aug, 2006 10:49 am

I still haven't written that plain English raycasting 'primer' I had intended on doing. Damn.

RayCasting uses defined things like screen width, to send out "rays" from the players eyes to the walls and objects so you can see them. A ray is "cast" from the player along a grid until it hits 2 walls, then displays the part of the wall that is closer

That two-rayed method can be seen as an optimisation of the basic method, not the basic method itself. The crudest raycaster just sends out a single ray very slowly (in little steps) until it bumps into something. However, if you restrict the world to 2D blocks (like Wolf) you know each intersection with a wall will always be on a "whole" X or Y coordinate, so you can optimise the slow ray by having two fast rays, one stepping through whole X coordinates and one through whole Y coordinates.

I assume you already knew that, though

With your whole thing about the screen width, I tend to make the angle system four times the width of the screen (so if the screen is 256 pixels wide, my range of angles is 0..1023). This would give you a FOV of 90 degrees.

Using fixed-point arithmetic and trig tables makes life significantly easier (not just faster) than using sin()/cos() functions and converting to and from radians all the time.

Floorcasting (texturing floors and ceilings) can be implemented using a simple 2D lookup table (once more!) This table contains depth information (how far away each pixel is) and you can use that along with the angle of each column slice to find out which floor tile and pixel within that tile is visible at that point. That's probably the worst explanation ever. Just ask if you need it clarified.

As for eliminating fish-eye ("wall bulge"), just multiply the final length by 1/cos(angle from centre) to correct it. ("angle from centre" being -45 degrees at the leftmost column, 44 at the right and 0 in the middle).

I take it you're aware of permadi?

Post by **CDI** » Mon 21 Aug, 2006 8:34 pm

mhmm, actually. In the time it took you guys to respond I ripped open the FAT engine and grasped it (and found a QBasic one >.>)

But thanks for the help!

Liazon · Post by **Liazon** » Mon 21 Aug, 2006 11:09 pm

benryves wrote:I still haven't written that plain English raycasting 'primer' I had intended on doing. Damn.

I take it you're aware of permadi?

I wish you'd write one because permadi sounds kinda confusing. I didnt' like it much and couldn't figure out the general idea of raycasting or how to implement it on calc.

So far, all I get out of it is the idea of sending a ray per column of pixel.