Messages

1

DotNet / Re: [Solved]Transform... a class? or maybe an struct?

« on: May 31, 2012, 07:59:40 pm »

Now that I finally have time to get back to programming, I looked over the new Transform.cs, and I see you still have several imports for matrix mutations. This isn't really a priority, but I recommend you implement these operations in C# so they can be optimized by the JIT compiler instead of having to go through the overhead of marshalling to call a C function.

Also, Laurent, you don't always have to create a new matrix with XNA. The operations are overloaded so you can optionally specify an existing matrix as an out parameter to avoid making a new one.

2

DotNet / Re: Transform... a class? or maybe an struct?

« on: May 23, 2012, 04:06:35 am »

No, it is more tricky because of memory management and object lifetime. It would be complicated to explain and I'm in a hurry this evening, sorry

Well I'm saying you copy the struct in those instances to avoid having any issues. But if you're marshalling a reference in C#, then the object should stay alive since its on the stack so it will work with C++ functions that are taking the struct by reference, and copies should also work.

Is there something I can do?

No, not really. It's a rule of C# to not allow structs to have default constructors so allocation and other things work just fine by zeroing the memory. I don't really see it as a problem myself.

Anyhow, thanks for the change. I really appreciate it.

3

DotNet / Re: Transform... a class? or maybe an struct?

« on: May 19, 2012, 09:59:48 am »

I know how it works, I already do that with other structures

But CSFML is a binding too, so there's no Transform structure in it, only a wrapper around a C++ sf::Transform pointer. So I would have to do the same modification in CSFML, which means duplicating the Transform functions three times. Definitely not the best thing to maintain.

Well, part of the problem seems to be that you have this C binding in-between C# and C++ and I don't know what exactly it's doing which is making things difficult to brainstorm about.

My main ports are that:
1. Transform needs to be a struct.
2. Transform methods should be defined in C# and modify transforms by reference.
3. Transform instances should be sent to C++ by pointer to the C# struct which matches the layout of the C++ struct.
4. Transform instances retrieved from C++ should be copied into a C# struct, not wrapped.

Perhaps you should simply eliminate the C binding in-between and import the functions from the C++ modules directly. You can avoid use of extern "C" too by importing the decorated function names. Making sure that the decorated function names are up to date in the C# binding seems simpler than what we're going through now.

Edit: I just reread your post, and I'm wondering why you think you'd need to do the same modification in CSFML. If the C# struct has the same layout you need only cast that to the wrapper you're using in CSFML and pass that to wherever it needs to be. CSFML shouldn't be able to tell the difference.

Looking at your code, you have:

struct sfTransform
{
    sf::Transform This;
};

You just need to pass a C# struct to whatever CSFML functions take a sfTransform* and it should work fine, no? Marshal.PtrToStructure() should help here for copying pointers you get from C/C++ into a new C# struct.

4

DotNet / Re: Transform... a class? or maybe an struct?

« on: May 19, 2012, 04:30:14 am »

I have no real experience with DllImport in C#, but you should be able to create a struct class in C#, then pass it to your C/C++ code as MyFunc(ref MyStruct myStruct), which I assume would give you a pointer in C/C++, which you could cast to your equivalent C/C++ struct. This means you'd need your C# struct to have the same members and alignment as the C/C++ struct, but that should be simple enough.

Edit: Here is an article explaining the details: http://msdn.microsoft.com/en-us/library/awbckfbz.aspx

5

DotNet / Re: Transform... a class? or maybe an struct?

« on: May 19, 2012, 12:55:36 am »

I'd like to chip in and say that I just recently started using SFML.NET and was surprised to find that Transform is a class and not a struct. Having to allocate an object on the heap every frame is bad. The Transform class needs to be made a struct and modeled after the Matrix class in XNA that uses static functions to modify matrices by reference and avoid copying them. (i.e.: Matrix.Add(ref Matrix a, ref Matrix b, out Matrix c)) It should not be a wrapper around a C object, since keeping it as a struct in C# allows for better optimization for operations in C#.

In my opinion, simply make the underlying API take a reference to the Transform struct and then let it do whatever it wants with that.

Also, chain calls are nice fluff, but they're ultimately fluff and having performance is what matters in this case. I can deal with the loss of chain calls if it means not having 60+ heap allocations every second while idle.