Messages

1

DotNet / Re: SFML.Net Core???

« on: July 16, 2020, 05:22:37 pm »

That's a pretty old thread you revived here 8Observer8  ,
I don't want to sound mean but let's not do that anymore it confuse people, like this post was originally because SFML.NET didn't support .Net Core in 2016 (and subsequently me saying I did a PR for it) and now it's slowly transforming into a .Net Core catch all/ debug post/thread. which should be there own standalone post to allow for easier navigation/ answer finding and google indexing of problem/answer

SO PLEASE IF YOU'RE ABOUT TO ADD TO THIS POST CONSIDER CREATING A NEW ONE INSTEAD, CONSIDER THIS ONE CLOSED

2

DotNet / Re: SFML on Linux with MonoDevelop

« on: February 17, 2020, 04:20:50 am »

I know it's not answering exactly your question but here's what I would recommend. The easiest way would be to use .net core instead of mono. Since you are starting from scratch it shouldn't be that difficult and .net core is faster than mono. The mapping of the .so is done for you and I think the only thing you might need to do is copy paste the right version of the CSFML libraries next to your executable (It might also do it automatically, just try building and running and if it doesn't find CSFML then that means you need to manually copy them)

3

General / Re: HI, i need help with SFML

« on: December 09, 2019, 05:41:36 am »

Just to make sure, you followed this tutorial?
https://www.sfml-dev.org/tutorials/2.5/start-vc.php

I just redid the tutorial steps and it worked for me.

It's ok to be lost when starting in programming, what part of the tutorial you have trouble with or doesn't work for you?
If you did the dynamic linking, did you maybe forget to copy the right dll to the output directory?

4

DotNet / Re: unable to load DLL error in csharp

« on: December 07, 2019, 12:45:59 am »

I'm guessing you're making a .Net Framework project... it's a known bug. I would suggest you try a .net core project instead it also has support for linux and macos natively and doesn't require that workaround... (Except for macos... For now...)
Also usually .net core is faster than .Net Framework

And don't forget to share your final game with us!

5

DotNet / Re: Can't seem to get SFML C# running on Mac

« on: June 14, 2019, 05:27:12 pm »

Make sure csfml-graphics.dylib is copied to the output directory (beside your main executable) it should be automatic from the nuget package.
I know for a fact that on linux there's a similar problem but it's based on how the system search for shared libraries, the default location doesn't include what's beside the executable.
Just for the record, on linux you can either do :
export LD_LIBRARY_PATH="your/app/path/"

LD_LIBRARY_PATH is not recommended for production, only for dev.
For prod you should install the good versions of the csfml libs from your package manager, or copy the ones that are beside the executable to one of the system default libraries folders

So check that the lib are there, and I think I saw something similar to LD_LIBRARY_PATH for mac
Edit:
Found this forum post that should fix your problem
https://en.sfml-dev.org/forums/index.php?topic=24990.msg166468#msg166468

6

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

« on: August 14, 2018, 02:47:59 pm »

I think we should support .Net Standard 2.0 only, this will allow for .Net Core 2.0 and .Net Framework 4.6.2-4.7 support. As for the advantages of .Net Core 2.0 see those incredible blog post from Microsoft about the performance upgrade of .Net Core :
https://blogs.msdn.microsoft.com/dotnet/2017/06/07/performance-improvements-in-net-core/
https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performance-improvements-in-net-core-2-1/

Finally, I think that sticking with .Net Standard 2.0 should last us for a while, because up to now, Microsoft kept all of their .Net Standards retro compatible. And in the event that isn't the case we will act according to the information that will be available at that time.

7

DotNet / Re: What should be the criteria for .Net Core Merge? (Community Input)

« on: November 28, 2017, 03:16:15 am »

The existing codebase are not directly compatible because .Net Standard 2.0 require at least .Net Framework 4.6.1 or .Net core  2.0

Advantages of using .Net Standard 2.0 is native compatibility with Windows, Linux, MacOS... (And more?). Also .Net Core is faster then .Net Framework https://blogs.msdn.microsoft.com/dotnet/2017/06/07/performance-improvements-in-net-core/
.Net Core is also Open Source so it cannot be shutdown because a company decided to do so.

