Messages

1

DotNet / Re: Is there any guide for SFML for beginners, for c #?

« on: August 11, 2020, 07:03:32 pm »

I'm not aware of a C# specific guide using SFML. The next closest thing I know is probably the code examples on github. https://github.com/SFML/SFML.Net/tree/master/examples

The existing SFML tutorials for C++ can be followed and compared with the C# example code. Obviously they have differences but the library usage is generally the same.

2

DotNet / Re: Is it bad practice to subclass primitives like Text?

« on: July 20, 2020, 11:35:19 pm »

sorry to necro this thread but I think this requires an answer.

I do recommend composition but SFML.Net classes do have the facility for inheritable dispose calls. It follows the documented disposal pattern but for whatever reason SFML.Net doesn’t follow the actual naming convention.

You want to override the Destroy function and add your dispose calls there, don’t forget to call base afterwards.

As you found you should NEVER method hide dispose with the new keyword as you run the risk of the “new” Dispose function not actually getting executed as it’s a non-virtual override for lack of a better term.

protected override void Destroy(bool disposing)
{
    _clock.Dispose();
    base.Destroy(disposing);
}
 

3

DotNet / Re: Drop .NET Framework in favor of .NET Core?

« on: September 02, 2018, 02:04:47 am »

hey eXpl0it3r

I've been using SFML.NET to develop a game for the last few months and will be continuing through to late next year so despite being a little late to this discussion i'll provide my two cents.

As someone who is still using .NET Framework I will confirm SFML should be moved to .NET Standard as this assures its compatibility with the various CLR platforms (.NET Core and .NET Framework). For as long as SFML.NET only relies on whats available under .NET Standard there shouldn't be any compatibility concerns and means you don't necessarily need to keep a .NET Framework branch for legacy reasons.

A note to why i'm still using .NET Framework (other than its what SFML currently provides) as it may clear up some concern for this migration.

.NET Core the main CLR platform at discussion here was initially made for console application development in the cloud which really doesn't fit with where SFML gets used. As a result certain namespaces for UI and basic graphics/imaging in .NET Framework aren't available in .NET Core without 3rd party support.
I so happen to be using these namespaces (e.g WinForms and Drawing namespaces) and cross platform isn't a big priority for me at this time.

I want to point out the upcoming .NET Core 3 looks to potentially add what i'm using anyway to help those such as myself move from .NET Framework to .NET Core as that is the preferred platform choice for the future.

https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/


I can't think of any other real reason at this current time why you might stick with .NET Framework and so its reasonable to see SFML.NET move forward as a .NET Standard library.