Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFML.NET 2.4 Update  (Read 18267 times)

0 Members and 1 Guest are viewing this topic.

dabbertorres

  • Hero Member
  • *****
  • Posts: 506
    • View Profile
    • website/blog
SFML.NET 2.4 Update
« on: October 03, 2016, 10:58:56 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML.NET 2.4 Update
« Reply #1 on: October 04, 2016, 06:07:33 pm »
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.

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

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

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

Quote
Style-wise, SFML.NET used two different namespace styles:
Yes, the second one looks better :)
Laurent Gomila - SFML developer

dabbertorres

  • Hero Member
  • *****
  • Posts: 506
    • View Profile
    • website/blog
Re: SFML.NET 2.4 Update
« Reply #2 on: October 05, 2016, 06:45:33 pm »
Happy to help!

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

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

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

Quote
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML.NET 2.4 Update
« Reply #3 on: October 05, 2016, 08:13:33 pm »
Quote
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?

Quote
How about NativeLib or NativeLibName?
NativeLib looks good.
Laurent Gomila - SFML developer

dabbertorres

  • Hero Member
  • *****
  • Posts: 506
    • View Profile
    • website/blog
Re: SFML.NET 2.4 Update
« Reply #4 on: October 05, 2016, 11:09:13 pm »
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

  • Hero Member
  • *****
  • Posts: 506
    • View Profile
    • website/blog
Re: SFML.NET 2.4 Update
« Reply #5 on: October 13, 2016, 11:45:53 pm »
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.
« Last Edit: October 14, 2016, 01:21:39 am by dabbertorres »

kazyamof

  • Newbie
  • *
  • Posts: 15
    • View Profile
    • Email
Re: SFML.NET 2.4 Update
« Reply #6 on: February 03, 2017, 06:15:05 pm »
So, will be available the 2.4 version on the main SFML webpage?
I only see the 2.2 version.

@Laurent
« Last Edit: March 30, 2017, 05:17:35 am by kazyamof »

kazyamof

  • Newbie
  • *
  • Posts: 15
    • View Profile
    • Email
Re: SFML.NET 2.4 Update
« Reply #7 on: March 30, 2017, 05:35:59 am »
UP!

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML.NET 2.4 Update
« Reply #8 on: March 30, 2017, 06:29:29 am »
The current master is supposed to be 2.4, but we lack people to test it and build a release. Feel free to help :)
Laurent Gomila - SFML developer

kazyamof

  • Newbie
  • *
  • Posts: 15
    • View Profile
    • Email
Re: SFML.NET 2.4 Update
« Reply #9 on: March 30, 2017, 07:07:37 am »
What about the extlibs folder? Should be updated too? And how?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML.NET 2.4 Update
« Reply #10 on: March 30, 2017, 08:35:22 am »
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.
Laurent Gomila - SFML developer

DarkDino

  • Newbie
  • *
  • Posts: 5
    • View Profile
    • Email
Re: SFML.NET 2.4 Update
« Reply #11 on: May 11, 2017, 07:29:52 am »
Please publish the 2.4 update for .NET ;o;

[R]Viper

  • Newbie
  • *
  • Posts: 27
    • View Profile
Re: SFML.NET 2.4 Update
« Reply #12 on: June 19, 2017, 10:38:46 pm »
Is there a way I can help with the 2.4 release?
« Last Edit: June 19, 2017, 10:42:13 pm by [R]Viper »

dabbertorres

  • Hero Member
  • *****
  • Posts: 506
    • View Profile
    • website/blog
Re: SFML.NET 2.4 Update
« Reply #13 on: June 20, 2017, 04:33:21 am »
Testing! Try it out, use it, and respond with any feedback you have!

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10801
    • View Profile
    • development blog
    • Email
Re: SFML.NET 2.4 Update
« Reply #14 on: June 20, 2017, 10:59:12 am »
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. ;)
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

 

anything