C++/CLI

Since I finished (except for materials) .pdmesh file loading in pdEngine, I have been working on a mesh viewer application. Now, this is not a game and requires a proper GUI, and everyone knows that C# is the only satisfactory way to do this. I don't want to be meddling in MFC, I want nice windows, made by WPF.
This means that I need to create a wrapper for pdEngine in C++/CLI, so that I can get it working through C#. I'd never used C++/CLI at all before last week, so it was an interesting learning experience. I was previously biased against it as a horrible language hacked together, between native and managed, which in some ways it is, and yet it works and doesn't have many annoyances.

That is the language however. I am using Visual Studio 2010 (release candidate, but I will get the final through DreamSpark in due course), and for all its bells and whistles, can't handle C++/CLI for shit. There is absolutely no C++/CLI intellisense. It sounds stupid, but intellisense makes it so much easier to program, especially when writing a wrapper. I don't have to remember all the variable names I have given, when copying lots from one location to another, it prompts me.
This is why, when I found out there was no intellisense in VS2010 (and there was in VS2008) I got very annoyed. I ended up downloading an addon, called Visual Assist X, which essentially does intellisense better, through an extension. It includes C++/CLI. Now, I think if one small company can get out C++/CLI within months of a beta of the IDE, a multinational corporation shouldn't have to drop it because of "time constraints".

Templates in .cpp files

I blogged a few days ago about the need to define templated members within header files, and why I found that annoying. Well, when looking through the propositions for C++0x, the next specification of C++ that could be released as a draft this year, I was pleased to see the heading "Extern Template". The syntax would be thus:
extern template class std::vector<myclass>;
See the full infromation, and the rest of teh changes in this spec here.

You learn something new every day

I frequently see function prototypes written as
void function(type& param);
but until today have never found out what the relevance of the & was. I assumed it was the opposite of a *, a dereference, but didn't understand how that worked. I always treated functions like this as if they were written
void function(type param);
and no harm came of it.
But, looking at a physX function early that was
void NxBoxShape::saveToDesc(NxBoxShapeDesc& desc)
I wondered how it could return from this. I had the additional problem that I had a pointer I wanted it to save the desc to, of type BYTE*. I tried various casts that didn't work, and after a while on Bing I found out that this type of parameter takes a normal variable as an argument, but within the function treats it as a reference, so the value can be changed and it will affect the argument.
It is odd that I never knew this before, either I missed it in the various tutorials and books I read, or no-one thinks it worthwhile to mention. Well, now I know.
In the end, I solved my little problem by just passing a new NxBoxShapeDesc then using CopyMemory to save it to the pointer.

Templated class

For some reason unbenknownst (that's an awesome word) to me, templated classes must not only be declared, but defined, in header files rather than C++ files. I assume this is becasue templating is done at compile time, and the compiler does not have access to other C++ files, that is done with the linker.
The upshot of this is that whenever modifying the functions in this, a compile of every other C++ file that sues this header has to be done. This slows down development time significantly. I can take long compiles, but it's annoying when I'm only making small changes in one file.

Collision shapes

Until now, on pdEngine, there were three choices when it came to collision shapes: a box around the whole objects, a sphere around the whole object or an accurate triangle mesh. The first two do not produce accurate results for complex shapes, and the last being slow for physX to handle.
What I have been wanting to do for a while, and something I have now achieved, is rather than generate a bounding box around the whole mesh, generate one for each subset. I have also done this using spheres, although it's more academic and I can't see this type of bounding actually being used.
In the attached screenshot there are three objects of the same mesh, a biplane that comes with the DirectX SDK. The leftmost uses spheres, the middle uses boxes and the one on the right uses the mesh.
The trouble with this technique I have experienced is converting between the physX coordinate system and the Direct3D coordinate system, one of which is twice the other. At the moment, this only works for axis-aligned bounding boxes, so it is not very useful for some objects, but I shall experiment with alternatives.

Confusion?!

I get very confused when debugging these days. This is because I can no longer tell the difference between my Direct3D 9 and 10 renderers. That's a good thing :)
In terms of progress, fluids are coming along in DX10 but are not yet done. Models now support multiple subsets per mesh, and the next thing to do is to get the physics to use these too.

In other news, I recently reinstalled StumbleUpon. I have not had it since Windows 7, as I saw it as something of an addiction I needed to free myself from. However, I do very little at soem points on the computer, and StumbleUpon is better than Omegle or 4Chan or wherever else I am tempted to go.