• Advertisement

Archived

This topic is now archived and is closed to further replies.

How to speed up textures in a wolf3d engine

This topic is 5615 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

In a wolf3d style raycaster, I let it draw textures. First it casts the ray for a vertical stripe on screen until it hits a wall, then it calculates the height of the piece of wall to be drawn on screen (= lineHeight), and derives drawHeight from lineHeight (drawHeight is equal to lineHeight, except if lineHeight is higher than the computer screen), and what texture that wall has. Then it does the following:
  
  for(int y =-drawHeight/2;y< drawHeight/2;y++)
  {
      color = texture[texNum][texStripe][int((2*y+lineHeight)*32/lineHeight)];
      pset(x,y+h/2,color);
  }
   
btw h is the height of the screen and pset is of course the pixel place function. This goes pretty slow (I know that this part of the code is doing it, I isolated it). How can I speed this up? How is it done in the game Wolf3D that can do this on a 286? edit= source tags got problems with html symbols... < < < [edited by - lode on December 3, 2002 9:39:17 PM]

Share this post


Link to post
Share on other sites
Advertisement
Well if you are sure that loop is what is taking all your time you can optimize somewhat further.

My suspicion though is your pset function. I have no idea what that is or how it works. If it''s hooking Windows GDI or something in there that is probably your main problem.

In Wolf3D alot of that code was optimized in assembler. You could rewrite that code in assembler, break out the constant multiplcations with shifts instead, and do a few trickety tricks from there like inlining the pset function to write directly to video and such in assembler macro. Depends on what system you are using. If it''s DOS it''s a piece of cake.

Share this post


Link to post
Share on other sites
Oh yes, it's not the pset function It's fastest way possible to draw pixels that I know if in SDL, it directly sets the pixel value to video card memory without any check or whatever, and it's inline, and the it can draw a 1024*768 screen @ 60 FPS if there are no further calculations.

I think the color = texture[texNum][texStripe][int((2*y+lineHeight)*32/lineHeight)]; is doing it but I don't know how to replace it...

It isn't dramaticly slow, but the point is that the closer I'm to a wall, the slower it gets, while you'd think that a raycaster should go slower when going further away from a wall because the rays are longer.

[edited by - lode on December 3, 2002 9:41:13 PM]

Share this post


Link to post
Share on other sites
My suggestions...

Precalculate (h/2)
Precalculate (drawHeight/2)
Precalculate (32/lineHeight)
Precalculate texture[texNum][texStripe][0], offset from there

Do as little math in each iteration as possible... if you can calculate once a constant increment for ((2*y+lineHeight)*(32/lineHeight)), you can save yourself a lot of repeated calculations. Even on a superfast computer, things like this can bog it into the dirt.

If you can get something like this...


  
/* Precalc everything */
for ( y = top; y < bottom; y++ )
{
color = texAddr; texAddr += texIncr;
pset(x,y,color);
}


... then you are writing like the masters of yesteryear.

Share this post


Link to post
Share on other sites
You might also want to check that you''re drawing each vertical scanline (aka column) only once... when you get close to a wall, you might be accidentally drawing each column two or three times.

Or, worse, it might be simply because all your textures are in RAM, not VRAM. On an AGP card that shouldn''t matter too much, but anywhere else...

Share this post


Link to post
Share on other sites

  • Advertisement