Is .NET Relevant to Game Developers? 563
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?"
Will there be DirectX for .NET? (Score:1, Informative)
.net DirectX (Score:5, Informative)
Another round of bug fixing and it'll be rather good.
Dotnet won't rule the world. (Score:5, Informative)
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?
DirectX 9.0 for Managed Code (its out already) (Score:5, Informative)
(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
Based on what microsoft has done in .net games NO (Score:4, Informative)
Re:That Giant Sucking Sound... (Score:5, Informative)
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.
Re:That Giant Sucking Sound... (Score:5, Informative)
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.
.NET and Passport are not the same thing (Score:2, Informative)
There is already Managed DirectX for
.NET is also an IDE, and an optimized C++ compiler (Score:5, Informative)
Re:Doubtful. (Score:5, Informative)
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
Re:Dotnet won't rule the world. (Score:2, Informative)
Your post is excellent with much more thought than I could cram into mine (office moving day, sigh.) Effectively .Net is intended for business application development, whether on server or client, or client-server. It has the typical rapid (well, unless you get stuck, it being so new yet, help can be hard to find) development ability of most tools which aren't geared to engineering or game work. Though, as processor speeds increase, hardware architecture improves and people get faster connections (which has been a reversed trend for a while with DSL ISP's going kapoot) the burden becomes less visible.
As an afterthought. I've still got some old games which were probably coded largely in assembler and c and are unplayable because hardware is so damn fast now. MoSlo hasn't been much of a help, either, since it provides uneven compensation for increased horsepower. I think anyone who thinks .NET isn't really too slow needs to see what these old games look like GHz processors and think about where all that increased power has gone.
Re:Strange... (Score:5, Informative)
Microsoft's marketing droids decided that if they called everything
Excuse me (Score:5, Informative)
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,
The future (Score:5, Informative)
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
Re:That Giant Sucking Sound... (Score:2, Informative)
IMHO, the value of
Also,
Re:That Giant Sucking Sound... (Score:5, Informative)
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.
Re:."Managed" anything - e.g. net DirectX (Score:2, Informative)
Re:That Giant Sucking Sound... (Score:4, Informative)
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
Yes! (Score:2, Informative)
Writing tools that an artist or designer can use to create content for said engine is a big part (and set to get much, much bigger).
Anything that speeds up the process of getting tools into the hands of the creative people is a Good Thing(tm)
Visual Studio .NET or .NET Framework? (Score:2, Informative)
Otherwise,
Looking at the way the CLR works.. you could I guess make a cross-platform game that way. But who cares? All the hard-core gamers have windows boxes and are interested in getting the most FPS out of their games.
As far as I'm concerned, if you really had to break down and use some windows stuff, you could put the MFC crap in too, but it's going to slow down your game.
It's decent for apps but games are high-performance.
Re:That Giant Sucking Sound... (Score:3, Informative)
As for memory management - as one of the other posters said, you can take control of the GC, but you really mess with it when you do this. - "fixed" blocks prevent the GC from moving chuncks, which really messes with it's performance.
If you use managed C++ rather than a pure .NET solution, you can get some of the benefits of the (very nifty) standard library, but still have your important code running unmanaged. However, I don't really see any gain to this. .NET is a good framework (and I hate MS...), it's like Java but with 10 years of watching all the things Java did wrong, but the areas where it really helps aren't worth the tradeoff for game developers.
It's good for server programs (like J2EE) because of the managed code - less chance for security flaws and harder to take advantage of them if they do exist. It's even okay for plain old application development (the GUI is noticably worse than compiled code, but it's better than Java [under Windows]). But a 3d engine needs the low level control that native code allows.
Re:Dotnet won't rule the world. (Score:1, Informative)
Java is slow for desktop applications because its graphics library is rubbish, not because the VM is inherently slow.
Re:That Giant Sucking Sound... (Score:4, Informative)
That said, "Finalize" in Java and destructors in C# aren't particularly useful. You can't be sure that any managed objects you reference are available during this period, and if you have any unmanaged resources left over, the destructor is a suboptimal place to clean them up, for the 40 second rule and due to the unpredictable time the garbage collector will call these methods. Better to implement IDisposable interface with its "Dispose" method, and provide a "Close" method that calls "Dispose". This give the user more control of cleanup of system resources, but still provides a minimum level of protection for users who fail to protect themselves, since you can fall back on the finalizer if "Dispose" is never called.
Re:C# vs C, DirectX samples (Score:3, Informative)
How good is .NET at heavy calculation? Games are more than just graphics.
If they *were* realistic examples of all the stuff a modern games does, then disregard this post.
My Exp, with .NET and Game Dev Says Yes (Score:5, Informative)
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.
Re:."Managed" anything - e.g. net DirectX (Score:4, Informative)
Re:Dotnet won't rule the world. (Score:1, Informative)
Re:That Giant Sucking Sound... (Score:2, Informative)
Is .NET Relevant to Game Developers? (Score:3, Informative)
Re:DirectX 9.0 for Managed Code (its out already) (Score:5, Informative)
FYI, the DirectDraw interface in managed DX is just a wrapper around making D3D calls. There is no DirectDraw layer ANYWHERE in DX9. The managed interface just makes it easier to do 2D operations, everything ends up going through the 3D driver eventually.
Finally, I agree, the managed DX documentation is no where near as complete as the native DX docs.
managed code: just as pedal to the metal as native (Score:3, Informative)
The JIT compiler performs classic optimizations such as constant folding, constant and copy propagation, common subexpression elimination, code motion of loop invariants, dead store and dead code elimination, register allocation, inlining, and limited loop unrolling (small loops with small bodies).
The resulting code quality is suprisingly good but typically not quite as fast as optimized C++.
What about OOP constructs?
Method calls use essentially the same native instruction sequences as in C++.
Object allocation is typically faster than C++, because the compacting garbage collector doesn't have to search a free list, and because it is adaptive and tuned -- for example, GC policy is sensitive to data cache size. The amortized cost of newing and GCing a small object is down around 20 ns on a 1 GHz P-III -- a fraction of the cost of a single L3 data cache miss.
Of course, you can also have value types (structs) on the stack and in other objects, for which allocation and reclamation is "free".
A few operations are moderately slower than in native C++, since GC and security may incur array bounds checks, checked casts, and write barriers on object field and array stores. But you trade off these costs against functionality and productivity benefits (no heap corruption debugging sessions).
So you can write fast managed code.
It does require learning anew what things cost. Most of us are old hands at C and C++ and know the approximate cost (in machine instructions) of code, and also know what our library calls cost.
In contrast, we're all newbies, babes in managed code land. We don't really know what our code costs, don't know what our library calls cost.
So the secret to writing fast managed code is to measure it and be vigilant. Measure the time and space costs of your code, using your favorite code profiler, using the CLR (Allocation) Profiler, using vadump (if working set is an issue), using timers, and using the debugger to take a look at the generated native code.
Please visit this MSDN site in about two weeks for my forthcoming article, "Writing Faster Managed Code: Know What Things Cost":
[http://msdn.microsoft.com/netframework/]
Jan Gray
Architect, Microsoft CLR Perf Team
Re:.NET is used for game development (Score:4, Informative)
That's like saying "I'm running Java!" because you used a Java-to-native compiler and produced an ordinary native EXE, and then ran it without any trace of Java on the system.
Re:That Giant Sucking Sound... (Score:2, Informative)
The JIT compiler in the CLR generates native code as its needed. It's true, there is a delay once a new code path is executed, but following JIT compilation, the native code version is executed thereafter.
For web pages, there is a signifcant delay when a page is hit for the first time. ASP.NET needs to cache the .ASPX file in a temp folder, generate the code and then JIT it. After that, you're back to running directly from native code.
Re:Yes - but not where you think (Score:3, Informative)
Remember that C# and .NET are robust enough for these - the .NET IDE proves that.
Visual Studio .NET is for the most part not written using the .NET framework. It was developed concurrently with the .NET framework.
Re:.NET is also an IDE, and an optimized C++ compi (Score:3, Informative)
Uh, unless you use DirectX. Which is all COM based.
I prefer cross platform technologies, regardless.
Re:Dotnet won't rule the world. (Score:2, Informative)
Re:C# vs C, DirectX samples (Score:5, Informative)
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.
Re:We could only hope... (Score:2, Informative)
Your problem is thinking of DirectX as a "language" when its not.
Re:That Giant Sucking Sound... (Score:3, Informative)
I have (benchmarking is one of my hobbies
Java once was quite slow but since Java2 and also the last JRE 1.4 there have been huge improvements in the JIT. However many browsers still contain ancient JRE versions, and also the "native" Java GUI (AWT) is not very good/fast. Using another GUI toolkit removes this problem.
Garbage collection can cause some slowness in both C# and Java, but if one takes care and does not use unnecessarily big amounts of instance (i.e. use object recycling) one can avoid this.
DirectX for .Net? (Score:2, Informative)