SFML.NET 2.4 Update

[dabbertorres]

Branch: https://github.com/dabbertorres/SFML.NET/tree/2.4

I made a few architecture/style changes that I wanted to make sure were discussed and accepted/not-accepted before submitting a PR.

The major things:

• 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.
• 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.
• 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.
• Style-wise, SFML.NET used two different namespace styles:

namespace SFML
{
    namespace Graphics
    {
        ....

vs

namespace SFML.Graphics
{
    ....

I normalized it all to the second, as I find it to be a nice feature (I'd like C++17 to get it).

Comments, questions, concerns?

[Laurent]

Hi

Thanks a lot for your help

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.

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?
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.

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

[dabbertorres]

Happy to help!

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.
ie:
#if !(DEBUG && SFML_NET_USE_NATIVE_DEBUG)
Best of both worlds, I think.
Now that I'm thinking about it again, do you think this should be a separate PR as well?

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.

[Laurent]

another thought I had was to have another macro definition, to enable/disable this behavior

So people who want the debug CSFML libraries must recompile SFML.Net with this macro defined?
My turn to suggest something: would it be possible (and not too weird) to use the debug DLLs only if they exist, based on a runtime check, and fallback to release DLLs if they are not there?

How about NativeLib or NativeLibName?

NativeLib looks good.

[dabbertorres]

Correct. It's at least nicer than manually changing all the library names. Plus, SFML.NET compiles relatively quickly.
But I do understand why it may not be desirable.

Yes, I believe it is possible (quick Google search confirms this). It'd boil down to using the OS-specific library loading functions (LoadLibrary/GetProcAddress and dlopen/dlsym). It's not complicated by any means, but I'm not certain if it is worth it or not.

(Side note: OSX and Linux both using dlopen/dlsym simplifies things)

[dabbertorres]

Bump @Laurent.

Any more thoughts? Should I leave this out for now, and just make PRs for the 2.4 update and the style changes?

edit:
2.4 Update
I'll wait to make a PR for the style changes once the 2.4 update is merged, since it is based on my 2.4 branch.

[kazyamof]

So, will be available the 2.4 version on the main SFML webpage?
I only see the 2.2 version.

@Laurent

[kazyamof]

UP!

[Laurent]

The current master is supposed to be 2.4, but we lack people to test it and build a release. Feel free to help

[kazyamof]

What about the extlibs folder? Should be updated too? And how?

[Laurent]

The extlibs should be updated too, of course. CSFML DLLs must be updated to 2.4, openal32.dll must be the same as in SFML 2.4, and libsndfile.dll is no longer used.

[DarkDino]

Please publish the 2.4 update for .NET ;o;

[[R]Viper]

Is there a way I can help with the 2.4 release?

[dabbertorres]

Testing! Try it out, use it, and respond with any feedback you have!

[eXpl0it3r]

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.