I've attached a .zip with a DOS binary, the source code, and my little texture set. Could you guys test it out and tell me what kind of FPS you get with the "Ray Skip" at 1, and at 5? Use the -/+ butons to change it. It makes it run a lot faster on 5, but you lose detail...I wanna see how fast it runs on ppl's computers.

Goodbytes: I'm using 16bit color. Down with palettes!

J13: That screenshot looks nifty...I kinda like it with the lines on top of the walls!

Fine...I'll download allegro 4 or the newest WIP or something...
Anywayz, here's the latest code:
(Control view with mouse/arrow keys, move with WASD)

[WHOOPS! The post's too big with it...just download the attachment]

As you can see, I've eliminated another call to the cos() function, by using a table to fix the distortion!

EDIT: 23: Words are backwards on my textures only on certain sides of a cube. 2 sides are right, 2 sides are backwards. I tested it with the all powerful NYAH.

Are you going to FPS-test mine?

Good. Then lighting is easy enough... sorta. I guess. Or something. Yeah.

Anyways, if you want to shade based on depth, as if the player has a light on his/her head or whatever, you'll probably want to shade the ceiling and floor as well as the walls. So, you need to darken your floor/ceiling gradient a little as it reaches the horizon.

Then, as for shading the walls, you can probably just subtract a little from the colour components of each pixel based on how far away it is. Allow me to rip some code from FBlend for a minute.

Okay, here's a sort of example program for ya:

This is C++ code, so compile it as so.

The two parts to note are the creation of the light table, and the actual subtractive blending parts, which are commented as important parts numbers one and two, respectively.

Now, credit must go to Bob for actually writing the subtractive blending part in FBlend, which I modified a teensy bit. The rest of the program is my fault.

Actually, I think it works well. Make a small bitmap called src.bmp, compile this, and put them in the same directory, and try it out yourself.

Anyhow, now on to how it works. It's kind of hard to explain... basically, in the subtractive blending part, the color is grabbed from the source bitmap(you should use a faster method than _getpixel16 if possible, btw) and then the individual colour components are separated apart, so where originally the binary representation of the colour looks like this:
OOOOOOOOOOOOOOOORRRRRGGGGGGBBBBB // 16-bit colour on a 32-bit int, 5 bits for red, 6 for green, 5 for blue
it gets transformed to look like this:
OOOOOGGGGGOOOOOORRRRROOOOOOBBBBB // 16-bit colour on a 32-bit int, but spread apart, and 5r5g5b instead of 5r6g5b
The lightlevel[] array is set up to match the above representation for 32 levels of light... for example, lightlevel[31] looks like this:
OOOOO11111OOOOOO11111OOOOOO11111 // 11111 = decimal 31 - for each colour component
Then, the light level is subtracted from the source colour, put back together into the packed 565 format, and drawn onto the destination bitmap. Again, use direct bitmap access instead of _putpixel16.

This is basically the same thing as doing

unsigned int r, g, b, c;
c = _getpixel16(src, x, y);
r = getr16(c); g = getg16(c); b = getb16(c);
r -= distance; g -= distance; b -= distance;
c = makecol16(r, g, b);
_putpixel16(dst, x, y, c);

But hopefully faster.

Finally, remember that since you only have 32 distance values, try to spread them out a little - i.e. you would probably want a slice that's 32 'pixels' away to actually be quite bright. In fact, you can probably map distance in 'tile units' - i.e. with a slice that is 1 tile length away being a distance value of 1.

Hope this helps.

Sory, didnt notice any textures. I compiled and ran a previous version of somebodys and it crashed I was about to report it, but realize that it was because using a NULL bitmap doesn't work to well.

I used my own texture. Just throw a 64x64 truecolor texture in with the executable and you're good to go. Try it with mine; how's it work for you?

I don't have any texture either; I just drew some scribbles in MSPaint

BTW, can anyone help with this little bit of math? The if statement is to skip the offscreen pixels (HUGE fps boost) but it messes up the texture a bit. I've attached a screenshot which demonstrates this ...

See anything wrong with that first half of the function?

Chris: Where's yours? I don't have a compiler here at work (and don't feel like setting one up here)

23: Your code stays over 150 on my computer even near walls, and tends to be >200 ... very nice! I can't really see the glitches you're talking about, though, so I can't really comment on what might be causing them. Perhaps you could post a screenie of a pronounced glitch? (Heh, you could even check miran's screenie module in the early modules submission thread to do it ...). This test result is from using your latest code posted in this thread, which is quite a few posts up, actually, so I guess you may have made progress since then.

EDIT: Gah! I idle a bit and look what happens ... takes me 20 minutes to write this post and to test 23's code and sooo many people have already posted. It's not being beaten ... it's being completely demolished

For reference, to document the worst beating I've seen yet: the last post in this thread when I wrote the above response was TF saying:

23: Stays over 260 with this 1.70GHz machine I have here at work. When not close to a wall, I get around 313.

aybabtu: 2000 don't like DOS apps , so I couldn't test it here.

Will do a test at home on my 600 MHz system (which, I assume because of RAM and other network stuff, run laps around this computer )

Yay! What's your system?

Goodbytes: Thanks...I'll try that stuff out tonight or something...

23: Your new code skips off screen pixels! Yay! Maybe even more FPS!

Miquel: Sorry it's DOS! I don't have MinGW or anything, but it shouldn't be hard to compile...you should just have to stick END_OF_MAIN in there.
On a 600Mhz system...you should get nice numbers. On my 233, I get ~20 frames...and with TF getting 50-60! Ah...life is good.:P

23: darned. well, it seems that must have been a fluke, or only happens in very rare circumstances... but I did see something else thats a bit odd.. hard to explain, just that I found if you're standing right up to a wall, and turn back and forth a bit the colors on the texture move In the attached image, notice the green, almost teal color, now If I use the arrow keys to look side to side, that teal grows and shrinks in size, after a bit of looking left, it totally disapears and the colors underneath takeover. weird.

Athlon 900.