When updating and debugging to make sure all is well, I realized that only the release CSFML dlls were being used, making debugging a little more annoying. I fixed this by adding a (internal) CSFML class to each module (ie: SFML.Graphics.CSFML, etc) that contains an internal const string with the name of the CSFML dll to be used. It's value is determined by an #if !DEBUG switch. This allows the CSFML debug dlls to be loaded in debug mode, and vice versa in release mode.This means that we have to ship the Debug version of CSFML with SFML.Net, right?
I moved the Context class to the Window module, to match up with SFML and CSFML (it was in Graphics). Side-Effects: had to be made public, which I felt was okay, due to Context being publically available in both SFML and CSFML. More uniform APIs, essentially.Fine. I have no idea why it was different in first place.
Null-Conditional operator usage. This feature is tied to the C# 6.0 compiler, not to a .NET version. So it works when compiling SFML.NET for .NET 3.5 (with VS 2015, at least). I wasn't sure if the targeted support version was for Visual Studio (C# compiler) or .NET, hence my question on this.No need to make the internal code depend on new language features when it changes nothing for the end user, and only restricts the environments where SFML.Net can be compiled.
Style-wise, SFML.NET used two different namespace styles:Yes, the second one looks better :)
First, I think it would be cleaner if 2.4 update and style changes were in two different PRs. Even more if those style changes are unrelated to each other.Agreed. I'll split the changes.
This means that we have to ship the Debug version of CSFML with SFML.Net, right?Yes, debug versions of CSFML would need to be shipped as well. I expect this isn't necessarily desired, so another thought I had was to have another macro definition, to enable/disable this behavior, so only those who want it (library developers, etc) would need to worry about debug versions of CSFML.
And the convention is to name constants in CamelCase, not in UPPER_CASE (so it should be DllName). "Dll" might also be too Windows-specific, since on other OSes we'll load dylib or so files.Will fix. True, I guess I was in .NET mode. :) How about NativeLib or NativeLibName?
No need to make the internal code depend on new language features when it changes nothing for the end user, and only restricts the environments where SFML.Net can be compiled.Will revert.
another thought I had was to have another macro definition, to enable/disable this behaviorSo people who want the debug CSFML libraries must recompile SFML.Net with this macro defined?
How about NativeLib or NativeLibName?NativeLib looks good.
Testing! Try it out, use it, and respond with any feedback you have!
If you can provide binaries, dabbertorres, I think it would be about time to just put them out there and if issues arise one can always fix them. ;)Yeah, I can do that, can I assume creating the same exact package as the last release will do? (with updated binaries of course)
No need to make the internal code depend on new language features when it changes nothing for the end user, and only restricts the environments where SFML.Net can be compiled.
They are in the SFML (C++) repository/packages, you don't have to generate them.So what am I supposed to do? I came to the point that I download https://github.com/dabbertorres/SFML.Net/tree/2.4 (https://github.com/dabbertorres/SFML.Net/tree/2.4) and open SFML.Net/build/vc2010/SFML.net.sln in visual studio. Then build the project and I get dll's but then what? If i just add them as reference to new project it just't won't work, I get communicate that "Application is in break mode".
You should have 2 sets of DLL's in the same directory; the .NET DLL's and the CSFML DLL's.Yeah I should but I don't :). I have no idea how to get those extlibs, I went probably through all .rar files on https://www.sfml-dev.org I even tried to build csfml with cmake but it's not going to work. Nothing looks like extlibs in 2.2 C# binding. Now I feel that I have no idea how all of it works and I wasted so much time that I give up. I will learn "pure" opengl because it's much easier that making sfml run. Thanks for trying to help anyway.