Just Code it!

Comment or Leave a Message

Please Comment or Leave a Message if this is what you are looking for or if you have any question/comment/suggestion/request.

If you are reading this post it is probably because you have some trouble trying to have your application to run on a system where some COMs dependencies don’t seem to be happily resolved, or because you can’t afford to register the COMs at all (policy?)… or if you don’t have any COM problem at all, well… keep reading. The DLL Hell is always behind the corner.
Because the problem is quite annoying when happens, I provide at least four solutions so that you can choose the one you find more comfortable to use :). Let me know which one you prefer and if you know other alternative ways to do it as painlessly as possible.

The Problem
Imagine to have a simple application that references a COM object. You try to build your COM and then your app, and eventually you try to run it on your machine and… it works! Good! So you happily go and copy your App and the DLL of the COM in a single folder on a second machine and… BUM! Your App crashes without hope.
So, what’s going on?
The problem relies on the fact that when you use a COM DLL (with Early Binding), you are somehow coupling your App with a precise version of your COM library. This means that if one day you or someone else upgrades the COM DLL, then the App will still continue to work using the original COM it was binded to. What really happens is that your App will not simply try to locate the DLL (using only its name) in the current folder and then in the PATH environment variable, but will actually use a GUID (the CLSID) to locate the COM DLL in the Windows Registry and from there locate the file in the file system. GUID stands for Globally Unique IDentifier (while CLSID is the CLaSs IDentifier) and is automatically generated for you when you create the COM object and automatically used when you reference your COM from your App. If you want to see how to use a COM you can have a look at my other post ([intlink id=”114″ type=”post”]Create a .NET COM and use it in Unmanaged C++[/intlink]).
This GUID is then the only thing that the App will use to locate the COM DLL, and in order to make this work you have to “Register” your COM classes as we already know.
So, what if you don’t want to register it?

Sample Scenario
Let’s assume that we have a couple of COM DLLs with one sample Object each and both with a simple (different) method defined. In my example I have these:

  • MyPippoCOM COM with a SillyAdder class (CoClass)
  • MyOtherCOM COM with a SmarterMultiplier CoClass
  • TestApp exe that uses the two previous COMs using Early Bindings

In TestApp I instantiate the objects using the ProgID.

The Tool
Fortunately Microsoft came up with a (almost) simple solution.
The trick is create a *special* file that will tell to our App how to behave and where to look for what it needs. This file is the “Manifest”.
As a brief description let’s just say that this is a simple XML file and in there we can specify where are the DLLs that we want to provide to our app, bypassing the normal searching behaviour.

The Problem of the Tool
The problem here is that writing what you need here is not always (actually almost never) easy. In fact, in order to describe the COM that you App will have to use, you must “describe” it, specifying all the GUIDs, ProgIds (if you need it), and other nasty details that are generally (and fortunately) auto-generated for us when we Create and use a COM in a normal/standard way… So why do we have to suffer now? Fortunately we don’t, we are safe this time as well :P.

The Basic Solution – Understand What’s Going On
Based on Microsoft Documentation, the way to create a manifest for your DLL is to use the Tool mt.exe (this is the Documentation).
With this tool you can generate the manifest that you will have to use with your App if you want to achieve our goal.
For example, considering our MyPippoCOM.dll DLL, we could do something like this (from the command prompt, in the folder where the dll and tlb files are stored):

This will generate a file named “mySample.manifest” that, in my case, will contain something like this:

At this point you could do the same thing for the other DLL and then (only after), create the manifest for your app.
This is because with this tool you can only specify one dll and tlb when you generate a manifest and consequently you cannot create a manifest with the data for both DLLs in one go. Fortunately though this tool allows you to merge multiple manifests! So you could use this as final step toward the creation of the Application manifest. I said “toward the creation” because unfortunately the manifest that you will have at the end of this process will be incomplete and could contain some errors as well if you didn’t follow exactly my example and you specified the dll and tlb file using an absolute/relative path instead. I’ll explain later how fix this. For now le’s see how could you merge the two manifests:

The result will be a file named “merged.manifest” that in my case will contain this:

As it stands you cannot use it directly. You need to rename it, fix a couple of things in it, adding some missing informations and you need to build the TestApp without embedding its manifest.
So, first things first. Go back in VS2005 and build our TestApp changing one setting. Open the project’s properties, expand the section “Manifest Tool” and enter in the “Input and Output” entry. In the option screen on the right set “Embed Manifest” to “No”.
Now you can build the project again and this time a file TestApp.exe.manifest (in my case) will sit next to the executable.
Now open it. It should look like this (the dependentAssembly section will include the proper assembly based on which type of build you selected, debug or release):

Now it is just a question to grab our previous merged manifest (from the two COMs) and copy all the content that appears inside the “assembly” tags into the TestApp.exe.manifest, just before the assembly closing tag. In my case this will be the result of this step:

