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

Author Topic: SFML.NET Proposed Changes  (Read 26360 times)

0 Members and 1 Guest are viewing this topic.

zsbzsb

  • Hero Member
  • *****
  • Posts: 1409
  • Active Maintainer of CSFML/SFML.NET
    • View Profile
    • My little corner...
    • Email
SFML.NET Proposed Changes
« on: April 22, 2014, 03:21:17 am »
I talked to Laurent about updating SFML.NET and making some changes. He suggested I post a list of proposed changes so we can discuss them before I start making pull requests. If anyone has any suggestions or ideas please post them here.

Project Files
  • Add project files that match VS 2010, VS 2012, and VS 2013 - instead look at a possible meta-build system

SFML.Window
  • Explicit vector casting (PR #28) - fixed
  • Define Equals() overrides for vectors - fixed

SFML.Graphics
  • Color == and != comparision (PR #29) - fixed
  • Window.IsOpen() should be a property (Issue #23) - fixed
  • Shape.GetPointCount() and Shape.SetPointCount() should be a property [including classes derived from Shape] - needs to be discussed
  • Add indexed property for Shape points - and then possibly remove Shape.GetPoint() and Shape.SetPoint() [including classes derived from Shape] - decided against
  • Add indexed property for Image pixels - and possibly remove Image.GetPixel() and Image.SetPixel() - decided against
  • RenderTarget.GetView() and RenderTarget.SetView() should be a property [including derived classes] - should be discussed
  • RenderWindow.InternalSetMousePosition() and RenderWindow.InternalGetMousePosition() should be removed - fixed
  • VertexArray.GetBounds() should be a property - fixed
  • Transform.ToString() produces wrong results (Issue #34) - fixed
  • Investigate Issue #5
  • Investigate Issue #25
  • Investigate PR #23 - fixed
  • CSFML and SFML.NET updates to match C++ version of SFML - see the end of this post for full list
  • OpenTK Support

SFML.System
  • Add Time and Clock classes - yes the .NET/Mono framework provides System.Diagnostics.Stopwatch but it can not provide high resolution without conversion from the Ticks property and this can be cumbersome to use - done
  • Move Vector2 struct to SFML.System (from SFML.Window) - done
  • Move Vector3 struct to SFML.System (from SFML.Audio) - done
  • Move ObjectBase to this module - done
  • Add support for redirecting error output
« Last Edit: June 09, 2014, 02:13:48 am by zsbzsb »
Motion / MotionNET - Complete video / audio playback for SFML / SFML.NET

NetEXT - An SFML.NET Extension Library based on Thor

StormWingDelta

  • Sr. Member
  • ****
  • Posts: 365
    • View Profile
Re: SFML.NET Proposed Changes
« Reply #1 on: April 22, 2014, 03:51:46 am »
I'd be happier with a networking class for both TCP and UDP making the existing .net ones easier to use. :)
I have many ideas but need the help of others to find way to make use of them.

smpsnr

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: SFML.NET Proposed Changes
« Reply #2 on: April 22, 2014, 07:25:21 am »
Add support for OpenTK. Tao is from 2005! I've seen some old threads suggesting that it's possible to use OpenTK with SFML 1.6, but the solutions are all hacky and I've never been able to get it to work with 2.0.

In my opinion this is the biggest thing holding SFML.NET back.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML.NET Proposed Changes
« Reply #3 on: April 22, 2014, 11:04:59 am »
I'll comment some of the points listed, you can consider the others validated.

Quote
Add project files that match VS 2010, VS 2012, and VS 2013
Why? It would make maintenance of project files 4 times longer. Anyone can convert the project files to his version of the IDE, as long as we provide projects in VS 2008 format (Visual Studio cannot do backward conversion).
What would be great is a meta-build system, like CMake for the C++ library. I don't know if such a system exists for .Net (and that would be compatible with the Mono IDEs).

Quote
Add indexed property for Shape points - and then possibly remove Shape.GetPoint() and Shape.SetPoint() [including classes derived from Shape]
Add indexed property for Image pixels - and possibly remove Image.GetPixel() and Image.SetPixel()
How would the new API look? Wouldn't it differ too much from the C++ API?

Quote
RenderWindow.InternalSetMousePosition() and RenderWindow.InternalGetMousePosition() are not used and should be removed
Really? I created them on purpose, I would be surprised if they were not used. But I remember that soon after I pushed this code, I found a less ugly way of doing it; and didn't came back to implement it.

Quote
When the blend modes branch gets merged to master update CSFML and SFML.NET
The commits in SFML since the last release should be reviewed, and any modification to the pubic API should be made into CSFML and SFML.Net too.

Quote
SFML.System
Hmm... are you really sure that the .Net SDK doesn't provide anything equivalent to the Time and Clock classes?
Providing an incomplete System module would be confusing (and I don't want to provide the threading classes).

Quote
I'd be happier with a networking class for both TCP and UDP making the existing .net ones easier to use.
The .Net framework already has everything that you need for manipulating TCP and UDP sockets.

Quote
Add support for OpenTK. Tao is from 2005!
True! :)
Laurent Gomila - SFML developer

zsbzsb

  • Hero Member
  • *****
  • Posts: 1409
  • Active Maintainer of CSFML/SFML.NET
    • View Profile
    • My little corner...
    • Email
Re: SFML.NET Proposed Changes
« Reply #4 on: April 23, 2014, 12:23:33 am »
Quote
Why? It would make maintenance of project files 4 times longer. Anyone can convert the project files to his version of the IDE, as long as we provide projects in VS 2008 format (Visual Studio cannot do backward conversion).

True, I didn't think of that point. Its just slightly annoying to use the auto upgrade  :P

Quote
What would be great is a meta-build system, like CMake for the C++ library. I don't know if such a system exists for .Net (and that would be compatible with the Mono IDEs).

There is some build systems out there, and if they can run on linux all Mono IDEs support the VS *.csproj format. I could take a closer look to see if any of them match what we are trying to do.

Quote
How would the new API look? Wouldn't it differ too much from the C++ API?

I'm not too sure on these changes, I was more or less thinking out loud. .NET/Mono framework conventions is to avoid writing getters and setters and instead use properties. However there is nothing wrong with using a getter/setter if you wish to be more expressive. An indexed property is the same type of property that is implemented on the VertexArray class to give access to vertices. So it would look like the following.

using SFML.Graphics;
var myshape = new ConvexShape();
myshape.PointCount = 4; // this would be a new property instead of SetPointCount()
myshape[0] = new Vector2f(50.0f, 100.0f); // and this would be the indexed property for points instead of SetPoint()

Quote
Really? I created them on purpose, I would be surprised if they were not used. But I remember that soon after I pushed this code, I found a less ugly way of doing it; and didn't came back to implement it.

Oops, I guess I failed on my search for any usage locations. They are currently used in a single location each and it would be trivial to refactor that usage out. On the plus note, there won't be a need for a public function that the documentation reads "warning: do not touch me!"  :D

Quote
The commits in SFML since the last release should be reviewed, and any modification to the pubic API should be made into CSFML and SFML.Net too.

Yep, I forgot about some commits so I went through the commit log and at the end of this post you will find things that should make it into CSFML and SFML.NET.

Quote
Hmm... are you really sure that the .Net SDK doesn't provide anything equivalent to the Time and Clock classes?

There is a TimeSpan class, but it is neither high resolution or very accurate. The System.Timers namespace can only provide at best a resolution 15ms. And if the user uncaps the framerate above 60fps you will run into timing issues.

The only way to get a true high resolution timer in C# is with System.Diagnostics.Stopwatch. However this class only provides a way to measure time and return the value in ticks. So its left to the user to convert the ticks (based on the clock frequency) to whatever measurement of time they wish. This is the reason I implemented the Time and Clock classes in NetEXT as a way to provide easy measurement just like the C++ version of SFML does.

Quote
Providing an incomplete System module would be confusing (and I don't want to provide the threading classes).

I agree about it being confusing, but I think the current state is already slightly confusing. With the vector structs spread into the graphics and audio modules and no system module at all. About threading... isn't the plan to drop sf::Thread anyways and go with C++11 threading features?

With a system module we could also implement sf::err and also move the ObjectBase class into the system module. Instead of making the audio module depend on the window module for the base class.

Quote
I'd be happier with a networking class for both TCP and UDP making the existing .net ones easier to use.

As Laurent said, the .NET/Mono framework implementations are already much nicer and feature rich than what SFML provides. Not to mention the built in asynchronous functions [multithreading networking out of the box].  ;)

Quote
Add support for OpenTK.

Sounds like a good plan.  :)



Here is the changes that SFML.NET and/or CSFML are behind on.
Audio capture device selection
Sound recorder processing interval - CSFML fixed
Font info - CSFML PR made
- operator for Color - fixed
Rect negative dimensions - fixed
Up vector in the Listener class - CSFML fixed
Joystick info - product id and vendor id
Documentation notes about coordinates and distorted rendering - fixed
Some documentation updates about the Shape classes - fixed
Blend mode changes - fixed
« Last Edit: September 06, 2014, 04:27:43 pm by zsbzsb »
Motion / MotionNET - Complete video / audio playback for SFML / SFML.NET

NetEXT - An SFML.NET Extension Library based on Thor

rcurtis

  • Newbie
  • *
  • Posts: 19
    • View Profile
Re: SFML.NET Proposed Changes
« Reply #5 on: April 23, 2014, 12:41:07 am »
Most of these getter-to-property conversions sound reasonable.  I am currently using the NetEXT timer classes for everything I need, so no protest against them.  The biggest thing in the list for me was the inclusion of OpenTK.  Great list Zachariah!

-Robert

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML.NET Proposed Changes
« Reply #6 on: April 23, 2014, 07:54:47 am »
Quote
I'm not too sure on these changes, I was more or less thinking out loud. .NET/Mono framework conventions is to avoid writing getters and setters and instead use properties. However there is nothing wrong with using a getter/setter if you wish to be more expressive. An indexed property is the same type of property that is implemented on the VertexArray class to give access to vertices.
Since this is also possible in C++, if it's not done in SFML, I'd say don't do it in SFML.Net ;)

Quote
I agree about it being confusing, but I think the current state is already slightly confusing. With the vector structs spread into the graphics and audio modules and no system module at all. About threading... isn't the plan to drop sf::Thread anyways and go with C++11 threading features?

With a system module we could also implement sf::err and also move the ObjectBase class into the system module. Instead of making the audio module depend on the window module for the base class.
Good points. So let's go with the System module :)
Laurent Gomila - SFML developer

Deathbeam

  • Jr. Member
  • **
  • Posts: 82
  • VB6, VB.NET, C#, HTML, PHP, CSS, JavaScript nerd.
    • View Profile
    • My portfolio
    • Email
Re: SFML.NET Proposed Changes
« Reply #7 on: April 23, 2014, 02:55:51 pm »
So these changes will be mostly around making our lives easier by using properties? Sounds nice :)
Btw IntRect, FloatRect and so are not related to graphics too imo, so why do not move them too to SFML.System?
« Last Edit: April 23, 2014, 03:12:39 pm by Deathbeam »
Spooker Framework - Open source gaming library
My portfolio
Indie Armory - Small community of a game developers. Everyone is welcome. Bring your friends, family, pets...

zsbzsb

  • Hero Member
  • *****
  • Posts: 1409
  • Active Maintainer of CSFML/SFML.NET
    • View Profile
    • My little corner...
    • Email
Re: SFML.NET Proposed Changes
« Reply #8 on: April 23, 2014, 03:48:15 pm »
Btw IntRect, FloatRect and so are not related to graphics too imo, so why do not move them too to SFML.System?

Well that would be something to bring up in a discussion about the actual SFML implementation (C++ version). And if that was to happen, it most likely wouldn't happen until SFML 3 due to the fact it breaks existing code.
http://sfml-dev.org/documentation/2.0/group__graphics.php
Motion / MotionNET - Complete video / audio playback for SFML / SFML.NET

NetEXT - An SFML.NET Extension Library based on Thor

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: SFML.NET Proposed Changes
« Reply #9 on: April 23, 2014, 07:15:43 pm »
You're not the only one with this suggestion, it has already been discussed. Everybody seemed to agree at that time, so it's likely that sf::Rect will be moved to the System module in SFML 3 -- but not before, as zsbzsb says.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML.NET Proposed Changes
« Reply #10 on: April 23, 2014, 09:36:57 pm »
Quote
Everybody seemed to agree at that time
Are you sure? :P
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: SFML.NET Proposed Changes
« Reply #11 on: April 23, 2014, 09:48:39 pm »
You were hesitant, but in the end you didn't say anything against it anymore -- thus "seemed" :P but now that I read the thread again, I see that I completely missed Disch's answer.

Anyway, it would be discussed again, but I think until SFML 3 there are a few more important tasks ;)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML.NET Proposed Changes
« Reply #12 on: April 23, 2014, 10:54:23 pm »
Yep.
Laurent Gomila - SFML developer

smpsnr

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: SFML.NET Proposed Changes
« Reply #13 on: April 24, 2014, 07:45:32 am »
I'm glad that people are on board with OpenTK support!

Another thought - On Linux, XInitThreads from libX11 must be called for OpenGL windows to work properly. If possible this should happen in the background.

In general, better documentation of running SFML.NET on Mono is needed. Perhaps cross-platform versions of certain methods that differ between Mono and .NET could be added to the System module? For instance, on Mac and Linux System.Environment.ProcessorCount returns the number of physical processors, but on Windows it returns the number of logical processors.
« Last Edit: April 24, 2014, 07:49:57 am by smpsnr »

Deathbeam

  • Jr. Member
  • **
  • Posts: 82
  • VB6, VB.NET, C#, HTML, PHP, CSS, JavaScript nerd.
    • View Profile
    • My portfolio
    • Email
Re: SFML.NET Proposed Changes
« Reply #14 on: April 24, 2014, 07:49:27 am »
I'm glad that people are on board with OpenTK support!

Another thought - On Linux, XInitThreads from libX11 must be called for OpenGL windows to work properly. If possible this should happen in the background.

In general, better documentation of running SFML.NET on Mono is needed.

Running SFML.NET on Mono? What more documentation do you need to do that? It is already childish simple :)
Spooker Framework - Open source gaming library
My portfolio
Indie Armory - Small community of a game developers. Everyone is welcome. Bring your friends, family, pets...

 

anything