Lower resolutions should generate a lower number of count cycles in comparison to spancount cycles. Is it also slower at higher resolutions?
And on a side note, that stippled version I've posted above is broken at the remainder ( if (spancount > 0) ) part.
Drawspans optimization in C for software Quake
Re: Drawspans optimization in C for software Quake
While working on something else, I've found out that bbextents and bbextentt are always the same for turbulent surfaces. So, all instances of them in the water drawing code can be replaced with this macro:
But all the bbextents and bbextentt checks can probably be removed completely, because since turbulent surfaces uses tiled power-of-two textures, bitmasking the texel location with &63 at drawing time can take care of that.
Code: Select all
#define BBEXTENT ((16384 << 16) - 1) // 16384 = 64 << 8 // -1 (-epsilon) so we never wander off the edge of the texture
Re: Drawspans optimization in C for software Quake
Negative indexes are really bad for stippling and for dithering, because they screw up bit parity consistency (*pdest&1).
My current code uses positive indexes for everything.
My current code uses positive indexes for everything.