I tried some tables and such, but it didn't make a difference. It's because of allegro stepping in to help speed up sin&cos with it's tables. Very nice of it, really.:P

EDIT: Screw allegro's "help"!! I #included <math.h>, then made a macro to convert degrees (0-360) to radians, and used the sin & cos functions without allegro's help. I got the idea after I RTFM and it said that it's sin and cos tables weren't very accurate. Well, guess what? IT'S BEAUTIFUL!!!! Here's a screenie:
[url http://www.angelfire.com/empire/jonhome/wolf3.gif]Image...[/url]
Here's the latest code:
(I know I overuse the DEG_TO_RAD() macro, but it's easier this way. Also, notice the DrawSlice() function, made by 23, and it gives me an extra FPS. Also, I used those shift operators to do division, and that gave me another FPS! Also, you can now control it by the mouse...controls are shown...)

Pretty kewl...;D

I just uploaded the pic, so you should see it now...sorry!

Yup. 1 pixel! And the textures look way nicer, too! (Notice the left-most wall in this one, then compare it to the "NO DISTORTIONS" screenshot...pretty nice!)

Alright...I'll try that rotate 90 degrees thing.

Yep

1) Basically, by rounding to the nearest 64 for one coordinate, then by using the tangent of the angle to get the other coordinate.
2) Because stepping through them seperately is a lot easier than going through them together. Look at how easy it is to just add twice every loop. Can only do that if they're checked seperately.

I still don't quite understand tan() enough to explain it. If it's not in amarillion's tutorial, it should be

Going slightly off topic into the 'not raycasting' ideas I posted earlier, I've come up with a knockup of such an implementation (see attachment for code & screenshot) and am convinced that it is a 'better than raycasting' implementation. The technique uses a combination of the following:

- front to back (zero overdraw) portal based rendering
- one divide per column texture mapping (same as normal ray casting)

The FPS doesn't seem to be the astronomic figure I'd expected, but to put things in perspective, here are the top four time consuming functions from a profile build:

        Func          Func+Child           Hit
        Time   %         Time      %      Count  Function
---------------------------------------------------------
    2471.277  33.0     2471.277  33.0      686 _rectfill (alld40.dll)
     944.485  12.6     1258.176  16.8   109713 DrawSlither(struct BITMAP *,struct Texture *,int,int,int,int) (main.obj)
     774.079  10.3     1192.259  15.9   589954 _fmul (main.obj)
     740.479   9.9     2330.742  31.1     1904 AddWall(struct Wall *,unsigned int,long,long,int,int) (main.obj)

So, the bottleneck is clearly video memory access (i.e. drawing, not calculating), which is exactly the same cost as raycasting. Therefore I am confident that with properly optimised drawing code the same sorts of frame rates as ray casting could be seen.

With respect to fmul versus AddWall, fmul is used four times per wall (unless the wall is a reverse face - then just twice) and a further three times per slither if that slither actually appears on the screen. For slithers which do not appear on screen due to being obscured, no fmuls will usually be performed, however for areas where the wall would appear on screen were it longer (and retained the same orientation), one fmul will be performed per slither.

I know that the display sometimes flickers. I'm not sure if this is a buffer bug I've added or the usual array of incompatibilities between Allegro and Windows 2000.

AddWall becomes substantially faster as the screen fills up. Many more sectors would not substantially increase calculation costs.

A screenshot is only attached as I couldn't find anywhere to upload it in order to show it inline. Similarly Allegro.cc would not let me post the code inline due to length.

Yeah, textures are pretty easy. Just use different numbers in the array

I'm going to add that other stuff too, but not until I've gotten rid of those texture problems. I'll keep that in the other thread though. Until then, it's back to my game ...

Guess I'll check out TH's code too

What's this now? What does it do that that site doesn't teach?

It's that TICL thing that Carrus posted. It doesn't really teach anything new. But, it's got the wolfenstein textures, and the brown-suited enemies from wolfenstein.

I tried my hand at getting that better way to cast the rays to work...of course it didn't...oh well. I just can't get it to work. I don't even know if I want to get it to work. To be honest, 23, that bug in yours, which is probly caused by the tangent or something, makes that method very unappealing. Maybe I can be enlightened from that java source code...idunno. But, for now, I can make the detail level adjustable. Basically, I can multiply teh x_inc and y_inc, and distance by a number, which makes it go much faster. Of course, you lose accuracy, but even when you multiply it by 5, you can get more than 10 more fps, and the output is still acceptable. Some of the smaller lines and details are lost somewhat, but it's not a problem. I'll just have the detail level adjustable.

TH: Could you compile it into a binary? My DJGPP complains about MANY "errors". I tried fixing some, but I just gave up. How smooth is it? Would you think that you were in a raycaster when you're running it? What is a 2D portal engine?

Hey...I think I should put depth shading in...how should I do it? Use a blending function or something? If so, I've never used one before...are they slow?

TH, I think the word you're looking for is sliver, not slither.

aybabtu: nice textures! The art for Wolfenstein is a lot nicer than I had thought it was... as for lighting, it depends on whether you're using 8-bit colour or hi-colour/true-colour modes. If you're using 8-bit colour, you have to use palette tricks of some sort, and the fastest way is to use a lookup table. If you're using a higher colour depth, you use a lighting function... which are you using?

23:'for'loop initial declaration used outside C99 mode

you still checking the level[] boundary? use getpixel in Mypost!:P
and plz shorten your code or Attach it! your codebox is now 9.9k! sp4mm3r!;)

and test the FPS yourself:

while(!key[KEY_ESC])
{if(key[KEY_1])mode=0;if(key[KEY_2])mode=1;
 if(mode) for(i=0;i<H;i++)hline(front,0,i,W,(i<H/2)?MC(133,160,255-i):MC(i,i,i));
 else blit(backdrop,front,0,0,0,0,W,H);

C++ coders care.

Hell yes! Much faster than getpixel(). What would using getpixel() get me anyway?

Is that why your code has almost 0 whitespace?

And I am testing the fps myself (or was that directed at aybabtu?) ...

Ace: Cool