Header improvement

[helmers]

I have made my first steps with using the header today.

I work with my own header that is based on the 1.3b header.

Took me some days to add all the XML help tokens to all methods (>1300!!) but now I have the intellisense support for the methods and its parameters.

I have made up to now only minor changes to the classes/methods so the following results should also apply to the current/official header.

 

I started with the Control example and crashed after the first few calls to the collision callback.

 

I found two problems.

 

1. The collision callback header has the wrong parameters.

In my version (2.31) of the C headers the force parameter is a vector and no float.

And there is an additional parameter: float speed.

 

This still did not resolve the crash.

 

2. The mapping between the Vector3 and the byte* is not correct.

Here I would suggest the following improvement:

 

The Vector3 (and also the other Vector/Matrix classes) should be declared like this

 

[structLayout(LayoutKind.Sequential)]

public struct Vector3

{

private float m_X;

private float m_Y;

private float m_Z;

 

Then one could declare the passing of vectors in the callback as

 

public delegate void EntityCollisionCallback([MarshalAs(UnmanagedType.SysInt)] IntPtr entity1,

[MarshalAs(UnmanagedType.SysInt)] IntPtr entity2,

ref Vector3 position,

ref Vector3 normal,

ref Vector3 force,

float speed);

 

This did the job for me and there is no longer any memory corruption during the callback.

The same should also work for the normal methods (not only callbacks).

This should also improve performance as no copying of the float array is needed.

 

 

There has been suggested to start a project for the wrapper on sourceforge, codeplex, ...

This should really happen as I have the feeling that the header needs the joined effort to improve it.

One problem with this is that there are two equally valid ways to go:

 

I think the way klepto2 is going is to keep the classes as close to the C/C++ original as possible.

That makes the use of samples from other languages easier and helps to maintain the code when new versions of LE become available.

 

My personal way I plan to go is to make the wrapper more object oriented. Even if that means to rearrange the methods.

May be I feel that way because I come from the XNA world.

 

I hope klepto2 can have a look at my suggestions and can perhaps update the wrapper.

[ZioRed]

[structLayout(LayoutKind.Sequential)]

public struct Vector3

{

private float m_X;

private float m_Y;

private float m_Z;

 

...

This should also improve performance as no copying of the float array is needed.

...

mmh.. perhaps I remember wrong, but I thought that, when passing structs to a method, a copy of the struct is passed to the function, while passing a class a reference is passed. If it is so (as it seems from here), then I see no performance improvement changing "class" to "struct".

 

Am I wrong?

[helmers]

mmh.. perhaps I remember wrong, but I thought that, when passing structs to a method, a copy of the struct is passed to the function, while passing a class a reference is passed. If it is so (as it seems from here), then I see no performance improvement changing "class" to "struct".

 

Am I wrong?

 

You are on the right track!

 

With the 'ref' keyword you force the .NET runtime to put the "pointer" of the struct on the stack and not a copy of the contents. So you can enforce the same speed as when you use a class instead of a struct. Of couse this is not very 'nice' code because it has the side effect that you can chenge the callers value in the called method (thats what calling by reference is originally for). But when doing loops I think that performance is worth the less readable code.

Even Microsoft itself uses this trick in their XNA library, where for nearly all mathematical method (involving Vector or Matrix) exists a "normal" method but also a "by ref" method.

 

The trick with the "sequential" attribute simply defines that the fields for x,y and z are in this order, so that we can directly map the Vector3 struct to a pointer in the stdcall method. So we do not need any longer the Vector3.ToFloatArray() method.

[ZioRed]

Well if the use of struct instead of class significantly affects performance then I agree that it should be done (turning up our noses for aestethics).