[.net] 3d engine on .Net , worth?
Author
I've been thinking lately in the possibility to build the next generation of my 3d engine over Net Framework, and I've been thinking on the pros and cons.
I'm not worried about performance, but with portability, compatibility, and code reusability.
The obvious advantage is that, like it or not, .Net is the future because Microsoft wants it, so the sooner we migrate, the better.
Against it, I see the fact that none of the major 3d engines arround seems to be doing to move to .Net , and it looks to me that 3d engines are going to stay in "plain" C++ or COM at most, for a long time... so moving a 3d engine to .net would be too early. Also, I see managed c++ coding a bit too far from what I usually see in general coding... then there's the portability problems... I see managed c++ much more troublesome when porting the code to unmanaged environments...
I would like to know what people think about this
Obviously if you want portable code you need to limit yourself to libraries that are common to the platforms you want to support. Dot NET is not a portable library and even with mono support for it in linux I would not count on it being 100% compatable with the current editions of the .NET framework. The current 2.0 version probably breaks alot of stuff.
The only issue on your list that is ugly is portability. Can you define the platforms you want to support? (e.g. I believe .Net on the GBA is not feasible, whereas a Linux/Darwin/BSD/Win32 .Net engine is possible and PS2.Net or XBox.Net are theoretically feasible).
Managed C++ is essentially C++.Net, and it has more portability issues than C# does because C# is part of the .Net core and managed C++ is anciliary. If you write a .Net game engine, write it in C#.
Managed C++ is essentially C++.Net, and it has more portability issues than C# does because C# is part of the .Net core and managed C++ is anciliary. If you write a .Net game engine, write it in C#.
I was thinking about porting my engine to C# in the future. I think it is a little too early yet though, I'd say you should wait until .NET matures more, as well as Mono. I don't think even Xbox 2 supports .NET, so that might be indicative that the move is not neccessary quite yet.
Author
that's the point... I'm thinking primarily in console platforms.
What I'm worried the most is with interface classes... you see, when doing a 3d engine, you can do external interface classes that point to a switchable directx/opengl architecture... but, to some degree, these interface classes are quite plain and can be ported to almost anything.
With net, the way classes are coded changes a little (extra directives, namespaces, garbage collection, etc) that breaks reusability a lot.
If you intend to port it at all, you should design your engine to be API independant. There is a source forge project that wraps OpenGL for .NET
Microsoft probably could get .NET to run on XBOX without significant problems. The XBOX uses an X86 processor and a tiny variation of the Win2000 kernel. Chances are, however, they will not port it any time soon. Microsoft has fallen way behind with Longhorn and the core .NET team is probably spread far too thin already.
That said, I can definitly see .NET 2.0 support being a major possibility for launch titles on XBOX 2. When that will be, I haven't a clue. Microsoft's latest DX SDK contains a sample for using .NET as a scripting runtime for C++ games. There are many benifits to this approach: Primarily, the run-time is more mature and better supported than something like UnrealScript and it compiles to native code and is far faster than Python, Lua, Lisp, etc. One major stumbling block for XBOX2.NET would be the rumor that XBOX2 will not use an X86 processor.
Microsoft probably could get .NET to run on XBOX without significant problems. The XBOX uses an X86 processor and a tiny variation of the Win2000 kernel. Chances are, however, they will not port it any time soon. Microsoft has fallen way behind with Longhorn and the core .NET team is probably spread far too thin already.
That said, I can definitly see .NET 2.0 support being a major possibility for launch titles on XBOX 2. When that will be, I haven't a clue. Microsoft's latest DX SDK contains a sample for using .NET as a scripting runtime for C++ games. There are many benifits to this approach: Primarily, the run-time is more mature and better supported than something like UnrealScript and it compiles to native code and is far faster than Python, Lua, Lisp, etc. One major stumbling block for XBOX2.NET would be the rumor that XBOX2 will not use an X86 processor.
Quote:Original post by Magmai Kai Holmlor
The only issue on your list that is ugly is portability. Can you define the platforms you want to support? (e.g. I believe .Net on the GBA is not feasible, whereas a Linux/Darwin/BSD/Win32 .Net engine is possible and PS2.Net or XBox.Net are theoretically feasible).
Managed C++ is essentially C++.Net, and it has more portability issues than C# does because C# is part of the .Net core and managed C++ is anciliary. If you write a .Net game engine, write it in C#.
There is no difference in portability issues, at least that I know of. We compile to MSIL just as C# does, and both produce verifiable IL (and thus should be portable, as IL being verifiable basically says that it conforms to the CLI specs). There may be some differences if you attempt to deal with mixed managed and unmanaged code, however compiling with /clr:pure will ensure you don't use any of those things.
C# is not part of the .NET core, and is not the "de-facto" defining language for .NET is the sense that the spec writers conform to C#. It's the other way around. C# doesn't actually support all of the .NET infrastructure features, especially in version 2.0 (at least when my internship ended). C# doesn't support all of the access modifiers supported by .NET, nor unbound delegates or type forwarding.
This is not to say that C# is any less of a language than C++, or that C++ is any less of a language than C#, in the .NET arena, especially with the v2.0 managed syntax (if you haven't seen it, check it out in the express download, I think it made it into beta 1). If I was writing a language, I'd probably attempt to utilize both languages, using C++ as a way to wrap up some unamanged code if I had some good stuff laying around. C# would probably be my primary language for the engine, though I'm not sure if I take the v2.0 syntax into account.
Quote:
Also, I see managed c++ coding a bit too far from what I usually see in general coding... then there's the portability problems... I see managed c++ much more troublesome when porting the code to unmanaged environments...
Have you looked at C++/CLI? It's a beautiful middle ground, though, of course, you won't really be able to take full advantage of it until VC2k5 comes out of beta.
I'm going to stick with c++/opengl until I'm forced to move on. To be honest, these two tools are more than enough for what I'm doing and any future need will come from elsewhere not prog.lang. unless it's a whole different paradigm than OO. I rather not touch d3d again either. However I think C#/.net coding non 3D apps is nifty and I could see myself doing it if I wasn't stuck in 3d/game field. I don't know about c++/.net, looks to me like C#/.net are built for each other.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
