crap

sory

and by green, almost teal, the two blocks, one at the top, and one at the bottom...

Um...did you run the binary or compile the code? The binary is a DOS binary (DJGPP, remember?), so if you have winXP or 2000 or something, it probly won't work.:P

Chris, Can you explain what you're doing in DrawSlice? I can't figure it out (my fault )
I got similar fps on my system with just

void DrawSlice(BITMAP* buffer, BITMAP* texture, int xoff, int x, int y, int tall)
{
  stretch_blit(texture, buffer, xoff, 0, 1, 64, x, y, 1,tall);
}

but I may not have compiled yours with the correct optimisation. Also it rotated the textures by 90 compared to yours.

Pete

I get better fps my way over using stretch_blit() (about 50% better). The rotation is because I treat rows like columns in DrawSlice() due to Bob's suggestion. Otherwise I'm doing evil cache missing or something

Anyway, DrawSlice is based off my Bresenham line drawing code to step through the column pixels and get the right texture pixel to draw. It's not too difficult to figure out, methinks. If it still confuses you, post in my "Math help, please" thread since this one's getting a little long

Trezker: Yes, I should look at your code closer; thanks for reminding me

I took the shading out of that code, TF. I don't see that for the life of me when I run it. Can't duplicate the error at all. Are you using my gray stone texture?

what grey stone texture?

Hey...so am I! I know my casting method is far from the best, but 50-64 FPS is fine by me. Wow...400? You're useing the "right" method, huh? I'm gonna check out your source...

Geez! That's crazy! It runs on both my old 586 (Win95) and my family's computer (Win98SE). Crazy...

Holy CRAP! A 30 frame jump! Wow...didn't think I'd see the day...well okay! If it's becomming a problem, I'll put a limit...! YAY!

I think I've coaxed another frame per second out of it. In my raycasting while loop, I had it testing to see if the_x and the_y were hitting a tile, but, if they do, the inside of the loop catches it and breaks out of it. So, I eliminated 2 divisions (well, shifts), and a usless conditional...it runs a little bit faster...I think.

EDIT:
How accurate should PI be? I mean, after the first 10 decimal places...it should be pretty usless, right? Or should I have as many as I can?

Heheheheh.
3*10=30
3.14*10=31.4
-OR-
3*100=300
3.14*100=314
Quite a difference...;):P

EDIT: How long with Matthew let a thread go to...I see that Bruce Perry's "My avatar" thread is well over 200...

EDIT2:

Yes! How dare you insult teh almighty PI!? Round down to 3...bah!

Wolfenstein uses the broad equivalent of compiled sprites for every possible sized slice of every possible texture. But I'd dare imagine it uses some super-clever assumptions about run length stuff which Allegro does not with its compiled sprites - or else it couldn't possibly fit all that code into memory.

How many different textures does the average Wolfenstein level have?

And has this thread yet discussed the ways of inserting sprites and doors into the world?

Well, a very primative technique of drawing a baddie would be to:
1) keep an array of distances to walls
2) Use the x/z, y/z formula to determine the sprite's midpoint location, and the size/z formula to determine how much to scale it -- to do this, of course, you need to rotate the x,y,z so z+ or z- is away from you (pending left or right hand coordinate system)
3) Draw the sprite slice by slice, comparing its z to the wall array's z for each slice
4) For each slice you draw, fill in the corresponding spot in the wall array with the sprite's z so that later sprite draws layer correctly.

Of course, this technique is designed with same-height enemies in mind, and cannot have a taller enemy peeking over a wall or another baddie. But then, it's probably good enough for your average wolfenstein clone.

I get around 70 fps with 1 frameskip and over 200 fps with 5 frameskips, with and without vync. 'Course, I'm on an Athlon 1800+