Slashdot Mirror
Is .NET Relevant to Game Developers?
andrew stuart asks: "We've heard an awful lot about how .NET is the future and how .NET signals the end for COM based Windows development, but how far does this go? Is it really the end of COM? Will ALL Windows programming be done with .NET? What about games development? Will games be developed with .NET? If games aren't developed with .NET and Microsoft is killing COM, then what future for games development on Windows? Will there be DirectX for .NET?"
At work I've used dotnet for the past year and half full time.
I've built websites with it, I've build desktop apps with it,
I've even built auto-updating distributed apps with it.
Dotnet has some good things to it and some bad things just like
any other technology. Before dotnet, most of my work solutions
were written in VB *shudder*, but when dotnet was released I
switched immediately to C#. C# does some things right that Java
didn't do too well on, but those are honestly pretty rare. IMO,
C# is very much like an immature version of Java. That being
said, Microsoft is pushing dotnet pretty hard.
When it comes to dotnet for game development, it is a
possibility. Mainly because Microsoft is putting so much
emphasis on it. With good native integration into DirectX, they
could push a lot of DirectX developers into using C# or Managed
C++, maybe. It will only happnen if MS can make the integration
fast and tight, and even then I don't think everyone doing
DirectX will use dotnet, it imposes too many rules on you as the
developer and really hides the low level details that are so
critical to many high performance games (yes even using unsafe code). On the other hand it
could be a good language for someone to learn to write games in,
for just that reason.
Of course, that really only applies to people who want to use a
Microsoft product for building games. The ubiquity of dotnet
within the MS world will have little to no effect on the OpenGL
programmers, except that they may need to find a different
editor *if* they have been using Visual Studio.
In reality I think dotnet is what everyone thinks, a competitor
to Java. How many highgrade professional games are written in
Java currently?
Doug Tolton
"The destruction of a value which is, will not bring value to that which isn't." -John Galt
DirectX 9.0 for Managed Code
.NET .NET
= /library/en-us/directx9_m/directx/directx9m.asp?fr ame=true
(its out already)
With DirectX 9.0, developers can take advantage of DirectX multimedia functionality and hardware acceleration while using managed code. Managed DirectX enables access to most of the original unmanaged DirectX functionality. The following are the managed code languages supported by DirectX 9.0 and documented in the software development kit (SDK).
Microsoft Visual C#(TM)
Microsoft Visual Basic®
Microsoft Visual C++®
Microsoft JScript®
http://msdn.microsoft.com/library/default.asp?url
The developers of AC2, developed by another company for microsoft, where given authencation code and chat server code developed by microsoft. The addition of this code has made the game unplayable. Here is a quote about the problem from the microsoft head of the game: " Right now the Chat and Authentication System (the Microsoft technology that handles this entire sort of chat) relies on system calls to another system--one that is not related to the Chat and Authentication System or to AC2--to send out the packets that contain your chat. What is happening is that under high CPU usage (that is, when the game starts reaching its peak), this third system starts to throttle the packets and queue up the game server messages (not to be confused with messages/chat to players)." From what is know about the authentication server and chat they are based on .net technologies. So since microsoft cannot produce its own reliable stuff using .net what is the chance of someone else?
The bigger issue for game development is that memory management is turned over to the system, which takes a lot of control away from game developers... these are people that put inline assembly code to speed up certain sections...
.NET information is /.
Oh how I fear for anyone whose source of
The memory managment is not "turned over" to the system. There is an automagic Garbage Collector like Java, but you still have control if you don't want to wait for the automagic processes.
Wow have you even tried .NET? This entire slashdot article could have been eliminated with a quick google search.
.NET isn't interpreted, but designed to be JITted. Heavy math is fast in C#, and made even faster since you have the option of STRUCTs! (we do plenty in our research work that involves computer vision.)
.NET DX9 libraries give you 98% of the C++ performance. That isn't too bad now is it?
.NET framework - that's only 20 megs. When most games nowadays are coming out on several CDs, installing the .NET framework isn't a big deal.
CLR doesn't produce slow code. It's NOTHING like when people complained how slow java was. That's because
It won't do MMX optimizations so far, at least not that I know, so that stuff is still done by hand. But DirectX 9 is basically 'DirectX.NET', and the
Most of the stuff we've used in DX9.NET has been very fast, and using the simple interop with native code we've written plenty of MMX/SSE/SSEII optimized methods where we needed them.
In addition to your game needing the
What does this give a game developer? Plenty! Faster development of games with fewer crashes possibly, easier patching of games and auto-updating. Games are a different beast than commercial apps - you don't need versioning so much, you don't need XML, or rapid GUI development. But there's nothing wrong with writing a game in C#, it's just another language, and its plenty fast.
The parent article seems to have a vague concept of what .NET is. (Perhaps this is more MS propaganda's fault.)
MS released C#, and that's what they're toting when they talk about ending COM-based windows development, I think.
If you knew what COM was, you might have a better understanding of what Microsoft is phasing out. COM is the Component Object Model. It allows programs to invoke special versions of other software (which has a COM written for it) and call routines out of that software. For example, I could call the spellchecker for MS Word from my email-writing program, assuming the user had Word installed, of course.
I used COM in writing an application meant to automate customer response letters (the user wanted to have Word-compatible documents when the program was finished - a perfect example of COM) and let me tell you: COM is hairy. You have to pass pointers to functions, call functions with nasty parameters... it's a good idea, it just doesn't work inside the C/C++ syntax very well.
Unless you're looking for your game to be able to read and write MS Word files, or print through Excel, games probably wouldn't have used the Component Object Model.
C# apparently has the same functionality that COM did, but probably does it a little more elegantly.
In any case, game developers didn't use COM, and they're probably not using C#. They WILL, however, be using .NET. Because Visual Studio .NET is Microsoft's latest incarnation of their programming IDE and compiler package.
And the later versions (hopefully) contain more and more code optimization. And Microsoft HAS good code optimization: they bought all of Watcom's optimizing people a few generations back (when game programming was done almost exclusively in Watcom).
In short: Visual Studio .NET is probably phasing out COM. This has absolutely no bearing on game programming.
--
Disclaimer: The above statement probably includes half-truths, because real truth is too complicated.
I think you were thinking of fortune cookies, not chopsticks. I can assure you, coming from South-East Asia, that the Chinese, Japanese and Koreans all have been using chopsticks for millenias.
Which is why there was much backslapping when a Chinese archaeologist claimed to have found a fork in a cave in China dated to about 3000 BC - it's not that they have not discovered forks, it's that they have "moved on".
And no, my chopstick handling is still rather poor. I can use it to eat rice though :p
Michel
Fedora Project Contribut
While you might not be aware of this, cross-platform solutions have been used, are used and will continue to be used to develop games.
.NET? .NET gaming. Those who use DirectX because there is specific things in DirectX that they can't find elsewhere will move on to .NET. Others will realize that OpenGL is better than DirectX as an API for mostly anything (Don't flame me for the exceptions).
.NET and Microsoft is killing COM, then what future for games development on Windows?
.NET and COM programming in one step.
Will ALL Windows programming be done with
no. A whole bunch of DirectX developers that use it because they don't know any better will probably move on to
If games aren't developed with
For christ's sake... is developing games and DirectX now linked by some kind of godly power? Most of the good games out there (quake anyone?) have been built on multiple platforms and released on multiple platforms because their developers had a clue, which most developers don't. Having used Microsoft stuff for the past years is not a good point while trying to choose which library to base a project on. Finding the most portable and easy to use one is.
There was a discussion earlier this week about writing portable games here on slashdot. I believe you haven't read it so here it the main idea:
* If you decide to write a game from scratch, pick portable libraries right at the beginning of the project
* test that the project compiles and works on both platforms as it grows.
* keep bad code and unportable code out of the source.
That way you can probably get rid of DirectX,
.NET is the future, but it's not here yet. It's great for writing small applications quickly, like those corporations use internally. The earliest Microsoft would switch over large applications like Office to fully managed code will be around 2007, because only then will most PCs be able to handle it. 3D games will wait at least a few more years. Right now 95%+ of professional game development is done in C++. COM interfaces aren't going anywhere.
.NET evangelist, would answer with "a resounding no".
In 2010 when we might see a serious move to managed code even in games, then COM might start to quietly go away. But thanks to COM interop via COM-callable wrappers, there will continue to be options for C++ developers for the forseeable future.
And if you utter the words "COM is dead" to any Microsoft-employed programmer, they'll tell you to stop being spoon fed by their awesome marketing division. Even Don Box, father of COM and star
On the contrary, you have zero memory control in Java unless you use Java objects as JNI wrappers and then do all your memory managment in C. Alternately, you can use JVMPI to trap memory allocs and deallocs and try to control things that way. Or you find a VM that lets you tune and reprogram GC behavior. All objects in Java are subject to the GC. In .NET, there is some support for hand-managed memory, though attempts to limit it exist.
If I remember correctly there is, for example, no way to guarantee a destructor will run for a particular instance before it is recycled. Is this still true?
It was never true. You're guaranteed that finalize() will run on an object before it is removed from memory. What you're not guaranteed is that the object will ever be the target of a collection, meaning finalize() might never run. Additionally, it's impossible to know at what point in time after the running of finalize() (if ever) the object will actually be taken out of memory.
I'm curious how ask slashdot has become a free goole answers service... The person asking the question should really do some research first.
.NET developer) hope so! But alas, I don't think the time has come yet.
.NET?
.NET. What's wrong with that? Honestly you don't need to optimize some part of the application, like the start-up screens or the options dialogue.
.NET. Check DirectX 9 SDK, you can use it with C#, VB.NET, etc. There are sample projects everywhere.
.NET Framework allows compiling down to native code, there is a .NET framework tool "ngen.exe" which generates a native image of your CLR assembly down to native code for YOUR machine - it will optimize for the particular processor. This is kept in the cache on the particular machine.
.NET, you'll probably have to wait till computers with 5GHz processors and 2GB memory are common. Then again, everybody will agree with me that certain games just have to be written the hardcore C/C++ way. So what's the point of the question?
.NET like you do with Direct8 with C++ via COM interfaces, I think they are equally good, may be a bit slower due to the overheads.
.NET - as long as the user has sufficient memory I don't see why you can't.
.NET please.
Some comments here:
1. Is it really the end of COM?
We (any
2. Will ALL Windows programming be done with
Sure, you can do the hard core stuff in [Unsafe] C#/C++, leave the rest in
3. DirectX is already available for
4.
5. I personally think it's down to what game you are planning to write. If you want to do Doom III in
6. Summary:
If you are referring to using DirectX 9 with
If you want to do stuff like Diablo/Starcraft in
Don't do Doom III in
jliu
I have been using .NET since September 2001. I wrote an open source 3D engine using C#. It makes use of BSP tree visibility culling, it uses WorldCraft as a level editor, it supports OpenGL and it did support NVIDIA's Cg until they changed their interface. When I released this engine open source back in February 2002 I stated clearly that I thought that .NET would be useful for game development.
.NET 3D Engine
ExoEngine - A C#, OpenGL
PS. Some people notice that in the screen shots the engine is only getting about 10fps or less. This is because it was running without 3D hardware accelleration.
Some argue garbage collection is expensive, but try calling C++'s "new()" a few million times and see how much you like it then. Memory ALLOCATION in .NET is almost a no-op relatively, and deallocation's only real downside other than non-determinism is that a poor GC (garbage collector) can cause "burps" in performance if it falls behind due to too many objects being created and unreferenced too quickly. Generational GC's like .NET's tend to mitigate this to a large degree.
I suppose if you consistently use 100% of the processor and are allocating objects, eventually the processing overhead of the GC will become apparent, but most programs use the procecessor unevenly, leaving spare cycles for the GC to consume.
personal attacks hurt, especially when deserved