Ok! Almost there.
The final step is to add something that mt.exe doesn’t add for us but that I like to have, the ProgID attribute. You have to do this by hand unfortunately. Just add this attribute to any comClass tag. The final result in my case is this (I optimised some tags a little bit as well):

Note that the ProgID should actually contain the version number as well (e.g. progid=”MyPippoCOM.SillyAdder.1″), but the other version does work if you don’t specify this number when creating the object in your code as in:

That’s all for this first long manual version.
There is a way to skip some steps and do it slightly more automatically.

The Semi-Practical Solution – The Slightly More Automatic Way
A way that I found helpful to adopt is to make usage of the post-build steps feature.
To keep it short and simple, what you can do is edit the post-build event for both of your COMs projects, adding somethig like this:

(and similarly for the other COM).
This will generate automatically a manifest named “manifest.manifest” (nice name uh? :P) in the project output folder.
Then edit the TestApp project’s properties, writing in “Manifest Tool | Input Output | Additional Manifest Files” the location of any manifest that you want to merge.
Those two settings will essentially automate the creation and merge of the manifest that we previously did manually!
You will have to do the final fixes anyway. Maybe you can try to automate this as well :).

The Practical Solution – The Fast Way
I found a way to cheat and generate the manifest with even less work. It is sort of cheating, but it is fast and works! :).
Instead of opening Visual Studio 2005, open VS2010 and create a new project. Just any project, a console app for example.
Now right click the References tab in the solution explorer and select “Add Reference…”.
In the window that will pop-up select “Browse” and navigate where the first COM DLL is located and add it.
Repeat the same process for all the other COMs.
When the References list is completed, expand it and select all the COMs that you just added.
Go in the “Properties” window of the selected references entries and change the value of “Isolated” to True.
Job Done!
Now when you will build the project a .manifest file will be automatically generated and it will contain the correct XML for both COMs.
mine looks like this:

Notice that it contains the ProgID attribute with the version number (“.1″) at the end of the string (see: progid=”MyPippoCOM.SillyAdder.1”). You will have to remove it if you don’t specify it in your TestApp application.
Apart from this, you can directly use this as input manifest for the TestApp saving even more time! :) (you can consider to change the assemblyIdentity attribute if you do this).
NOTE: In order to apply this solution the COMs must be registered on the developer machine. This must be said just in case you did some previous steps and you unregistered them and you didn’t rebuild the projects ever after.

The Speedy Solution – The Last Tip!
There is a final tip to avoid even more typing. The only thing to prepare is the merged manifest in the way you prefer and use this one as Additional Manifest File in the Input and Output section of the Manifest Tool in the properties of the C++ TestApp project. Then, instead of setting the Embed Manifest to “No”, Leave it to “Yes”.
This will generate the application exe without any needed manifest and this is ready to be executed side-by-side with the COM DLLs.
No more editing, no more problems :).

Note about VB6 COMs
If you have VB6 COMs the previous method will still work really well (even with a correct ProgID), but if you want to explore even alternative ways, there is an interesting tool that you can try to use to generate the manifest for each specific COM.
You can find the tool here: Make My Manifest
What it does is essentially create a manifest for any VB6 projects (not only COMs) generating a complete manifest with all the project’s COM dependencies.
So this is more exhaustive than our single C++ COM manifest and this means that if you have multiple VB6 COMs that uses others COMs, then the manifests could contain common elements and thus the merge should take care of this. But for the rest it is a quite nice tool to use, so give it a try.

The DLL Hell is not a random name and what I tried to cover in this post is just the tip of the iceberg.
I wanted to write this because I found quite difficult to gather the practical information that I ended up discovering personally through a long series of frustrating experiments in order to properly understand and faultlessly solve the main problem.
I hope that this helped you and you found it interesting.
Let me know if you discovered other ways to solve it or if you have any suggestion/question/information that you want to share ;).

The base of all the Maths that I will use is the Vector for sure (well, the number itself… but I have no intention to start from there :P).
I assume that you are somehow familiar with the concept of vector and its basic operations (sum, vector/dot product, etc).

The vector that I need for this project is a 3D vector. Sometime it is more convenient to represent 3D vectors using 4 components (with the last one “w” set to 1) to simplify some transformation. I will start using a 3-components vector for now.

We could use directly the Vector3 class (or Vector4) in XNA for this, but I will write my own just to have more control over it and to play directly with the operations/methods that I will expose. It is just a chance to see what’s behind and we can decide to remove it in the future if we don’t need it anymore.
The nice thing about writing your own basic classes is that they will be very portable and what you will have to provide will be just the wiring with the current library (OpenGL/DirectX/XNA) Vector/Matrix classes. The rest of your code will (almost) work without any change (well… you will have to change the rendering as well).

