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).
Even though the resource-unstable branch still desperately needs my attention, I promised myself that I’d start work on the XSI exporter this week. I spent a lot of time reading the SDK docs and basically feeling my way around, and whilst it takes a bit of getting used to (like any new API), I’m pleased with what I’ve seen. I already figured out the various entry points, got a plugin loading, and sorted out how to write a custom dialog pane.
Now that the resource-unstable branch is now finally 100% compiling, I’m busy testing and fixing bugs which have gone undetected while I’ve been working on this for the past 6 weeks. It’s slow going (there were a lot of changes after all), but it’s gratifying to finally have something to run again! I hope to merge the branch into the head as soon as I can. I have, however, allocated some time over the next couple of days to work on the XSI exporter, and I’m keen to stick to that, much as I’d like to carry on bashing.
I’ve started unit testing the new base facilities I’ve added in resource-unstable since OgreMain is now building there. I’m using CppUnit to document the tests this time, since the tests I’m doing are internal in nature and don’t have the added complexity of having to check a visual result. I’ve had a really annoying issue though - I’ve had to rebuild a lot of the dependencies (zlib, freetype, now zziplib) and I started to get really odd random crashes inside basic tools like _fstat and _lseek (which zziplib was using).