[Official] Eclipse.NET

[jcsnider]

I understand a bit of c# but I have never really made any huge projects in it… as for c++ I know it is somewhat similar but I have never taken the time to learn anything about it... therefore, just sharing my thoughts, I voted to keep C# as primary and if Jeff really wants to take on two projects, the C++ as secondary. I will download the C++ because I am curious and would like to learn a little about it and its code but right now I am a c# guy. (Unless we are talking VB... damn language continues to spoil me haha.)

[Pikachu]

I voted against porting to C++. Why? Because I do not see the major benefits that would be attained. Sure, it'll be a little bit faster, but so what? XNA and C# is pretty fast as it is, and certainly fast enough to run games that Eclipse produces. Not only that, but since both languages would essentially be using DirectX, the only difference in performance would be with .NET execution.

You already have a good start on the engine, and have gotten through a good chunk of the "hard" parts that I found when I was porting the engine myself (rewriting networking, basic graphics and rendering). If people really want a C++ version, at the very least finish what you've started, then port it to C++.

[Marsh]

I think what it comes down to is that someone will always complain about the library or language choice. Do what you really want to do. Also if you continue to restart a project you will never get anywhere. Sometimes you have to just tough it out. But i mean, do whatever you want to do. c++ would be great aswell. Better? or merely different?

[blkcrow]

I would love to see a C++ engine. Why using directx9 and not SDL since its only 2D and also a lot easier?

[JeffSventora]

> I would love to see a C++ engine. Why using directx9 and not SDL since its only 2D and also a lot easier?

I would probably never consider using SDL. I have enough experience with OpenGL & GLSL to just use those, but through my experiences I prefer DirectX. Mainly for small reasons, not that it's easier or anything.

> I voted against porting to C++. Why? Because I do not see the major benefits that would be attained. Sure, it'll be a little bit faster, but so what? XNA and C# is pretty fast as it is, and certainly fast enough to run games that Eclipse produces. Not only that, but since both languages would essentially be using DirectX, the only difference in performance would be with .NET execution.
>
> You already have a good start on the engine, and have gotten through a good chunk of the "hard" parts that I found when I was porting the engine myself (rewriting networking, basic graphics and rendering). If people really want a C++ version, at the very least finish what you've started, then port it to C++.

You're right, and so are you Marshy Dearest. But luckily the work we've gotten done is actually inspired/based off of code/samples/labs I've created while at school. To get the engine to where it's at now in C++, it would probably take me no longer than two weeks. I would just rather know what the community preferes now rather than later. If they want a C++ version after I finish this one, so be it but otherwise, I don't want to waste my time. Figured this would be a great oppurtunity for people to stop saying "You should do this" and actually have a say.

[JeffSventora]

In case any of you are wondering what the C++ would look like, this would by what I presume to be the equivalent of the Vector2 class from XNA. I wrote this myself today just for a quick example.

```

#pragma once

#include #include #include namespace EclipseLib

{

class float2

{

public:

// Union allows for the data to be accessed in different ways

union

{

// Our actual X & Y Coordinates

float XY[2];

// Position

struct

{

float x;

float y;

};

// Texture Coordinates

struct

{

float u;

float v;

};

};

// Constructors

float2(void) : x(0), y(0) {}

float2(float v) : x(v), y(v) {}

float2(float _xu, float _yv) : x(_xu), y(_yv) {}

// Operator Overloads

inline float2 operator+(const float2& v) const

{

return float2(x + v.x, y + v.y);

}

inline float2 operator-(const float2& v) const

{

return float2(x - v.x, y - v.y);

}

inline float2 operator*(const float2& v) const

{

return float2(x * v.x, y * v.y);

}

inline float2 operator*(float v) const

{

return float2(x * v, y * v);

}

inline float2 operator/(const float2& v) const

{

return float2(x / v.x, y / v.y);

}

inline float2 operator/(const float v) const

{

return float2(x / v, y / v);

}

inline float2& operator=(const float2& v)

{

x = v.x;

y = v.y;

return *this;

}

inline float2& operator=(const float2&& v)

{

if(this != &v)

{

x = std::move(v.x);

y = std::move(v.y);

}

return *this;

}

inline bool operator==(const float2& v) const

{

return (x == v.x && y == v.y);

}

inline float2& operator+=(const float2& v)

{

x += v.x;

y += v.y;

return *this;

}

inline float2& operator-=(const float2& v)

{

x -= v.x;

y -= v.y;

return *this;

}

inline float2 operator*=(const float v)

{

x *= v;

y *= v;

return *this;

}

inline float2 Zero(void)

{

x = y = 0;

return *this;

}

inline float2 Negate(void)

{

x = -x;

y = -y;

return *this;

}

inline float Dot(const float2& v) const

{

return (x * v.x) + (y * v.y);

}

inline friend float DotProduct(const float2& a, const float2& 

{

return a.Dot(;

}

inline float Magnitude(void) const

{

return (float)sqrt(Dot(*this));

}

inline float2& Normalize(void)

{

float InverseMagnitude = 1.0f / Magnitude();

*this *= InverseMagnitude;

return *this;

}

// Allows you to cast to a D3DXVECTOR2 Object

operator D3DXVECTOR2* (void) { return (D3DXVECTOR2*)this; }

inline D3DXVECTOR2* AsD3DVector(void)

{

return (D3DXVECTOR2*)this;

}

};

}
```

