[.net] 3d engine on .Net , worth?

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#.

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.

Some people have already been coding decent looking engines in C#, check out Purple# for one.

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.

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.

Quote:

Original post by SnprBoB86 One major stumbling block for XBOX2.NET would be the rumor that XBOX2 will not use an X86 processor.

If the XBox2 does use .NET then it not being an x86 processor won't make the slightest bit of difference. .NET code compiles to MSIL which is JIT compiled keeping your code totally oblivious to what the underlying processor is.

Quote:

Original post by CpMan 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.

I think the problem with C++/CLI (or managed C++) is that, well, you can still use normal C++ functionality, which may or may not be platform dependent. That creates some headaches that aren't really an issue in C#, since the closest thing you can do to doing anything "C++-like" there is unsafe blocks.

Good point, but you're going to get that with any C++ app anyway.

I'm surprised that nobody has mentioned the Axiom Engine which is a C# port of the C++ OGRE engine.

This shows that really language isn't the big issue you need to think about, but rather design, functionality, math, etc. As if you test both, the C# port of the OGRE engine actually outperforms it's C++ big brother!

I think there would be a huge problem with using .net on the Xbox 2 if its using some kind of IBM ppc dirivitive. While the Applications programmer does not care what CPU he runs on the person programming the .net framework sure as hell does. For every platform and every CPU the .net framwork programmer must make every single function work, and since it acts like a compiler that means they have to write an optimized compiler for that CPU/platform. Optimized asm is totaly different on an amd64 vs p4, and its also totaly different between the PS2s Vector units the EE, the Cell processor in the PS3 and the multi-core IBM sitting in the Xbox 2. All of these things come into effect when you have to program an abstraction that isnt slow, and still works the same way on every platform/CPU.

P.S. anyone think that Microsoft putting a Mac processor into its console is stupid or something closely related to stupid?

Quote:

Original post by HippieHunter I think there would be a huge problem with using .net on the Xbox 2 if its using some kind of IBM ppc dirivitive. While the Applications programmer does not care what CPU he runs on the person programming the .net framework sure as hell does.

Funny, you first say there would be a problem with using .NET with a PPC processor and then immediately say that an apps programmer (that is, someone using .NET on the PPC processor) won't care (which reads to me as won't have a problem). You just contradicted yourself.

Quote:

Original post by HippieHunter For every platform and every CPU the .net framwork programmer must make every single function work, and since it acts like a compiler that means they have to write an optimized compiler for that CPU/platform.Optimized asm is totaly different on an amd64 vs p4, and its also totaly different between the PS2s Vector units the EE, the Cell processor in the PS3 and the multi-core IBM sitting in the Xbox 2. All of these things come into effect when you have to program an abstraction that isnt slow, and still works the same way on every platform/CPU.

Firstly, ".NET framework programmer" should be ".NET framework team". Big difference there. Secondly, they don't have to "make very single function work", in fact they shouldn't have to touch the .NET framework at all. It's the CLR, JIT compiler, etc that would need to have a PPC version developed. And thirdly, what's your point? If microsoft decides to support .NET on the XBox2 then developing the CLT, JIT compiler, etc. for it is their problem, not ours. All we have to do is code using .NET languages.

Quote:

Original post by HippieHunter P.S. anyone think that Microsoft putting a Mac processor into its console is stupid or something closely related to stupid?

No.

hmm... very interesting...

A question for those who are already programming in managed C++ :

Would it be possible to do a project, library, whatever, in which, by using #define and #ifdef , you could compile the project as managed or unmanaged?

I figure it is possible, but, that would imply to do an #ifdef in half of the lines of code? or most of the code would be the same?

Quote:

Original post by HippieHunter P.S. anyone think that Microsoft putting a Mac processor into its console is stupid or something closely related to stupid?

It is actually quite the opposite. The x86 architecture is tired and other architectures are just flying right by. The PowerPC would be 10 times better for gaming than an x86 processor.

Intel milked the x86 line for too long giving people insignificant upgrades in speed. That is why AMD and PowerPC are starting to eat away big portions of Intel's sales, which in term loses Intel strategic business partners.

Quote:

Original post by vicviper hmm... very interesting... A question for those who are already programming in managed C++ : Would it be possible to do a project, library, whatever, in which, by using #define and #ifdef , you could compile the project as managed or unmanaged? I figure it is possible, but, that would imply to do an #ifdef in half of the lines of code? or most of the code would be the same?

i would go even further.

i think a decent programming language should have standarized .project files being a part of the language itself. then you can easily distribute your project and it will compile regardless of IDE or whatever, and it alllows you to set stuff like CG/no CG, case sensitivity, RAII, syntax preferences or other customizations to the language. and any standard compliant compiler would know what to do with it.

I almost threw up while reading this thread. How are "portability" and "use .NET" in the same sentence? C# is an abomination in my book. The IT world is making my game dev hobbies more annoying every day... If you want to port you gotta have a common denominator. C/C++ are as common as they come. ANSI C libs are pretty much your limitation unless someone has a library ported for you already. Anything else you're gonna be kicking yourself in the head. And why would they put .NET on the X-Box? Are people hiring Visual Basic coders now to write state of the art gaming engines?