I'm developing a raycaster similar to that used in NovaLogic games like Comanche but this applies to raycasters in general. How did nova display the roll of the helicopter? I came up with an algorithm that takes yaw and pitch into account but not roll. This is my perspective calculation:

perspectiveHeight = ((height + cameraheight) / raylength * viewPlaneDist - pitch);

The yaw is done easily by rotating the rays that are cast into the scene and the pitch is added into this equation. Like Doom and Wolfenstein 3D my raycaster is technically two dimensional so I cannot simply rotate my rays to induce roll. The only way I could think of is literally rotating the final image but I would need to cast rays outside the scene for that. How was it Done in Comanche? How did other games do it? Any input would be much appreciated.

Well I doubt a game like comanche uses 2d marching. to obtain pitch yaw and roll you must pass 3D rays through a view camera matrix. the original rays always point towards Z and then the view camera matrix represents the helicopter orientation and position as well if it is 4x4.

Well I doubt a game like comanche uses 2d marching. to obtain pitch yaw and roll you must pass 3D rays through a view camera matrix. the original rays always point towards Z and then the view camera matrix represents the helicopter orientation and position as well if it is 4x4.

I wouldn't be suprised if comanche did use 2d rays. I've achieved amazing results with it, I only need to cast as many rays as there are columns of pixels. I'm not gonna change the algorithm completely just so that I can roll the camera. If absolutely necessary I'll just rotate the final image. Anyway here's a screenshot of my raycaster (using a map from comanche) just to show how viable the approach is:

[attachment=13102:raycastershot.png]

anyways does anyone know how to do this in a 2.5D raycaster like wolfenstein?

So I just don't understand anything about how the rendering is done with your technique then. one ray per column ? how do you fill the column then, does not one ray = one pixel ? Do you have some kind of "ray to heightmap" intersection routine to render the terrain ? (like dichotomy or cone-based...?)

what is 2d, the scanning or the actual ray information ?

(I mean, a 3d ray bears 2 vectors of 3 scalars, a starting point and a direction, so your 2d rays stores what ? an origin pixel and a 2d direction ?)

about sheering, if a rotation were to be "simulated" by sheering my eyes would surely bleed. Can you just not do a space trick that would effectively make the rotation ?

Like when you create your rays, you trick the ray creation from the original data by rotating your origin space ? (if the pixels are your origin space when you scan the columns, then after extracting the coordinates (eg from loop indices), for your pixel, you just rotate them in place, and the following calculations will be space-tricked.)

edit: from this article https://en.wikipedia.org/wiki/Ray_casting, I start to vaguely see what was I missing in my mental conception of what you called ray casting. the folling of columns seems to be kind of retro-fed from the highest pixel, instead of casting one ray per pixel. But that seems very specific to games that will have only one or two objects to draw per column. And the terrain case actually seems very complex. If I believe my knowledge of how shadowing is done in parallax occlusion mapping, then its a quite involved algorithm and I fail to see how this could run real time. There must be something I am missing about heightmap rendering techniques. I feel this something must lay near the 2d-thingie concept that I can't quite grasp as well. Rotations would be obvious with 3d rays, and would not even deserve a question here, therefore my very simple first answer about the view matrix.

Might it be possible to do raycasting along vertical lines but then setting the resulting pixels along diagonal lines using Bresenham's algorithm?

The Bresenham pattern would be the same for all lines, so there should be no holes. It could also be stored and reused. The angle of the lines should be the inverse of the actual roll. You also need a height offset, otherwise you just get a skewed image. I guess there might be some artifacts due to the Aliasing in the Bresenham, but that should be acceptable.