The basic starting point for the Vector3 class is just a set of 3 properties that stores the coordinates we are interested in.
Without wasting too much time, I will just declare the three properties as public fields in my Vector3 class.
Those are the basic declaration in C++, C# and Java:
class Vector3 {
float x;
float y;
float z;

public class Vector3
public float x;
public float y;
public float z;

public class Vector3
public float x;
public float y;
public float z;

Easy :).

Dot Product
Aside from the 3 fields (and properties) used to represent the 3 coordinates (x, y, z), there are some more useful methods to implement.
A set of basic operations (amongst the obvious one such as assignment or equality operator) are:

  • Dot/Vector product
  • Scale
  • Magnitude (Normal/Squared)
  • Normalisation

The implementation of the dot product is straightforward.
In C#, assuming to implement it as an overloading of the multiplication operator (“operator *”), the code will be something like this:

public static float operator *(Vector3 _vectorA, Vector3 _vectorB)
return _vectorA.x * _vectorB.x +
_vectorA.y * _vectorB.y +
_vectorA.z * _vectorB.z;

Just as an example, in C++ this could be implemented in a slightly different way when declaring it as a member function:

float operator *(const Vector3 &_vector) const
return x*_vector.x + y*_vector.y + z*_vector.z;

And in Java it is more fun… I am sarcastic here. I have to implement it in another completely different way (no operator overloading):

public float GetDotProduct(Vector3 _vector)
return x*_vector.x + y*_vector.y + z*_vector.z;

It is quite interesting to notice how the overloading differs in C# and C++ and especially (missing :P) in Java.
If for some reason you like the Java version, then you can easily apply this in the other two languages as well… if you want to achieve the opposite instead (overloading in Java) then… good luck :).

I have to admit that the Dot Product is not really exciting. So let’s look at the Cross Product for a more (even if not much more) interesting example.

Cross Product
The Cross Product, differently from the previous one, is an operation between two vectors that returns another Vector. You can find the formal definition and all several properties explanation from the long series of resources on the book-shelves and websites (wiki).
A common way to write it is: v = a x b, where the “x” represent the cross product operation.
What is important to know at the moment is that when implementing the cross product you need to pay immediately attention at least to a couple of really important details:

  • You need to take into account the handedness of the coordinate system.
  • It is not a commutative operation.

(Coordinate Systems)
To see the difference due to the handedness of the coordinate system you can simply use the left-hand rule or right-hand rule that matches the handedness of your coordinate system to easily visualize how the resulting vectors differ.
The left/right-hand rules are quite easy to apply. Just use your left/right hand (or one of your friends :P), shape it like a fist and stick out the first three fingers (thumb pointing up, index pointing forward and yes, the third and preferred one, perpendicular to the other two). Now, keeping the three fingers (initially) at 90 degrees each one with the other, just rotate your left/right hand so that your thumb matches the direction of you first vector (“a”). Then rotate your hand around that axis (represented by the thumb) so that your index finger ends up on the same plane identified by the second vector (“b”) and the thumb (still fixed on “a”). If you see that you should spread the thumb and the index more than 180 degrees in order to match your index with the vector “b”, than simply flip your hand around the thumb (rotate it of 180 degrees around it) and you will see that (assuming that you can stretch your fingers as much as 180 degrees) the second vector can always be matched by your index finger now.
After all this stretching exercise you will find that the third loved middle-finger will point along the direction of the vector that results from the cross product.
Now you can relax you muscles, the left/right-hand rule will not tell you more than this… you cannot shrink or elongate your fingers to find out the length of such a vector :P… I hope.

Back to the Cross Product
The fact that it is not a commutative operation should now be clear. Just try to apply the same hand rule assuming that “a” and “b” are switched. Not only you will find that the direction is not the same, but you will find out that is exactly the opposite of the previous one! It is in fact true that the cross product is an anti-commutative operation!

Enough said about this… well, one thing is missing. The length of the resultant vector.
For this you can just stick to the definition I will give, or, if you are interested or curious, refer to a math book (or Wikipedia if you prefer). I will not explain where this came from because it is not relevant in this context and it would include some concepts related to matrices that I didn’t explain yet.
The direct and fast result is this:
The result of “v = a x b” is a vector with the components defined as:

  • x = ay * bz – az * by
  • y = az * bx – ax * bz
  • z = ax * by – ay * bx

Because the result is a vector we can use more fantasy when writing our code :). Those are some example of useful methods to apply this operation in the different languages.
Notice that if the two vectors are parallel the result will be 0!

Looking at the C++ example first we could decide to overload the “operator %” (if you like it) and even the “operator %=”, the compound assignment operators (well you will not like this if you didn’t like the previous of course). Here it is how it could look:

Vector3 operator %(const Vector3 &_vector) const
return Vector3(y * _vector.z - z * _vector.y,
z * _vector.x - x * _vector.z,
x * _vector.y - y * _vector.x);

