I need to know the techniques behind rendering sprites in a raycaster(ie. badies). I'm going to look at some source code soon, but I'm posting here to see if I can get an accual explaination instead of blindly following some source code, heh.

BTW I want a technique that is flexible, speed is nice, but flexibility it cool

Ok, so I just translate the center of all visible baddies and draw them, eh? But how do I know how wide to draw them, same translation? Also, will a baddie have any slant to the top/bottem of it cause it is always facing you(billboard) or does it slant. If it doesn't slant then I don't have to draw it slice by slice, just a simple blit >8)

Yea, I already know that translation equation like the back of my hand, heh. Good ole similar triangles

EDIT Response to your edit....Oh... EDIT

I've been wondering something about the prevelance of this "raycasting" technique (I really hate that name, as it sounds too much like a real rendering technique, raytracing) around here lately.

Why?

In terms of presenting a 3D world, a scan converter is, not only much better at it, but (when hardware-accelerated) faster as well. It is also more artistically free. You aren't stuck with Doom-like creations; you can make much more interesting, dynamic environments.

So, if you're interested in doing something vaguely 3-dimensional, why not go all the way?

As I'm sure you know already:

But a raycaster is a scan converter - it just so happens that the walls are converted to vertical rather than horizontal scanlines, which means that, per pixel, you can use affine scaling and still get correct perspective, and by thinking slightly more in trig than in linear algebra you can save several more calculations.

It was, I guess, but it was using trig. Nevertheless, everything is changing now that I've moved on to the platform I actually want to target - low end mobile phones. I've switched to a style much more like ray casting (but still with portals) which has the advantage of being very good at guessing which wall a particular ray will hit first time, and very good at guessing which wall it must have hit if not.

That version is not yet fully optimised.

To the original poster: is your raycaster simple Wolfenstein style, same height walls? If so what you effectively do is keep a 1d z-buffer. Keep a record of the heights of every sliver, convert your sprite to screen co-ordinates and draw (as a first implementation) sliver by sliver only where the sprite slivers are larger than the wall slivers.

You could, if you wanted to do it the trig way, use atan2 and then subtract the angle your viewer is actually rotated at.

Alternatively, and probably more speedily, you could use some linear algebra. Use the dot product to project the vector from the viewer to the enemy into screen space, adjust that for your FOV (multiply x by z multiplied by some scalar) then do a standard issue perspective transformation.

You can get a full Doom port for the Nokia series 60 line with bilinear filtering... but we don't all want one of those ugly things.

True, 3d hardware has come a long way in increasing the speed at which you can draw 3d objects, but it also came for a price: complexity. No offense, but open-gl really bugs me because you have to enter like 35 lines of code to make one stupid triangle popup on the screen. Not only that, raycasters are more hardware independant, because they don't depend on a platform that has opengl accel.

True, they could always implement an opengl accelerated renderer that the user could choose from, I guess...

Um... how much of them 35 lines are for setting up the hardware for your program (like the install_* functions in Allegro)?

The windows crap is the same as the install_* functions in Allegro (and the set_gfx_mode() as well)

The Windows crap is overhead that you should be keeping on hand for whatever purpose so you don't have to retype it. NeHe hands out that base code for a reason, y'know

And how many lines does it take to write a ray-caster that is decently well-optimized? I'm pretty sure it's more than 35.

You aren't supposed to understand it. Just recognize that it is required to produce a window. You copy and paste it as needed. You can use Allegro just fine without fully understand what all the initialization functions are.

Stretch-blit. That's the long and short of it. You stretch-blit the sprite such that it appears to be on the ground and remains, perspective-wise, at a particular height.

Yes! Going along witht the original post, visit the "Getting an angle" thread, go all the way to the last post where I have done it!! With lots of help from 23yrold3yrold! I attached a screenshot.

Me=8-)
aybabtu eyes his sig

Oooh! I have a teensy problem...it seems that my object drawing method fails for I think 180 degrees! Objects disappear! Look:
{"name":"wolf.gif","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/6\/567fd195c6b6f49ac04e82d333248f2c.gif","w":320,"h":320,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/6\/567fd195c6b6f49ac04e82d333248f2c"}
There's supposed to be 3 barrels there. The one on the far left does appear, but you have to turn a bit to the left! It should be visible in this shot, if I move about 5 degrees to the left, it shows up... WTF?

I know it's not the right forum:-X, but here's my code:

/*
 int odistance=distancefrom player to object
 float oangle is angle between player and object
 int odisplayx=where to draw on screen
 int obj_x,objy=object's coordinates
 */
odistance=(int)(DIV_VIEW/sqrt((obj_x<i>-px)*(obj_x<i>-px)+(obj_y<i>-py)*(obj_y<i>-py)));
   oangle=RAD_TO_DEG(atan2(obj_y<i>-py,obj_x<i>-px))-pa;
   if(oangle<0) oangle+=359;
   if(oangle>359) oangle-=359;
   odisplayx=(int)(oangle/0.1875)+(SCREEN_W/2);
   stretch_sprite(front,object[0],odisplayx-odistance/2,100-odistance/2,odistance,odistance);