Ok, after further investigation the origin of the .Net 2.0 dependency on binaries created with VC8 Express is becoming clearer. The major change that has occurred in VC8 is that the core C/C++ runtime libraries and standard libraries like STL, MFC, ATL etc are now configured as ‘side-by-side native assemblies’ rather than the usual simple native DLLs. The point of this is to allow version control over shared libraries so that different applications don’t mess each other up by overwriting shared DLLs. This is all well and good, although I don’t think it’s really needed for the core C+ runtime libraries, which have been around forever and already have their version encoded in the name, e.g. msvcr70.dll and msvcr71.dll (and now msvcr80.dll). I guess I can see why they’d want to homogenise all this, but it does make it more awkward for the native app developer.

What happens is that a manifest is embedded in your resulting binary which lists which versions of DLLs are required (this can be separated as another file too, but the default is embedded). In operating systems that support side-by-side assemblies (like WinXP), this manifest will be parsed and the libraries loaded from the appropriate subfolder of %WINDIR%\WinSxS (e.g. ‘x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.00.0.0_x-ww_09876c28′ – nice eh? ). This means that the right version of these runtime libraries has to be installed using Windows Installer (ie MSI database), you can’t just use nice simple installer tools like NSIS or Inno to plonk these DLLs in your app’s directory (or even the Windows system folder). It’s worth noting that this is still supposed to work on older operating systems too (like Win98) that don’t have a WinSxS area – the installer will just revert to the plain old system32 way and manifest information in the binaries will be ignored. You might think you could therefore cheat and just slap the DLLs in there anyway on all operating systems – I haven’t tried this yet but I suspect it won’t work since XP will parse the manifest and insist that it has to use the assembly route and can’t use the old unregistered DLL load route.

So, I think this is the underlying deployment problem – of course if you already have the .Net 2.0 platform installed you have these libs already configured so you’re ok, but in theory I think you can get this to work without, provided you build your installer as an MSI. It is quite restricting, and I don’t like it very much, but there we are. It’s also worth noting that if you don’t want to require the user to have administrator provileges, you can install the ‘assemblies’ (DLLs) as private versions in the app’s folder, but they still have to be set up with an MSI I think.

I don’t think VC8 Express comes with MSI building features (I’ll have to check when I get home), which is perhaps why this has turned into a larger problem. I’ll have to look around for a decent free MSI builder, since my favorite tools listed above can’t produce MSI as far as I’m aware.

I can’t say I like this. It reminds me far too much of COM object registration and all the messy nightmares that implies. Personally I like being able to just slap a bunch of files in a folder, with no external or global configuration. The private assemblies approach might be the closest we can get to this. This section of MSDN is a good place to start learning about this.

Well, the OGRE community has been taking it’s first look at VC8 (2005) Express Edition, which on the face of it seems like quite an incredible deal – a free copy of a great IDE with an optimising compiler and all the tools you need to make most native applications with C++ (among other things, but that’s what we’re most interested in). Besides a few minor missing features, such as a resource editor, 64-bit support and profile-specific optimisations, this seemed like the perfect tool for a budding native application writer. Stunning.

However, there is one major caveat. It appears that native applications written with VC8 express edition will not run on end machines unless the .Net Framework v2.0 is installed. That’s right – even though your bare-metal, purely native code application makes absolutely no use of .Net, it won’t run without it. It appears to be because VC8 insists on using relying on .Net assembly information even when you choose a native application, which is really not very convenient at all. This will need some more investigation over the coming days. If it is unavoidable, it means you have to distribute a wacking great extra library with your application or force the user to download and install it. Ouch. That means even though technically you could use Express to build, for example, a shareware / casual game, in practice you couldn’t sell it, since the .Net 2.0 requirement would completely blow the majority of your market out of the water because of the extra size of the download, the OS prerequisites and the technical sounding install requirements.

I hear that fully fledged copies of VC8 don’t have this limitation; I’d intended to buy one anyway, but it would have been nice to recommend VC8 express to people, since the VC IDE is still the best out there. What concerns me is that this dependency is pretty buried, and rather unexpected – I’m really hoping this isn’t something that applies to the full version; if it does I may just upgrade from my current 7.0 just to the old VC 7.1 instead (which I can get cheaper anyway) and be done with it. I really don’t want to be forced to use .Net if I don’t want to, and I especially don’t want to force users of my apps to install it.

I had loads of problems with my express install which seem linked with the fact that I’ve had a few betas of the full Visual Studio 2005 installed on this machine before which had not been removed cleanly. I thought I’d followed the overly anal uninstall procedure properly, but perhaps not. For others in this situation with ‘Package Load Failures’ and ‘CLR missing’ errors despite repeated uninstalling & reinstalling, try this link. The problems meant that I spent the majority of the time tonight downloading and installing and reinstalling rather than actually using VC8, so I’ll comment on features another time.

I’ve been catching up on a few of my TODO items, one of which is addressing a few remaining stability issues with the OGRE DirectX7 render system, a plugin which allows you to run OGRE on older computers running Win98 (which can’t run DirectX9) and with perhaps pretty dodgy drivers. It’s not been a priority for a while, since to attract new users it’s generally the newer tech that interests people, but at the same time having a solid solution for older computers makes it more useful for those targetting the shareware market. OGRE has plugins for DirectX9 and OpenGL for the higher end of the market (in theory the GL plugin can target these older machines too, but in practice manufacturers provided drivers that were so shoddy that it’s often not practical) and that’s where the focus is for future versions, but we do still support DirectX7 for the 1.0.x branch. We don’t support DirectX8, since it was a transition API version between fixed function and programmable hardware, and had several serious design flaws which luckily MS fixed in Dx9 but make engines designed around it fundamentally flawed going forward – hence IMO the complete rewrites many engines had to do to support full shader driven hardware.

