Port for .NET

Would you be interested in having a .NET port developed for Spark? I'm interested in working on one, as a good GL/SFML particle system for .NET is very hard to come across these days, and I like the way Spark handles things; I'd need a lot of support from the programmer(s) for conversion though, as there are a few things (mostly container usage) in the source that I would need a bit of explanation on.

-P

Hi, a port for .NET would be interested indeed. However the best would be to port directly SPARK 2 rather than SPARK 1. Even though SPARK 2 is not released yet and not fully finalized, the core works very well and is nearly ready to be released (still have some doc, demos and extensions classes to implement though). There is no rendering module for SFML yet as I am waiting for SFML 2 before designing it.

I am concentrating my effort on SPARK 2 now and will only make maintenance release for SPARK 1. So if you want to port the engine to .NET dont do it with a version that will be deprecated soon.

And I can give you support of course and any explanation you ll need about the implementation.

PS : I assume you know it is not an easy task and you have a good level in .NET and some knowledge in C++.

I am very fluent in both C# and C++; I mainly work with C++ actually, but I prefer C#'s language features and focus on OO rather than the mix of paradigms in C++. I've been using C# for game design lately (not XNA, because XNA sucks), and with Visual Studio's extra intellisense support in C# and the way references work it becomes much easier to manage things than it does with C++.

I had already looked through SPARK 1's codebase and most of it would be rather easy to port; the problematic areas are multiple inheritence that I saw in a few places that .NET lacks, so we'd have to come up with alternatives for that, and I'm pretty sure I saw you use container reserving, a feature that no base .NET container has. It's mostly small library-dependent things that will have to be changed a bit.

Will do, I'll wait for you to finalize up SPARK 2 before anything gets started.

EDIT: If you use any instant messengers we can discuss it further on there and possibly go over some of the problems and think of solutions before any of the actual coding work begins.

-P

Yes I use multi inheritance in SPARK for both polymorphism and code sharing. Basically I use abstract classes that define an interface, a base behaviour and the data needed. A possible way to do that in C# would be to use interfaces (I dont know C# well but it has java-like interface I think) and implementation classes. You mix the interface and compose the implementation in the class which basically acts as a bridge.

In that way you ll have the same behaviour :

• polymorphism via interface
  
• data sharing via the implementation
  
• base behaviour via the implementation
  
• code overriding possible in the method definition of the implemented interface
  

The only thing is that for a given abstract class in C++ you ll get a couple of interface / implementation class in C# and then have to link interface to implementation in the class that implements the interface (the bridge), so a little more code.

For space reserving in container, it is only a detail for memory optimization and it is not use anymore in SPARK 2 anyway.

My main concern regarding a .NET port is about performance. I know it is a endless debate i dont want to take part in but my code relies a lot on well organized data for cache, non virtual methods inlining, template generation... Some stuff that are generally not always compatible with a VM.

On the other hand, the life time of objects will be a lot easier to manage in C#. In my code I force dynamic creation of instances in most class and have a reference counting mechanism for deletation. All of these wont be needed in a C# port.

Regarding the messenger, yes I got msn but are we on a compatible time zone ? I am currently in Paris (GMT +1)

The time that I stay up changes often, so sometimes we will be in a compatible timezone and sometimes we won't :p
I'm in Ontario (EST).

Yeah, interfaces in C# are basically just pure virtual classes (they can't contain any non-abstract members) that act as "implications" that a class has a certain function/property; aside from that, usage-wise they act the same as classes, and it has normal classes and what-not.

.NET has actually come a long way from it's roots; game development using C# is growing very quickly (especially due to XNA and Xbox 360 support), and the gap between native code speed and the CLI is shortening. A very recent example is Sol Survivor, a game released exclusively on Steam, written entirely in .NET/XNA. Another good library example would be Box2DX, the C# version of Box2D; while it has never been benchmarked directly, the demo framework thing has been ported, and running-wise if you push the limits (like by holding the spawn button) they seem to run at about the exact same speed.

I do agree, however, on template generation; templates in .NET are deduced at runtime (which makes them a pain in the ass to use since you are VERY limited with them).

Anyway, as you said, I don't want to get into a big debate about it either, the point is I am hoping that a .NET version will prove useful for SPARK; I for one really want to use this particle engine. I can't seem to find any other good lightweight particle engines that would easily port to .NET, and from the demos I saw SPARK is exactly what I am looking for interface-wise, and I'm sure everyone else who uses SPARK feels the same way

You can add my MSN: paril@alteredsoftworks.com

-P

Ok i gonna add you.

I dont have a lot of time these days and I dont connect to msn very often so if you have some questions and dont see me connected, dont hesitate to post them here.

PS : I move this topic in the evolution section.

Alrighty, will do.

-P