[blkcrow]

> I would probably never consider using SDL. I have enough experience with OpenGL & GLSL to just use those, but through my experiences I prefer DirectX. Mainly for small reasons, not that it's easier or anything.

May i ask why? Dont take me wrong its not that i want it to be made in SDL I know you have your reasons no to but i want to know what advantage directx9 gives you over SDL for a project such as this

[JeffSventora]

Well if I did it in C++, I would take a different approach on the rendering as opposed to how I'm doing it in XNA. Think of XNA like using Sprites from DirectX, fixed functionality for 2D Rendering. I would take a heavy shader approach to this one, I'm not sure as to how well SDL copes with GLSL without adding more GL code to your SDL project. Also, my favorite feature, EffectPools and the shared keyword 

[blkcrow]

So you are planning in writing you are own shaders?

[Stein]

I wouldn't get discouraged on using XNA and .NET, they're good libraries and a decent starting place for people to learn programming because they're not all that complex(in theory, in practice one can make it as complex as they desire). Considering most of us are hobbyists, and instantly jumping into C/C++ would likely turn most of these people off(I mean hell, even basic VB6 stuff turns them off) I highly doubt C/C++ would make them stay. It's simply very complicated to look at for a newbie, especially when you do not understand the Syntax, whereas .NET remains relatively easy to read and somewhat logical(although I personally am not a fan of the mess that is OOP).

As much as I personally would like a C/C++ version, I would probably write it myself in my own ways if I ever were to seriously develop a game. And as I mentioned before, .NET is a relatively simple step into programiming, and since we are basically catering to every 12 year old's MMORPG dreams, we should probably stick to something somewhat basic for the ease of access, while still staying somewhat recent and powerful.

[damian666]

just simple VB.Net would provide a good step up if you ask me.

[Stein]

I have a basic VB.Net one I'm tinkering with for the hell of it. It's pretty simple yes, but going C# is likely better just because it covers a larger portion of the industry, whereas VB.Net seems more like a tinkerfest.

[damian666]

but eclipse is a tinkerfest 

and who cares about the industry, were just here for fun and games 

edit, can i take a looksie at your .Net one? :3

[Stein]

It's not done yet, still working on getting the threading to work properly on networking. I'm dividing the server processes under several threads, and if one crashes due an error it'll reboot itself from the start.  I have most of it working, just fidgeting on getting the load divided between several SQL threads to ensure there is as little delay in storing data as possible.

Maybe when I finish it, right now all you can do is register, log in and walk around pixel based anyway.

[damian666]

so? its a clean engine without any additional features, thats good for me.

[Stein]

It's also unfinished, still crashes or pisses itself and needs some stuff I'm rewriting to not use dependancies anymore.  It's a theory design, it's not to be used for production. I mess around in it, and write down what works and what doesn't, then adjust my plans to write an ACTUAL engine accordingly.

[damian666]

k, fair enough 

[Stein]

Anyhow.. _*pulls rails back together*_ We should PROBABLY keep this on topic.

[unknown]

> Well if I did it in C++, I would take a different approach on the rendering as opposed to how I'm doing it in XNA. Think of XNA like using Sprites from DirectX, fixed functionality for 2D Rendering. I would take a heavy shader approach to this one, I'm not sure as to how well SDL copes with GLSL without adding more GL code to your SDL project. Also, my favorite feature, EffectPools and the shared keyword 

Will a C++ version be noticeably faster for the end user? No. You're not doing complex 3d rendering you're making a 2d game. Keep it simple.

[JeffSventora]

Well, more than 50% of the users are not interested in a C++ version. Regardless, development of the current version will progress as normal, I still might make a client i nC++ at some point though. Thanks for the feedback! Expect some good updates soon 

[Synergy]

> Well, more than 50% of the users are not interested in a C++ version. Regardless, development of the current version will progress as normal, I still might make a client i nC++ at some point though. Thanks for the feedback! Expect some good updates soon 

Yay! 

I'm really looking forward to this. 

[JeffSventora]

Glad to hear! I've been re-working Fusion to take advantage of multiple cores, AKA I'm in the process of multi threading the engine. Should be finished within the next week. ;D

[Synergy]

> Glad to hear! I've been re-working Fusion to take advantage of multiple cores, AKA I'm in the process of multi threading the engine. Should be finished within the next week. ;D

I assume you mean you'll be finished reworking Fusion, not the whole engine? 

[iSnow]

I'd have to agree with Stein. Were talking Eclipse here and if we don't keep it simple the work won't have as much attention as it deserves. I know some C# and I wouldn't mind it at all but there are others who would like to see an easier language anyway. And were still talking about a 2D MMO engine and sure, adding particles and shaders and the fancy stuff to a game is a great thing, were not competing with major 3D games and their tech, of course the stuff I mentioned before is also possible in .NET, so keeping it accessible on the current generation is the key.

[Mal]

Or you could write it in VB.NET, get identical results and allows users to migrate readily and easily from VB6 to .NET.