Friday, March 26, 2010

Release 1.8.3 first changes are in

Or at least I'm pretty certain that it will be 1.8.3, although at this stage I don't really know yet. Depending on whether or not it becomes necessary, I might yet cancel 1.8.3 and go straight to 1.9, but time will tell.

Firstly, regarding the DirectX SDK version, it's looking likely that I'll be using the March 2008 release. This gives the same reduced executable size as February 2010, uses the same Direct3D 10 shader compiler (which incidentally is a D3D10 component that works on Windows 2000 and XP) but only has a d3dx9_XX.dll requirement of 37 (February 2010 needs 42).

I've consolidated a lot of the versioning of components into one place and made the whole thing considerably more robust. This wasn't a problem with previous releases, but might become a problem in the future so it makes sense to do it.

Web download has been slightly modified to deal with certain edge cases. These are quite rare and involve things such as your network connection temporarily going down and then coming back up again part way through a download, so they're not crucial, but the code just seems a lot more solid as a result.

Some performance optimizations for complex scenes have been done. Release 1.8.1 and 1.8.2 used an idea (stolen from FitzQuake, muchas gracias) to run R_CullBox on surfaces so that vertex submission to the 3D card can be reduced, but - like FitzQuake - they ran it on every surface. Now what I'm doing is detecting if a surface is in a node or a leaf that actually intersects the frustum and only running it on those surfaces. This cuts the number of R_CullBox checks down quite dramatically, especially in bigger scenes.

I'm also bringing in some code from Quake II in appropriate places. I haven't really done a direct head-to-head comparison, but I'm working on the assumption that the Quake II code - because it's really just an evolution of Quake 1 - contains fixes and improvements that are for the most part warranted (although in some places - such as it's handling of dynamic lightmaps - that's clearly not the case). This is really just going to affect certain aspects of setup for the renderer, optimization of math routines, some inline asm, and so on; I have no intention of making any physics or other gameplay-affecting changes.

The next major change will be interpolation. DirectQ's current interpolation code is fundamentally f--ked. It was derived from the original QER tutorial and patched over the intervening years in various incarnations of MHQuake to deal with edge cases where it broke down (which were unfortunately all too frequent). It works after a fashion but is very nasty and fragile. This will be a 2 step process, with step 1 being to completely gut the current code, then step 2 will be to bring on something nicer and cleaner (and therefore more maintainable).

That's all for now but there will be more. Stay tuned.

0 comments: