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
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.
Will games be written with .NET?
.NET?
.NET than are written for Linux?
Yes
Will all games be written with
No
Will games be written with SDL and OpenGL?
Yes
Will all games be written with SDL and OpenGL?
No
Will more games be written with
Yes
Will it really be any different from the way it is now?
No
Was this article posted just to give zealots a chance to yammer about MS world conquest and other conspiracy theories?
Yes
I don't need no instructions to know how to rock!!!!
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.
As a game developer, I am/will use the heck out of C# and .NET to develop software - just not the runtime portions of my games.
.NET allows me to use or not use various parts of the run time (assuming that we architected the interfaces correctly!) in a way that can both maximize usefulness (it looks like it will in the game!), and unit test the game code in a better environment.
.NET are robust enough for these - the .NET IDE proves that.
.NET are better for windows app development - either you have done it, and understand why MFC and C++ blow chunks, or you are in for quite a pleasent suprise when you write that first tool.
Tool development takes up an increasing amount of my team's time. We have custom tools for art manipulation, sound manipulation, and data warehousing. Not to mention our tool for level creation, which we hope to release with the game. All of these tools need to be robust, have clean interfaces, and be developed and changed quickly, and grow with the run time modules.
Remember that C# and
I won't go into why C# and
-Donut
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.