void operator %=(const Vector3 &_vector)
*this = VectorProduct(_vector);

of course this is a quite lazy version of the “opertor %=”… a more optimised one should be:

void operator %=(const Vector3 &_vector)
float tx = y * _vector.z - z * _vector.y;
float ty = z * _vector.x - x * _vector.z;
float tz = x * _vector.y - y * _vector.x;
x = tx; y = ty; z = tz;

If you want, there is still an improvement to make here. If you try to write the following line:

vectorA = vectorB %= vectorC;

You will notice that the compiler is not really happy… This is because our compound “operator %=” doesn’t return anything. If you want to be able to do such a thing, then you should consider modifying the code for this operator in something like this:

Vector3& operator %=(const Vector3 &_vector)
float tx = y * _vector.z - z * _vector.y;
float ty = z * _vector.x - x * _vector.z;
float tz = x * _vector.y - y * _vector.x;
x = tx; y = ty; z = tz;
return *this;

As a last note worth considering is to define all those as inline functions in C++.

The C# version is:

public static Vector3 operator %(Vector3 _vectorA, Vector3 _vectorB)
return new Vector3(_vectorA.y * _vectorB.z - _vectorA.z * _vectorB.y,
_vectorA.z * _vectorB.x - _vectorA.x * _vectorB.z,
_vectorA.x * _vectorB.y - _vectorA.y * _vectorB.x);

And in Java:

public Vector3 GetVectorProduct(Vector3 _vector)
return new Vector3(y * _vector.z - z * _vector.y,
z * _vector.x - x * _vector.z,
x * _vector.y - y * _vector.x);

Other Operations
Enough for Vector3. All the other operation are quite straightforward to implement as well, so it is just a question of describing their functionality:

  • Add/Sum: basic operations to add and subtract to vectors.
  • Copy/Clone: return a copy of the vector object (if we are using mutable objects).
  • Compare: check if two vectors represent the “same” vector in space
  • Scale: multiplies a vector by a number.
  • Magnitude (Normal/Squared): returns the length of the vector. The squared length is useful in some cases and it is nice to have if we can avoid to waste computational time computing a square root that we don’t really need.
  • Normalisation: scales the vector in order to obtain a unit length vector.
  • More as we need them :).

Next thing will be more challenging for sure: The Matrix!

Physics Engine – Introduction

March 12th, 2011 | Posted by riccardotramma in .NET | C++ | CSharp | Java | Physics - (1 Comments)

I decided to document here my personal project: “Building a small Physics Engine” perfectly usable to build small/medium games.

My intention is to bring this series of posts as far as possible. During this journey anyway, although good code and clean architecture is always important and always a basic principle for the code I am going to write, I cannot assure that I will always bring this to the extreme for this project and I will probably take some short-cuts and some lazy choice for several reasons:

  • This is a personal project
  • I want just to have fun with it
  • I don’t want to digress too much from the main argument
  • The aim is to quickly (and happily) build a Physics Engine after all
  • I don’t want to waste too much time refining something that I don’t really need (for now)

I will not explain everything in detail (there are books and books on the matter and it is not my intention to write a new one) and what I will state will not be necessarily complete and mathematically impeccable (some assumptions will be always along the way to simplify matters), but (hopefully) it will work! :)
I will assume a basic knowledge of some concepts, especially basic Maths/Physics concepts and operations. If something should not be clear just google it or ask it if you cannot find the answer you are looking for, I’ll try to answer asap.

We have to consider that there are several (sometime drastically different!) ways to obtain the same result or to simulate/model a concept. Some are better than others, sometime it is only or a question of personal preferences or can be that the results are only better in the specific context where we are using our (mathematical) model.
That said I will mostly use my personal preferences for techniques and methods, while I will use some less-efficient/precise ways when I reckon that I can save some developing time/resources and the result is still pretty acceptable. This is still a demo/personal-fun project and more fine-grained/polished/robust/efficient code can be added later on if anyone is interested. I will probably mention anyway some different techniques that I will maybe discuss more in detail even giving some examples if I will consider them worthwhile at the moment of mentioning them.

What about the source code?
Well, I will present code mainly in C# (I assume), but I do not exclude that I will show some concepts using C++ or even Java… just for fun and to have more examples :)… the important thing are the concepts after all… and the code, yes, the code!
I will give examples using DirectX, XNA or OpenGL and I will use (on my machine) Visual Studio (2005/2008/2010) or Eclipse… and yes, even the operating system will not be unique! I will use Windows or Mac (well… even Linux maybe… no ok, not for now, but it should not be difficult to implement with the existing material)!
This should give a broad view on how achieve things in different systems, using different libraries with different languages… what else? :)

So, let’s start from the basic, Math! Yes, Math is always the base :)… well, Geometry in this case.