The only downside is that existing project will need to update the Framework version they target so they can use the latest SFML.Net. Also not every .Net Framework API have been ported, but i would say that only very obscur/not used a lot/windows related APIs are missing (the only one that was really missing for the SFML.Net conversion was introduced in .Net Standard 2.0 and it's a very specific API to manage memory ressources if i remember correctly)
Another "downside" is that OpenTK is not on .Net Standard yet (they are planning to in the future) it's not really a direct downside because it's not something we maintain and we still expose everything so it can work, but it will prevent interaction with OpenGL until then.

Also Microsoft is really showing that .Net Core is the new Standard for .Net, so we kind of need, in my opinion, to offer a .Net Standard library if we want to stay relevant in the future.

Finally a good place to get more info is this forum post where we discuss if we wait for .Net Standard 2.0 or not https://en.sfml-dev.org/forums/index.php?topic=22150.0
And the actual pull request https://github.com/SFML/SFML.Net/pull/143

8

DotNet / What should be the criteria for .Net Core Merge? (Community Input)

« on: November 22, 2017, 10:19:48 pm »

Since the PR has been open for a couple of month, i would like to know what should be the criteria to merge the PR?
https://github.com/SFML/SFML.Net/pull/143
Exemples :

• Works on Windows, Mac, Linux
• Works/tested on Windows ONLY (same as current repo?)
• Works on Windows, Linux (because we cannot test Mac?)
• ...

Please feel free to express your opinion!!!

TL;DR of PR

• Make SFML.Net work with .Net Core 2.0
• Native Windows, Linux, Mac support (.Net Core 2.0)
• Exemples in the repo using OpenTK (OpenGL in C#) are broken because OpenTK hasn't been ported to .Net Core (we might leave 1 OpenGL exemple "broken" until the OpenTK team port to .Net Core and clean up other exemples using it)
• The PR has been tested on Windows and Ubuntu 16.04 (please feel free to test other OS, distro and architecture like ARM...)

9

DotNet / Re: SFML.Net on Xamarin.Android

« on: November 08, 2017, 10:59:47 pm »

I think you cannot use the Linux binaries because they are compiled for x86/x64 and most device running Android run on ARM, you should recompile csfml for ARM (there might be more than one possible target)

Also i think Android use the file system in a weird way (sandboxing), check where your app is looking for your .so, maybe you need to provide info so it can be found?

10

DotNet / Re: .Net Core Real Talk

« on: August 07, 2017, 07:14:54 pm »

I agree that .Net Standard is the ideal target for a Library only, but we also have to maintain the exemples which cannot be .Net Standard (since it's only a rule book and not an implementation) .
So yes we should most definetly target .Net Standard 2.0 for the core binding but the exemples should be targeting .Net Core 2.0

11

DotNet / Re: .Net Core Real Talk

« on: June 27, 2017, 09:47:28 pm »

I spoke with OpenTK people and they are waiting for .Net Core 2.0 too

Expect support fairly soon after netstandard 2.0 is release

Also there's a preferred way to "map" dynamic library name for dllImport https://github.com/dotnet/coreclr/issues/12103

12

DotNet / .Net Core Real Talk

« on: June 22, 2017, 05:21:14 pm »

Hi, there's now 2 PR for a .Net Core conversion to SFML.Net, but one thing people don't seem to understand, is that changing the project to .Net Core has impact on the minimum version of of .Net Framework that will be needed to use SFML.Net (the minimum version will become 4.5+) https://docs.microsoft.com/en-us/dotnet/standard/net-standard#net-platforms-support

Also some things are not yet in for .Net Core like VB support coming in 2.0 https://blogs.msdn.microsoft.com/dotnet/2017/05/10/announcing-net-core-2-0-preview-1/, missing CriticalFinalizerObject (also coming in 2.0) and OpenTK has not been updated to .Net Core yet.


But, on the other side, we would be able to build SFML.Net project that would work on Linux, Mac, Windows, ... all natively, there's also the fact that .Net Core is faster then .Net Framework https://blogs.msdn.microsoft.com/dotnet/2017/06/07/performance-improvements-in-net-core/

Finally... should we change SFML.Net to.Net Core or create a new binding called SFML.Net Core (or something else...because this one might confuse some people)

Please use this post to discuss the matter, it's not an official/sanctioned post but i think it's an healthy discussion to have together.

13

SFML development / Re: Suggestions

« on: March 16, 2017, 08:28:04 pm »

Me again, with an upcoming standard C++ 2d library, when it come out, where will SFML stand? Do we still do our own rendering or do we do a wrapper over the std 2d lib?

14

SFML development / Re: Suggestions

« on: March 16, 2017, 08:16:13 pm »

Another point we could discuss is: Do we want SFML to be friendly with threads? And if yes, to what extend (Vulkan for multithreaded render call?, Only some class being thread safe?, Some methods only being thread safe?)?
Modern applications are using more and more threads either to compute more things faster or to make do of weaker core/clock speed (like phone) .
Again, this just poped in my head while i sended my last post so i haven't been thinking about it for long (like max 5 min.) But i think this could be something we can discuss

15

SFML development / Re: Suggestions

« on: March 16, 2017, 08:04:39 pm »

Maybe we could discuss SFML philosophy for multi platform project. Do we want to provide API for write once for all platforms or do we want to provide an API that can use multiple configuration depending on the platform a good exemple would be do we add vector graphic support? This help having all the same assets per platform/resolution (this is a write once for all platform) or do we want everyone to handle themself multiple image resolutions, audio codec ... (Android and IOS have each prefered resolution / codec)
I haven't fully sized the implication of this, it just poped in my head a minute ago, but right now it's a valid discussion point in my head