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
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.
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() 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!"
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.
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.
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.
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].
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 selectionSound recorder processing interval -
CSFML fixedFont info -
CSFML PR made- operator for Color -
fixedRect negative dimensions -
fixedUp vector in the Listener class -
CSFML fixedJoystick info - product id and vendor idDocumentation notes about coordinates and distorted rendering -
fixedSome documentation updates about the Shape classes -
fixedBlend mode changes -
fixed