Quote:If you were building a 3d game for Linux, would you base it on Mono?
Xeonx Studios
Oooh look, a cross platform 3D game development kit written in C# for the mono platform...
[.net] 3d engine on .Net , worth?
Xeonx Studios
Oooh look, a cross platform 3D game development kit written in C# for the mono platform...
Quote:Original post by AzCoder
I am simplying trying to help people understand why the entire industry uses c/c++ instead of .Net. It is not because they are hesitant to move off of c++. It is because in many instances c++ is better suited for interactive 3d applications.
This quote gave me a huge deja-vu, because I once said it a long time ago!
The game industry moves slowly to adopt new paradigms, languages, etc. Some reasons are due to the technology, and some are due to IP.
Now no offence obviously, because I made the same statement as you about 5-6 years ago. I said that people should stop looking at C++ for games, because nothing would change from C/ASM. You are totally wrong in your thinking though, just as I was. There is no "be all end all" language, pattern, design, etc. As of right now, even using .NET 2.0 and generics, I would probably not attempt to write a full 3D engine in C# or managed C++ if I wanted it to compete with engines such as Torque, etc.
BUT
You really need a reality check, in being that in almost any application, only small portions need to be fully optomized. Right now I have some server and client engines that were previously written in C++. I have made a small API, wrapped in managed code, and than developed the full game demo in C#. Guess the result? EXACT EQUAL PERFORMANCE, DEVELOPED IN LESS TIME, TOOK NO TIME TO DEBUG WHEN I COMPARE IT TO C++ PROJECTS.
Now that I have moved a lot farther into my project, a huge majority of the engine is written in C# and is yielding the exact same performance as the unmanaged C++ version was. Sure I still have a few time critical funcitons written in C++ and wrapped, but the fact of the matter is that there are a lot of C++ engines that use some ASM routines for optomizing as well.
Quote:
Do you honestly think .Net is a viable choice for Linux, Mac, Playstation, or GameBoy Advance? If you were building a 3d game for Linux, would you base it on Mono?
Also this quote is very weak from any engineering stand-point. I'm sorry to say but there are MANY projects using Mono that are games or 3D applications. Although this isn't even something that should come up.
Sure .NET can be portable, but why mention PS, GameBoy, etc? Any engineer worth his salt knows to use the right tool for the job, and the right tool for these platforms is not a managed subsystem. The .NET framework has a strong emphasis on PCs and servers, sure there are efforts for portability, but those are only second. It is about choosing the right language/tool for the job, not trying to pipe up stupid lines everybody already knows.. as .NET is not made for console or portable game systems.
Just figured I'd let you know you are wrong :)
A couple things.
You guys underestimate how portable MS apps are, in reality. They don't normally release stuff for anything other than x86 boxes...but the NT kernel wasn't even designed on x86. It was originally on a MIPS, IIRC. That thing is every bit as portable as the Linux or BSD kernels...should MS choose to do so.
I suspect the .NET Frameworks are the same. Remember, there's a Compact framework, which is run on all sorts of small devices, most of which run MIPS. And a MIPS is big endian...a PPC release would be trivial.
As the Mono project rapidly approaches a stable release, it's not difficult to write programs that compile to completely portable binaries, Of course you have to be aware of endian issues...unless you use .NET serialization. You have to avoid certain libraries, of course, but Gtk# and such give you more or less the same capabilities.
You guys underestimate how portable MS apps are, in reality. They don't normally release stuff for anything other than x86 boxes...but the NT kernel wasn't even designed on x86. It was originally on a MIPS, IIRC. That thing is every bit as portable as the Linux or BSD kernels...should MS choose to do so.
I suspect the .NET Frameworks are the same. Remember, there's a Compact framework, which is run on all sorts of small devices, most of which run MIPS. And a MIPS is big endian...a PPC release would be trivial.
As the Mono project rapidly approaches a stable release, it's not difficult to write programs that compile to completely portable binaries, Of course you have to be aware of endian issues...unless you use .NET serialization. You have to avoid certain libraries, of course, but Gtk# and such give you more or less the same capabilities.
Hrm, I've seen these arguments before...
Well, lets try and straighten out a few things
Now, performance is not an issue. It hasn't been an issue for a while now. You can call C/C++ native methods from any .net language. So performance critical methods (which should be PROFILED FIRST) can easily be in a superoptimized state. Also, don't ever underestimate the JIT. It can take advantage of machine capabilities far better than a statically compiled application can.
Finally, I hear this performance argument brought up all the time... x is a micron faster than y, so use x. That's total bullshit. You should profile first. NEVER forget the 80/20 rule1.
As far as C# and .net goes, heck even C++/CLR, it's very fast to develop in. Generics are extremely nice and clean. To me, speed of development and code verifiability is more important than how fast my code runs (which with .net is at native speeds). Plus, if I do find a bottleneck when using one of said language, I can always drop to a lower level language.
Well, lets try and straighten out a few things
- C# and the .NET clr are currently controlled by the EMCA, not Microsoft.
- The Microsoft .net Framework implementation of Rotor is a multilayer framework, with part of it being the PAL (Platform Abstraction Layer)
Now, performance is not an issue. It hasn't been an issue for a while now. You can call C/C++ native methods from any .net language. So performance critical methods (which should be PROFILED FIRST) can easily be in a superoptimized state. Also, don't ever underestimate the JIT. It can take advantage of machine capabilities far better than a statically compiled application can.
Finally, I hear this performance argument brought up all the time... x is a micron faster than y, so use x. That's total bullshit. You should profile first. NEVER forget the 80/20 rule1.
As far as C# and .net goes, heck even C++/CLR, it's very fast to develop in. Generics are extremely nice and clean. To me, speed of development and code verifiability is more important than how fast my code runs (which with .net is at native speeds). Plus, if I do find a bottleneck when using one of said language, I can always drop to a lower level language.
Quote:Original post by Promit
A couple things.
You guys underestimate how portable MS apps are, in reality. They don't normally release stuff for anything other than x86 boxes...but the NT kernel wasn't even designed on x86. It was originally on a MIPS, IIRC. That thing is every bit as portable as the Linux or BSD kernels...should MS choose to do so.
I suspect the .NET Frameworks are the same. Remember, there's a Compact framework, which is run on all sorts of small devices, most of which run MIPS. And a MIPS is big endian...a PPC release would be trivial.
As the Mono project rapidly approaches a stable release, it's not difficult to write programs that compile to completely portable binaries, Of course you have to be aware of endian issues...unless you use .NET serialization. You have to avoid certain libraries, of course, but Gtk# and such give you more or less the same capabilities.
Hmm...I think it was actually PowerPC, because a lot of early devving and testing was done on macs, before PC's became viable, but that's trivial.
Quote:Original post by Anonymous PosterQuote:Original post by Promit
A couple things.
You guys underestimate how portable MS apps are, in reality. They don't normally release stuff for anything other than x86 boxes...but the NT kernel wasn't even designed on x86. It was originally on a MIPS, IIRC. That thing is every bit as portable as the Linux or BSD kernels...should MS choose to do so.
I suspect the .NET Frameworks are the same. Remember, there's a Compact framework, which is run on all sorts of small devices, most of which run MIPS. And a MIPS is big endian...a PPC release would be trivial.
As the Mono project rapidly approaches a stable release, it's not difficult to write programs that compile to completely portable binaries, Of course you have to be aware of endian issues...unless you use .NET serialization. You have to avoid certain libraries, of course, but Gtk# and such give you more or less the same capabilities.
Hmm...I think it was actually PowerPC, because a lot of early devving and testing was done on macs, before PC's became viable, but that's trivial.
If you are referring to the NT kernel you are wrong, as Promit stated the NT kernel was built for MIPS but was later moved to the x86 platform. Although as stated as well, a PowerPC release would be very trivial if a working MIPS core was established.
Quote:Original post by AzCoder
Do you honestly think .Net is a viable choice for Linux, Mac, Playstation, or GameBoy Advance? If you were building a 3d game for Linux, would you base it on Mono?
Linux: Yes
Mac: Yes
Playstation: Well, PS3 possibly but otherwise no
GameBoy Advanced: No
Quote:Do you honestly think that using a jit compiler for real-time interactive 3d applications makes good sense from a performance perspective?
Absolutely. The JIT compiler can optimise specifically for the hardware the application is being running. The advantages of this should be obvious. The only really disadvantage is the initial startup of the app is slowed by the JIT compilation, but is this really all that big a problem?
Quote:I will grant you that Design Patterns do apply to all languages. My point was that if you already know c++, your time is better spent learning additional design patterns than learning a new language like C#.
Certainly not an invalid point, but what's to stop you from doing both?
Quote:C++ is not the "Stone-Age". It has language features that are more advanced and not present in .Net. Like the STL. .Net does not support generic programming like the STL. At least not until they get the upcoming "generics". The STL is not simply another run-time library. It enables generic programming and supports approaches like policies and traits.
His point wasn't that C++ is stone-age, he was providing an exaggerated example to get his point across. Also, .Net *does* support generic programming (well, v2.0 anyway). It's true that generics do not provide as much flexibility as templates, but that was intentional. Templates have a bad habit of making things far more compilcated than necessary in order to do things that the language wasn't designed for.
Quote:Ultimately, you should use whatever language you want. I am simplying trying to help people understand why the entire industry uses c/c++ instead of .Net. It is not because they are hesitant to move off of c++. It is because in many instances c++ is better suited for interactive 3d applications.
That's just plain wrong. If your company has a codebase written in C++ that has taken years and many $ to build up would it really matter how much better a new language was? I'm not talking a game engine that you could simply write a managed C++ wrapper for, I'm talking thousands of small useful bits of independant code.
Quote:Most importantly, just because Microsoft wants you to use .Net is absolutely not a good reason to do it. Use your knowledge and make an educated decision for yourself.
I agree, everyone should make their own decision but some of your 'knowledge' seems to be plain wrong.
Commercial RTS game in C#, and you can download a demo too by the looks of it - Arena Wars - this game also apparently has a feature in Septembers edition of Game Developer.
the argument over .net and playstation is an odd one but if PS2(and you would think the PS3) use Linux as an OS then Mono would be a reality. Now getting a licence to develop for it would be another story.
with longhorn games will be written in .NET
with longhorn games will be written in .NET
Quote:Original post by Anonymous Poster
Now getting a licence to develop for it would be another story.
Why? Who would have to pay to whom?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
