The changes in my Xt tree are massive, with considerable effort put into not only cleanup but also performance optimization. Some of the features are dependent on other new features which aren't complete yet, which is why it's taking so long to get the code in SVN. Another problem has just been the bugs in the new code. I don't like to add bugs to SVN, so I try very hard to work out as many of those as I can find before I ever commit new code. I actually had to drop almost half of the new code that I wrote for the Xt tree just so there was less work to do in order to get the rest into SVN quicker.
Both the programmable and fixed rendering paths have changed considerably over last year so it shouldn't come as a surprise that things likely work differently. I also work closely with some testers who not only help me work out new features for general use but also help track down and identify various slowdowns and other performance issues. Through that collaboration I decided to completely rip out and rewrite all of the GLSL code that was in the 10/28 build, so it's 100% new and improved now. Many other things were changed as well, such as state changes, reducing calls and many wasted CPU cycles, as well as a reworking of the fixed rendering pipeline to better streamline it.
Oh, and the other devs do have my code. I have even released it publicly several times (even the 10/28 build had a source code release for Linux users to build from). The devs that ask for it get it, as Bobboau and WMCoolmon have done. But having it and being able to deal with the considerable amount of changes (upwards of 70,000+ lines last time I looked) are two very different things. With that amount of changed code it's generally easier for other devs to simply not deal with a code tree like that and focus only on whats in SVN. I've had a year to slowly get used to the differences, but others don't really have that luxury, so you can't blame anyone else for not releasing builds based on my code.
And so this doesn't keep to the off-topic content...
The FOV isn't in SVN just yet, as has surely been noticed. While testing I discovered several issues that I attributed to the FOV changes, but they turned out not to be related at all. I actually haven't found one single issue that can seriously be attributed to the FOV patch in any way, just old issues that didn't really get noticed before. As a result I removed those non-FOV changes so as not to screw up other stuff with a freaky bug hunt. The only change that I've made to the original patch, other than an extremely minor performance related change, was to put it with proper Cmdline_nohtl checks so as not to mess up cases where we don't actually run with projection (it's just easier to stay with retail in that area for now, even if the FOV patch doesn't appear to hurt anything).
I missed by time window for doing the commit though, and have been working on other bugs. I will get it committed at some point in the near future however, so sorry about the delay Murleen.
