SFML.NET Proposed Changes

[smpsnr]

Sounds like you've never seen DllNotFoundException: csfml-window-2 

It takes a bit of time to figure out where to put all the dependencies and how exactly to map the DLLs. On Linux editing the global DLL config is required for OpenGL support, on OS X I still don't fully understand how the native CSFML libraries are found, etc. That with platform differences in core .NET methods (edited last post) makes it more difficult that it needs to be.

[Laurent]

Another thought - On Linux, XInitThreads from libX11 must be called for OpenGL windows to work properly. If possible this should happen in the background.

This issue will be solved after we switch to XCB, which is thread-safe.

It takes a bit of time to figure out where to put all the dependencies and how exactly to map the DLLs. On Linux editing the global DLL config is required for OpenGL support, on OS X I still don't fully understand how the native CSFML libraries are found, etc.

I'd be more than happy if someone could write a nice tutorial about it. I can't do it myself because I have no idea what needs to be done on these platforms

[smpsnr]

Great!

I don't know if I'm the most knowledgeable person on the subject, but my stuff does run, so I could give it a shot. Will start a thread when I have some time.

[StormWingDelta]

This should be interesting to see.

[zsbzsb]

Alright, time for a little recap. Several pull requests have been merged to fix some of the above issues. Check the original post for an updated list. However there are a few pull requests that need some additional discussion.

With the pull request that changes GetPointCount() and SetPointCount() to a property a few things came up. The shape base class only defines the property with a getter and no setter. So in the circle and convex shapes we also need the setter. But in C# it is impossible to override a property and also add a setter if the base class does not define a setter. So there is 4 options to solve this.

#1 Instead of overriding the PointCount property in derived classes, simply declare the property as 'new'. This will allow the derived classes to implement getters or setters as needed, however it has the drawback of when a reference just to the base class type, any calls will not call the derived type's property. And then this breaks the inheritance model, so it is a nono from me.

#2 Go with how I setup the pull request, change GetPointCount to a property and then leave the function SetPointCount in the derived classes that allow changing the point count. The drawback here is that it is inconsistent. To get the point count the property is used, but to set a point count the function is used.

#3 Another option is built off of #1 and #2. Change both functions to a property and in the base shape class and just have the setter part of the function not do anything. This would allow derived classes to override the setters and/or getters without any issue and everything will work properly when dealing with base class types. The only drawback to this solution is that setting the point count may not have any affect and this may cause some confusion.

#4 Or leave as is with the functions for consistency.


With this pull request I changed the SetView() and GetView() functions to a property. This issue with this is that we are wondering if it hides the true intent of of the View property. What I mean is that is it clear enough that you must set the view after changing it.

Take for example the following code.

// Current working code
var view = window.GetView();
view.Move(new Vector2f(5, 5));
window.SetView(view);

// New property that would work
// the question is whether or not this View property would be clear enough that you must assign it after changing it
var view = window.View;
view.Move(new Vector2f(5, 5));
window.View = view;

// However I think both methods fall to this problem
window.GetView().Move(new Vector2f(5, 5));
window.View.Move(new Vector2f(5, 5));
 

Please give feedback on these issues. 

[Laurent]

#1: not a solution
#2: too inconsistent
#3: very bad design
so... to me the best one is still #4

Views: maybe we should find a totally different design. Obviously, C# doesn't provide the language features that makes this design work in C++ (no copy semantics, no read-only return types).

[zsbzsb]

Views: maybe we should find a totally different design.

I was thinking about this, and with some internal trickery I think I could make the following work. In my humble opinion this option here would make the best sense. Sure it breaks consistency with the C++ version, but I think it makes some of the most sense.

No need to reassign the view, whatever changes you make on the view object automatically get applied back to the render target from where they came. Note that the daisy chaining would be optional.

window.View.Move(new Vector2f(5, 5)).Rotate(45);

[Laurent]

And... how do you make this work?

[zsbzsb]

Internally both the View/RenderWindow objects would track the which RenderWindow(s)/View(s) that are assigned to them.

Whenever the user grabs another View object from the RenderWindow, the View will have an internal reference to the RenderWindow and also the RenderWindow will keep a reference to the View. Then whenever that view is changed it will automatically apply those changes back to the internal reference. The same would apply to the RenderWindow, if it has its view reset to another view then it can go to all the internal references of each view that is assigned to it and remove its reference from those views.

If you want, I could come up with a more robust sample code to explain how the API and internally it would work.

[StormWingDelta]

Being able to have a list of views that auto update if you change something about them rather than having to go through the setting a new view over and over again for each when a change is made would be nice.   That aside nothing to complain about too much.

[kpulv]

Being able to modify Vertices in VertexArrays like you can in the C++ version would be awesome.  It's tough to make good performing custom graphic types that rely on vertex arrays since in C# you have to create all new vertices or rebuild the geometry from scratch whenever an update is needed.

[zsbzsb]

Being able to modify Vertices in VertexArrays like you can in the C++ version would be awesome.

Thing is, initializing a new vertex every time something changes is the best way to do it unless we broke conventions that would directly modify the underlying vertex array. structs in C# are value (meaning copied around by value) objects and are the easiest way to work with unmanaged memory. So this really won't be changing - however I have never seen any serious performance issues using SFML.NET compared to pure native C++ code. Just remember if you need to update your array just change the vertices that need to be changed. 

[Deathbeam]

Internally both the View/RenderWindow objects would track the which RenderWindow(s)/View(s) that are assigned to them.

Whenever the user grabs another View object from the RenderWindow, the View will have an internal reference to the RenderWindow and also the RenderWindow will keep a reference to the View. Then whenever that view is changed it will automatically apply those changes back to the internal reference. The same would apply to the RenderWindow, if it has its view reset to another view then it can go to all the internal references of each view that is assigned to it and remove its reference from those views.

If you want, I could come up with a more robust sample code to explain how the API and internally it would work.

It can be done in this way, or in simplier way. You will have property View in RenderWindow. When you will change this view, in Draw call it will check equality between sfGetView and View what you have in RenderWindow, and if they are not equal, it will set View to RenderWindow. I think this won´t cause performance drop, but I am not 100% sure about it. There is also another method, and that is similar to Transformable class, so view will have internal boolean NeedsUpdate, what will change to true if you will change any property in View. And when RenderWindow sees that View needs update and uses this view, it will change its NeedsUpdate to false.

[Laurent]

Someone to fix this?
http://en.sfml-dev.org/forums/index.php?topic=15343.0

(and possible similar errors in other Equals functions -- didn't check)

[zsbzsb]

Alright, So I made a commit that adds the System module (moves vectors and object base there for now), yet Github is screwing up and throwing an error 500 page so I can't make a PR 

Well after contacting github support they pushed a fix out for it so I made the pull request now.

(click to show/hide)

Sorry for the trouble! The team is investigating and I'll let you know when this is resolved.

Just wanted to followup and let you know that the team pushed out a fix for these 500s so things should be back to normal.

Anyways, I was thinking about how to do the Clock / Time classes. I could either use the built in Stopwatch class to provide the actual time measurement (how I did it in NetEXT) or I could do it like the rest of the binding and use the native Clock and Time classes. Let me know if anyone has any suggestions, but I am leaning towards using SFML's native classes for implementing the classes.