Gah, what a day. To start with, Sourceforge CVS is currently performing at the speed of an apathetic slug towing a family saloon full of other slugs, said family having also forgotten to fully disengage the handbrake. 45 minutes for a ‘cvs up’ is not my idea of enjoyment. Secondly, I’d been trying to test what I thought was a useful update to SharedPtr whicih simplified a few things and added weak pointer support, all through templates, but whilst it compiles fine I get the weirdest runtime problems, such as hangs deep in STLport.
Well, I finally decided to shelve the lost device handling since it’s mostly working except for the couple of crazy little things left over which are utterly baffling. D3D’s return codes say everything is peachy, it’s debug runtime on full diagnostic mode continues to make reassuring cooing noises, yet deep in it’s innards it’s choosing to completely ignore some render state changes (namely those that implement transparency) after the device restore, no doubt whilst cackling wildly to itself (and perhaps rocking backwards and forwards and drooling a little).
Well, I have lost devices restoring in many situations now - I still have to sort out a remote debug session because fullscreen restores still error sometimes and they’re kind of hard to track when your machine is locked solid (now I wish I had dualhead!). But now I have the most bizarre problem - after restoring the device, on this machine the ‘scene blend’ factors, ie transparency, no longer work.
I managed to polish off a loading screen example at the weekend, Demo_BSP now reports progress as it loads (which is good, because if you hook it up to Quake3Arena’s pak0.pk3, parsing all those shader scripts can take a little while!). It’s wrapped up in a little ExampleLoadingBar class that people can re-use relatively easily in their own apps, or of course simply rip off - like the rest of the example code it’s written under a a very lenient license.
The last week has been something of a mixed bag; I’ve been going through lots of patches for Hastur because they were mounting up, and the result (plus all the other fixes for the past 6 weeks) is today’s release of 0.15.2. This _should_ be the last Hastur release before the mighty Azathoth, which I can finally get back to working on. My overlay issues while trying to get a loading screen working are first on the ‘to stamp on repeatedly until it gives in’ list.
You would have thought that by working hard at something, your TODO list would get shorter. Oddly, on my plane of existence it doesn’t seem to work that way. Ogre 1.0 (Azathoth) is still well in development and getting more advanced / stable by the day, but things just seem to keep crawling out of the woodwork. We’re still getting a steady stream of Hastur patches too, which take time to evaluate.
I had a very frustrating day today. Yesterday went pretty well; I got a little distracted from what was going to be progress bar work by implementing specialised ray queries on BspSceneManager, but since that’s been long overdue and it worked so well I could live with that. Plus I fixed a few bugs and got the interfaces for progress reporting for world geometry down, so not too bad. This morning I thought I’d slap in my new 250Gb SATA drive since I’ve been running low on space recently.
Well, Xmas is well and truly over, I now have a shedload of new DVDs to watch (for me, probably a years worth), and a couple of GameCube games to drag me away from the PC from time to time. A friend got me the Midway Arcade Treasures, featuring lots of games I used to misspend my youth on in the arcades. And they still play remarkably well. Defender and Robotron 2084 still rock my world, besides being hard as titanium nails fired through a gauss rifle.
Finally! After 6 weeks of work, the resource-unstable branch has been merged into the CVS head. It’s been a hell of a long road, and I can’t say I’m surprised at the size of the entries in cvs mailing list after committing, I really did change a hell of a lot. There are still some issues - the changes I made to particle systems aren’t quite working yet for one, and I haven’t been able to test everything yet.
With the exception of a couple of limitations, which I’ve had to ask about in the XSI SDK forums, mesh exporting from XSI is now working. The limitations are that only one set of UVs is supported (because of the slightly odd way you have to get multiple UVs from XSI and it seemingly not being indexable with the triangle data I have to use), and that defining sub-areas of a PolygonMesh using poly clusters with which to change materials is not supported - you have to change materials with multiple PolygonMesh objects instead (which can be arbitrarily nested anyway).