Perspective Correction Optimizations (Patreon)

Since I'm still unable to figure out how to implement the general-case perspective correction optimizations I have in mind, I've decided to implement a special case optimization to skip perspective correction almost entirely in horizontal surfaces (e.g. floors and ceilings).

After implementing this special case optimization in the rigid BSP surface rasterizer (and in the BSP depth rasterizer, which is used for sky surfaces, hard-depth opaque rigid surfaces and hard-depth opaque liquids), the framerate in vanilla Quake improved a lot more than expected. Most of the shareware episode can now be played at nearly 60 fps in my computer, which I didn't expect to happen.

Nearly all points of low framerates (mid-20s) in vanilla Quake are in areas with liquids now. So, now I'm implementing similar special case optimizations for liquids, which should help significantly since most liquid surfaces in vanilla Quake are horizontal (except portals, but most portal surfaces are small):

• Lightmapping on horizontal liquids will be as fast as on horizontal rigid surfaces.

• Soft depth can be partially optimized (3 sums and 5 divisions can be eliminated from its perspective correction), but it still needs perspective correction to generate the wavy shorelines.

• Texture mapping may be optimized a little, eliminating 3 multiplications during perspective correction, but it still needs perspective correction to generate the turbulence.

Besides those big optimizations for horizontal liquid surfaces, there are other 3 special cases that can also be optimized in melt-mapped liquids.

Let's see how far I get with these. Having a really good performance improvement over the last public release (version 0.10.0) is one of my aims for the next public release.

With all these optimizations implemented, most performance issues should be in maps without visibility data, maps with few horizontal surfaces, maps with too many small polygons, maps with lots of overdraw effects, and maps with more than 5 monsters visible at once (specially ones with MD5 models, which are much slower to render).