Whilst DirectX7 is old and undeniably clunky in this day and age, working with it again wasn’t as painful as I expected. In fact, it was kind of quaint how simplified things were, when you didn’t have to worry about hardware buffers, shader extensions, and multiple other clever tricks that might have been applied – it really is quite basic. It’s never going to win any beauty awards, but it’s a simple old thing that plods on regardless without making much of a fuss.

I thought I had resolved all the issues; I certainly had all surfaces restoring properly and reloading their content happily when it wasn’t before, but just before going to bed I spotted a remaining problem to do with exclusive mode access when switching between fullscreen and windowed. I will sort that out later, I think it’s a case of trapping it and reconstructing the exclusive mode screen surfaces when it happens rather that using the default restore behaviour.

We don’t officially support Dx7 in Dagon (OGRE 1.1.x) since the majority of the swanky new features won’t work in it, and people get confused because Dx7 doesn’t coem with MS’s SDKs anymore, but I think I will move it into ogreaddons once I’ve done this work, and at least get it functioning there so it will remain an option for people that want it. Judging by this trip through it, that shouldn’t be a very big job anyway.

Well, I managed to get the morph / pose animation enhancements I talked about last week in at the weekend, plus a few other tweaks such as targetting individual vertex data sections in submeshes for performance with combined skeletal / facial setups. I need to do a little more testing on the combos and then think about adding export support for it to XSI. I also managed to bash through a chunk of patches, so the OGRE patch list is a little more manageable now.

God, my list just seems to be getting longer these days. I haven’t touched Kadath in over a week, and I really need to get back to it. I have a resource reload potential leak issue to investigate, and a few software updates to test and integrate on the OGRE web host. No rest for the wicked it seems.

I spent some time today with XSI, because I had a bug report queued up from earlier this week that needed some attention, and I wanted to build an OGRE exporter for my fresh copy of XSI v5.

Well, the former went well, apart from taking a lot of time to figure out what the issue was. I like XSI’s API, it’s generally very consistent and stable, but it the amount of cross-referencing and re-indexing of data can get very confusing sometimes, especially since the exporter does it’s own set of reorganisations too (to create the best mesh for runtime performance, rather than flexibility like the originating data). Anyway, after figuring out what it was the fix was so simple as to be an anticlimax; 3 hours investigation, 4 lines to fix. Oh well

Getting a v5 exporter built caused me some unexpected problems though. The problem is that Softimage also use STLport to build XSI, and whilst in version 4.2 they were using VC6 (I can tell by the DLLs), in v5 they’ve upgraded to VC7.1. All well and good, but they’ve also carried on using STLport, which I know from experience isn’t necessary any more, but hey. The problem that results from this is that they’ve built the STLport DLL they distribute with XSI v5 with VC7.1, and the DLL name for STLport doesn’t differentiate between VC7.0 and VC7.1. So, since I’m using VC7.0, I get MSVC runtime library conflicts. I can replace their STLport DLL with mine and it seems to work, but this is not the kind of solution I want to use (potentially breaking XSI is not a good thing).

So, right now I wish I had already upgraded to VC7.1. I didn’t because I felt ripped off since VC7.1 wasn’t really much different to VC7.0 except for the STL being fixed and a few compiler fixes; paying a couple of hundred quid for that less than a year after getting 7.0 seemed like daylight robbery. I plan to buy VC8 as soon as it’s widely available (should be a couple of weeks or so) because there are a few useful things in that, and besides it’s been a bit more time now, so I feel like I’m getting screwed less. I should be able to build the XSI v5 exporter with that without any conflicts. If I get time I’ll try it with the Beta I’ve had for a while but haven’t used much due to time constraints.

It’s a bit of a ‘family week’ this week since the funeral was yesterday and extra family are in the island, so we’re having a few get togethers and thus there won’t be too many code commits this week.

Over the weekend I made a little progress on the animation enhancements I mentioned a few days ago, hopefully I should get those in over the weekend. I might even get chance to play with XSI v5 a little more and start planning morph / facial animation export support for that (I’ll backport it to 4.2 for those who haven’t upgraded of course, I still have it installed).

I also added some new heuristics to Kadath so that the user can control how the initial partitioning of the level is carried out. You can now specify primary and secondary heuristics to use (secondary being used if the primary is the same), the default primary being ‘minimum cut’ (ie minimise the number of triangles sliced), and the default secondary being ‘maximum orthogonality’ ie maximise how orthogonal the splitting plane is to the triangles being cut. Other options include ‘maximum area’ (prefer planes which are covered by larger surface areas of triangles) and ‘random’ (do whatever). I also plan to add manual splitting planes eventually which the level designer can user to indicate where the first splits should occur. All this is pretty standard BSP building fare – the difference being that the BSP structure is just a starting point used to generate the final cell/portal structure.

Finally, I hope you’ve all watched Star Wreck : In The Pirkinning by now. Top job.