SFML.NET Proposed Changes

[Laurent]

It's a binding, so use the C API. I thought you wanted the system module because the native classes were not equivalent?

[zsbzsb]

It's a binding, so use the C API. I thought you wanted the system module because the native classes were not equivalent?

Native classes are not equivalent, that is true. I was talking about the implementation, we could use the C API to implement it (preferred) or implement it using the native System.Diagnostics.Stopwatch class as the internal implementation. The native class provides no easy way to convert the Stopwatch.Ticks property to milliseconds/seconds/minutes as it also relies on the Stopwatch.Frequency property.

Update

I have now made a PR that implements the Time and Clock classes. I went with using the C API as the internal implementation to stay consistent with the rest of the binding.

[krzat]

I have been always using watch.Elapsed.TotalSeconds. Isn't it accurate enough?

[zsbzsb]

I have been always using watch.Elapsed.TotalSeconds. Isn't it accurate enough?

Stopwatch.Elapsed returns a returns a TimeSpan that uses different ticks ratio that is less accurate than directly using the Stopwatch.ElapsedTicks property. Stopwatch ticks are tied to the hardware / platform so you will always get the highest precision available on the running platform.

http://geekswithblogs.net/BlackRabbitCoder/archive/2012/01/12/c.net-little-pitfalls-stopwatch-ticks-are-not-timespan-ticks.aspx

[krzat]

Thanks for the info. In this case, I would just write sw.ElapsedTicks / (float)Stopwatch.Frequency or have extension method for this.

[zsbzsb]

Thanks for the info. In this case, I would just write sw.ElapsedTicks / (float)Stopwatch.Frequency or have extension method for this.

Or download the latest source from the SFML.NET repository as the Time and Clock classes have now been merged. 

[Epiplon]

I'm happy to see this port being pushed forward. 

[Laurent]

I just noticed the Visual Basic example is not up to date (it's drawing text without a font, not using the Time / Clock classes, etc.). Anyone?

[zsbzsb]

Let me download VB.NET Express 2008 and I will have a go at it. 

However, the better question should be - do we really still need a VB.NET example? I mean the language everyone really only seriously uses with .NET/Mono is C# and any VB.NET programmer will be accustomed to converting C# examples to VB.NET. There is even several good and free online converters that will do the work for you. Not to mention, I don't think we have received even one person saying that it is out of date (and it is written using SFML 1.6). I think its obvious what I think we should do, but it is up to you Laurent - so for now I will update it.

[Laurent]

You're right, but since it exists, let's keep it. It's also useful as a compatibility test case for us.

[Frugle]

I don't know if this has been suggested yet but I think implementing IList and IList<T> interfaces for VertexArray would be very useful. With them implemented you could use foreach and LINQ + you get bunch of useful methods. Because VertexArray already has bunch of similar methods it would be wisest to implement the interfaces explicitly.

Now that I think about it, you could probably implement them for Shape too.

[Laurent]

don't know if this has been suggested yet but I think implementing IList and IList<T> interfaces for VertexArray would be very useful. With them implemented you could use foreach and LINQ + you get bunch of useful methods.

Isn't it rather IEnumerable<T>?

[zsbzsb]

I don't know if this has been suggested yet but I think implementing IList and IList<T> interfaces for VertexArray would be very useful.

That wouldn't really be feasible, first it would require implementing methods that even the core SFML doesn't support for the vertex array. And second, there is no smart way to implement Insert(...) and RemoveAt(...) functions. It would just be a big complicated copy operation.

Now that I think about it, you could probably implement them for Shape too.

We already decided that we need the existing design to make it clear the intention of the Shape classes.

Isn't it rather IEnumerable<T>?

It is, so if we want the foreach syntax for the vertex array we could implement this instead of trying to implement other interfaces that don't make sense.

[Frugle]

Isn't it rather IEnumerable<T>?

It is, so if we want the foreach syntax for the vertex array we could implement this instead of trying to implement other interfaces that don't make sense.

This would be okay. IEnumerable<T> gives most of the useful stuff anyway.

[krzat]

Note that VertexArray is slow due to P/Invoke. Maybe we should just reimplement entire thing as a subclass of List<T>.