SFML community forums
Bindings - other languages => DotNet => Topic started by: Conduit on March 09, 2015, 04:45:25 am
-
Given the one-to-one nature of the Vector classes and some built-in C# structs (e.g. Vector2f, SizeF, PointF), I think it would be sensible to include explicit casts to those classes. We could also consider extension methods (e.g. "ToVector2f") to make conversion from those structs to Vectors simpler. Thoughts?
-
That would create dependency for System.Drawing which is generally useless unless you are working with Winforms or WPF application.
-
My biggest issue with doing something like this is the question of where do we stop doing this? Because if we add vectors it also makes sense then to do rects and colors. There may even be more that I'm not thinking of at the moment (what about keyboard keys and mouse buttons?). And then there is the problem of lots of these CLR structures being duplicated for GDI+ and WPF.
System.Windows.Point (https://msdn.microsoft.com/en-us/library/system.windows.point%28v=vs.110%29.aspx)
System.Drawing.Point (https://msdn.microsoft.com/en-us/library/system.drawing.point%28v=vs.110%29.aspx)
System.Drawing.PointF (https://msdn.microsoft.com/en-us/library/system.drawing.pointf%28v=vs.110%29.aspx)
System.Drawing.Rectangle (https://msdn.microsoft.com/en-us/library/system.drawing.rectangle%28v=vs.110%29.aspx)
System.Windows.Rect (https://msdn.microsoft.com/en-us/library/system.windows.rect%28v=vs.110%29.aspx)
System.Drawing.Size (https://msdn.microsoft.com/en-us/library/system.drawing.size%28v=vs.110%29.aspx)
System.Windows.Size (https://msdn.microsoft.com/en-us/library/system.windows.size%28v=vs.110%29.aspx)
System.Windows.Media.Color (https://msdn.microsoft.com/en-us/library/system.windows.media.color%28v=vs.110%29.aspx)
System.Drawing.Color (https://msdn.microsoft.com/en-us/library/system.drawing.color%28v=vs.110%29.aspx)
I think it would be sensible to include explicit casts to those classes
Definitely would need to be explicit.
That would create dependency for System.Drawing which is generally useless unless you are working with Winforms or WPF application.
That is another thing, so instead of SFML.NET only depending on the core System.dll we would now be depending on multiple dependencies. That I'm sure 90% of the users don't use... to add to that fact: if we did this and added a dependency for System.Windows (WPF structures) then we will break the library on Mono and will also have to upgrade the framework we compile against (.NET 2.0 doesn't have WPF).
To be honest, these conversions to me really sound like a job for an extension library to SFML.NET (such as here (http://en.sfml-dev.org/forums/index.php?topic=10564.0)) and not something we should include in the core. I mean, if we added support for these conversions - should SFML now support conversions from say GLM?
-
Oof. Didn't realize this would cause an incompatibility with Mono... my familiarity with Mono doesn't extend far past the basics. That alone is probably a good enough argument to sink this ship, given that it would have a much greater effect on the library's users than a little added syntactic sugar. I can just as easily create a small, personal addendum to the SFML.Net code and compile my own copy from now on - especially since I'm doing that already for the explicit conversion between Vectors while you guys are finishing up the next release.
-
My biggest issue with doing something like this is the question of where do we stop doing this? Because if we add vectors it also makes sense then to do rects and colors. There may even be more that I'm not thinking of at the moment (what about keyboard keys and mouse buttons?). And then there is the problem of lots of these CLR structures being duplicated for GDI+ and WPF.
Could limit to casts/conversions of internal SFML data classes. For an example the SFML mouse position is a Vector2i but all of the SFML Sprite/World positions are Vector2f. Working between the two requires a bit of finagling. Don't mind a bit of extra coding but.. simplicity wins out over verbosity. :)
-
That's totally intended. Your world space does not have to match 1:1 to the window pixels (i.e. when you zoom in), as such you should use the mapPixelToCoords or mapCoordsToPixel functions.
-
Could limit to casts/conversions of internal SFML data classes. For an example the SFML mouse position is a Vector2i but all of the SFML Sprite/World positions are Vector2f. Working between the two requires a bit of finagling. Don't mind a bit of extra coding but.. simplicity wins out over verbosity. :)
As already said in the recent request thread (http://en.sfml-dev.org/forums/index.php?topic=17670.0) and bug tracker issue (https://github.com/SFML/SFML.Net/issues/104) this already exists.
-
Yeah - Vector conversion has been present in the source for a while now, apparently (see my post/bug ticket, linked above), but wasn't available unless you compiled the library yourself. The recent upload of v2.2 should include it, I believe - try downloading the new files, and check the SFML.System namespace. The casts must be explicit, but they're definitely working.