Is .NET Relevant to Game Developers?

That Giant Sucking Sound... by ackthpt · 2003-04-30 02:31 · Score: 3, Insightful

CLR produces slow code. A trend I observed decades ago appears thus: As hardware capability and processing speed advance, software takes advantage in ways previously unthinkable due to severe degradation of overall performance. Windows isn't fast, it also has overhead, loading up memory with libraries the session might reference. Put .net with it's CLR on top and you get the feeling you've been here before. Yes! It was when people complained how slow Java was.

Well, it's pretty much the same thing. (And before that was UCSD Pascal and P-code) Interpreters don't have brute strength speed that assembler, or even earlier C++ had. Sure, they're quick for instantiating a zillion objects from an already loaded class, but are awful for anything doing heavy calculations. For heavy math/memory moving you'll need tighter native compiled code libraries, which I'm already finding to be a headache. That and unless your game runs in a browser, your players will have to have the .net Framework (~20 meg, of which I note 1.1 is now downloading on Microsoft update.)

So what else does .net have to offer? This whole XML thing? Can't say I've ever considered that a necessity for game play. Maybe it'll allow the player to enjoy games which are Office compatible or such, doesn't seem relevant. I feel .net is not for game programmers, at least action games. Probably fine for strategy games which don't have to do a lot of iterating potential moves.

Then again, maybe this explains the long delays for Star Wars: Galaxies and Duke Nukem Forever...

--

A feeling of having made the same mistake before: Deja Foobar

Re:That Giant Sucking Sound... by Anonymous Coward · 2003-04-30 02:37 · Score: 2, Insightful

What utter nonsense. The CLR isn't that slow at all, and if you do find that you'd like to call a library written in another language, it's trivial to do that in .NET.

Your argument sounds very like the "proofs" we were all given that games would always be written in asm, not in C++. Look at what tosh that is.
Re:That Giant Sucking Sound... by scenic · 2003-04-30 02:37 · Score: 2, Interesting

I thought the .NET framework allowed compiling down to native code?
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...
I'd be interested in the .NET experts out there to comment on the parent post. AFAIR, .NET's main disadvantage is the defering of resource management to runtime. Since you can compile it down, that part of the performance equation isn't so bad. that's IIRC. :)
Sujal

--
politics, food, music, life: FatMixx
Re:That Giant Sucking Sound... by disc-chord · 2003-04-30 02:42 · Score: 4, Informative

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

Oh how I fear for anyone whose source of .NET information is /.

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... by Anonymous Coward · 2003-04-30 02:44 · Score: 5, Informative

Wow have you even tried .NET? This entire slashdot article could have been eliminated with a quick google search.

CLR doesn't produce slow code. It's NOTHING like when people complained how slow java was. That's because .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.)

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 .NET DX9 libraries give you 98% of the C++ performance. That isn't too bad now is it?
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 .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.

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.
Re:That Giant Sucking Sound... by uradu · 2003-04-30 03:10 · Score: 2

> ...and using the simple interop with native code...

Aha, there's the rub. If you assume a pure .NET world, then performance is certainly adequate. But most of the world and much of the component libraries and legacy code currently in use are still mainly COM. Which means that for quite some time yet we will be living with Mr. interop.dll lurking around, along with the very considerable drop in performance that entails. I assume Microsoft is providing a native .NET version of DirectX, because otherwise you would be pining for the blazing performance of IDispatch in the good old days.

That being said, I can't say I will miss COM too much. I think .NET offers many more benefits than downsides, but let's just kill legacy COM code ASAP if we're really going all out .NET.
Re:That Giant Sucking Sound... by Caoch93 · 2003-04-30 03:13 · Score: 5, Informative

...and just like in Java, that control is less than perfect.
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:That Giant Sucking Sound... by johnnliu · 2003-04-30 03:15 · Score: 4, Informative

I'm curious how ask slashdot has become a free goole answers service... The person asking the question should really do some research first.

Some comments here:

1. Is it really the end of COM?

We (any .NET developer) hope so! But alas, I don't think the time has come yet.

2. Will ALL Windows programming be done with .NET?

Sure, you can do the hard core stuff in [Unsafe] C#/C++, leave the rest in .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.

3. DirectX is already available for .NET. Check DirectX 9 SDK, you can use it with C#, VB.NET, etc. There are sample projects everywhere.

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

5. I personally think it's down to what game you are planning to write. If you want to do Doom III in .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?

6. Summary:

If you are referring to using DirectX 9 with .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.

If you want to do stuff like Diablo/Starcraft in .NET - as long as the user has sufficient memory I don't see why you can't.

Don't do Doom III in .NET please.

jliu
Re:That Giant Sucking Sound... by arkanes · 2003-04-30 03:21 · Score: 2, Informative

.NET does NOT allow compiling to native code. What you can do is compile your assembly to a Win32 executable ( a clever little hack that stores the bytecode and a stubloader for the framework). This confuses some people (since you get app.exe, they think it's native code - it's not).
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:That Giant Sucking Sound... by Tattva · 2003-04-30 03:25 · Score: 3, Informative

The Finalize method, or destructor, will execute in most situations. MS in the .NET beta said finalizer methods of remaining objects would not necessarily execute upon process shutdown. They have ammended this in the release to say that if the finalize process (of every leftover object) upon process shutdown takes longer than 40 seconds, finalization will be terminated and any remaining objects will not be finalized.
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.

--
personal attacks hurt, especially when deserved
Re:That Giant Sucking Sound... by jhamm_ccs · 2003-04-30 03:53 · Score: 2, Informative

You actually _CAN_ compile C# to native code at deployment time. C# has a nice utility named ngen which will essentially run the JIT and store the compiled code as a native image. While you still have the performance overhead of running in a managed environment, this does reduce the loading time significantly.
Re:That Giant Sucking Sound... by Tony+Hoyle · 2003-04-30 04:51 · Score: 2, Insightful

The CLR is really very slow. When I first came across it at an MSDN demo they were running it on really fast machines and it still obviously dragged on the simple app they were writing. I've got the misfortune of having to do some stuff in it (mostly a frontend to the C++ backend because we *need* speed) and I'd estimate it goes between 10 and 20 times slower than native code (~5 seconds to generate a single web page on a Dual P4).
Re:That Giant Sucking Sound... by nightcrawler77 · 2003-04-30 05:02 · 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.

--
"Power corrupts, and absolute power corrupts absolutely." -- Lord Acton
Re:That Giant Sucking Sound... by nightcrawler77 · 2003-04-30 05:09 · Score: 4, Insightful

I hear a lot of complaints about the lack of deterministic finalization, but I really have to wonder why people care so much about when the memory is actually freed for a particular object.

Most complaints center around the fact that you don't know when your destructor is going to execute. That's a valid concern, but there is nothing that really separates a destructor from a regular method. If you have some clean-up that needs to happen, put it into a Dispose() method and call it yourself. Pretty simple.
"But the memory isn't freed after I call Dispose()!"...who cares? Just let go of your reference and let the GC handle it. You've executed your cleanup code, so why do you care that there is a block of memory out there that you can't even see that's still allocated? It's not going to leak, so just let the GC do it's job.

--
"Power corrupts, and absolute power corrupts absolutely." -- Lord Acton
Re:That Giant Sucking Sound... by Caoch93 · 2003-04-30 05:38 · Score: 4, Interesting

I hear a lot of complaints about the lack of deterministic finalization, but I really have to wonder why people care so much about when the memory is actually freed for a particular object.
Technically, you're talking about two different things. Finalization is the "end of lifecycle" processing of an object, beyond which the object becomes semantically meaningless. Removal from memory of the "dead bytes" of that object is something different. The reason people often complain about deterministic finalization is because, without it, you have no control over when the object's cleanup happens. You know you don't need that object anymore, but you can't actually get rid of it. That can be annoying, especially if you come from a C or C++ background and are very much accostumed to being able to control everything.
Being able to control finalization and memory frees (which are technically not coupled in Java or .NET memory managed code) can also be really important when you're either in a small memory space (J2ME) or you're writing server software like a J2EE container. The reason why is because, bascially, you're replacing your intimate knowledge of your own software with some best-guess heuristics. There's little I know of that's worse than a thrashing GC, and this can be avoided if you can micromanage memory collection to happen at more opportune times. Some JVMs (Sun's, most notably) allow you to tune their GCs to help prevent this through a control of the amount of memory given to objects of different ages. This can be quite helpful in performance tuning.
If you have some clean-up that needs to happen, put it into a Dispose() method and call it yourself. Pretty simple.
I don't know enough about .NET to comment, but if there's an interface you can implement to provide uniformity in the call and use of that method, that's great. Java, AFAIK, has no such interface, so hand-made deterministic cleanup is idiosyncratic. That's okay, but it's not ideal. What's more, though, let me ask you this- in some large middleware or object framework following your idea, what guarantee is there that your disposal method won't accidentally get called twice? This could lead to indeterminate states in the system that aren't immediately understood, since there's no check against that implicit. At least with a C++ destructor, destroying the object guarantees that further use of the object is impossible. No such guarantee is available with homespun management. Yes, the roll-your-own you're describing is good enough, but that doesn't mean it's without flaw.
...who cares? Just let go of your reference and let the GC handle it. You've executed your cleanup code, so why do you care that there is a block of memory out there that you can't even see that's still allocated? It's not going to leak, so just let the GC do it's job.
Maybe, but again, think about situations where you're trying to minimize memory use. Deterministic destruction makes memory immediately available again. You can put a new object in that freshly freed memory. With a GC, that may not be possible. Thus, I dispose() my object, which scrubs it clean, then I throw it to the wolves...only they're not hungry just yet. I go to make a new object, and that memory isn't available. On most systems, this will force the GC to mark the dereferenced object's memory as fair game, yes, so this isn't a big big deal, but the decoupling described can lead to ickiness. Also, as I mentioned, having memory deallocation occur synchronously to my call to a destructor means the GC will never thrash. GC thrashing seriously slows a program down, and after thrashing and thrashing, it still might not have the memory you're looking for (for various reasons).
In my experience, the loss of control that results from being in a GC environment is neither as big a deal as its oponents make it out to be, nor is it as little a deal as its proponents make it out
Re:That Giant Sucking Sound... by ADRA · 2003-04-30 06:10 · Score: 3, Interesting

The main difference between the ASM->C/C++ and C/C++ -> .NET leap is that the .NET cdoe cannot be tracked down to efficeincy buy looking at it. A skilled C++ programmer will know the weight of the commands they call, and in a lot of cases, optimize the code to be close to ASM levels of performance most of the time. .NET has no to-hardware pass-through by design which means optimization lay in the jit-type area where programmers cannot control performance.

About your first statement, the only (slight) adcantage that your first statement means is that instead of having an in-game scripting language in your game, you could compile a real scripting engine into your code. Otherwise, there is no use for cross-language games programming.

Porttability hasn't been touched yet. Does anyone think this would help games development to other platforms???

--
Bye!
Re:That Giant Sucking Sound... by Baki · 2003-04-30 08:51 · Score: 2, Informative

.NET is NOT faster than Java. Those who claim it is have only been listening to MSFT marketing and/or not tried for themselves. Have YOU even tried a Java version from the past 2 years?

I have (benchmarking is one of my hobbies :) ) and in average Java was 30% faster than C#. Both are pretty decent however, compared to native code (which is about twice as fast). Note I have been measuring pure language + JIT + VM speed, not the libraries. Java's standard libraries are better than .NET, which is only logical given .NET is still quite new.

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.
Re:That Giant Sucking Sound... by juggleboy · 2003-04-30 10:01 · Score: 2, Insightful

3. DirectX is already available for .NET. Check DirectX 9 SDK [microsoft.com], you can use it with C#, VB.NET, etc. There are sample projects everywhere.
Also available is DirectX for for Visual Basic. Yet for some reason I don't see many Visual Basic games being released.
If you want to do stuff like Diablo/Starcraft in .NET - as long as the user has sufficient memory I don't see why you can't.
On the other hand, if you could code your Diablo/Starcraft clone in C++ and halve the system requirements, why on earth would you dream of coding it in .NET?

Dotnet won't rule the world. by dtolton · 2003-04-30 02:35 · Score: 5, Informative

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

Re:Dotnet won't rule the world. by ackthpt · 2003-04-30 02:53 · Score: 2, Informative

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

--

A feeling of having made the same mistake before: Deja Foobar
Re:Dotnet won't rule the world. by danro · 2003-04-30 02:58 · Score: 2, Insightful

How many highgrade professional games are written in Java currently?

None.
But that is largly because of javas lingering performance issues.
Everything running on a VM has to have some extra overhead compared to native code, but .NET, unlike Java has the luxury of not having to be platform independent, and should have less of a problem in this departement.
(In fact, not being platform independent is a plus for MS. They will need something to prop up their OS business in an age of increasingly commoditized* operating systems.)

I think .NET may have the potential to become suitable for games programming.
These parts of .NET will of course be hopelessly tangeled with the windows operating system (moreso than the winforms parts), ie. hard to port and utterly unusable on other operating systems.

Or, I may be talking out of my ass here.

*) Read: GNU-Linux and friends...

--

"First lesson," Jon said. "Stick them with the pointy end."
Re:Dotnet won't rule the world. by Anonymous Coward · 2003-04-30 03:04 · Score: 2, Funny

I've said it before and now I'm ready to beg. Enough with the carriage returns! Our browsers word wrap automatically just fine!
Re:Dotnet won't rule the world. by Asprin · 2003-04-30 03:15 · Score: 5, Interesting

Of course, that really only applies to people who want to use a Microsoft product for building games.
...
In reality I think dotnet is what everyone thinks, a competitor to Java. How many highgrade professional games are written in Java currently?

You got me thinking, so I'm going to take a flyer here.

Remember back in the **OLD** days when Atari, Commodore and Apple games weren't launched from the OS, they were loaded from a boot floppy because we really didn't have OS's back then? (Unless you purchased CP/M, of course.)

Well, Knoppix has demonstrated an absolutely ridiculous level of competence at autodetecting hardware, and since . Would the gaming industry consider the possibility of using Linux as a development platform in a trend back to using bootable disks for games?

Think about it: a bootable CD that has the Linux kernel, drivers, support libraries and your game code.

PRO: [Fully customizable and optimized kernel] + [NO OS OVERHEAD or CPU/RAM competition] ----------------- = [Mad crazy performance out the wazoo regardless of what other spyware crap the boneheaded user has been suckered into installing.] PRO: OpenGL, Internet Integration, divers filesystem support for saving games to floppy, hard drive, memory card, cdrw, THE INTERNET. PRO and CON: Potential for DRM and proprietary CDROM file systems to limit piracy and legal backups. PRO: Their kernels would be open source, so we could see if they were spying on our hard drives or personal data. (This might be a big problem because you're giving their cd exclusive control of your PC to play a game.) PRO: Reduced support costs - you'd be distributing an embedded system that only includes the drivers YOU specifically choose. CON: Game developers may start developing drivers again. (**shudder**) CON: No downloading or listening to MP3's in the background while playing Half-Life anymore, though they could certainly throw in those feature if they wanted to. Woah... Am I on to something?

Anyone else have any ideas to add?

--
"Lawyers are for sucks."
- Doug McKenzie
Re:Dotnet won't rule the world. by Mr.+Shiny+And+New · 2003-04-30 03:40 · Score: 3, Insightful

This has been an entire /. article before, if I recall. And I think mainly it isn't worth the trouble; it means that games won't work on the latest hardware; it means you have to reboot to play games; it means that you have to essentially single-task. no more printing, downloading, whatever.

The task of building a "game" distro would be complex; a game company would have to spend lots of time building it; otherwise, it has to be outsourced. If you're not building it, why are you shipping on only that OS? If you are concerned only with certifying on one platform, why not just pick a popular platform and say "we only support X". It's easier and keeps the users happier.
Re:Dotnet won't rule the world. by Hard_Code · 2003-04-30 04:52 · Score: 2, Insightful

Then again, I do NOT want arbitrary games to have complete superuser access to all my hardware. What an absolute nightmare. Some sort of "special" kernel mode that disables many things and gives utmost priority to one process might suffice. But then again, you can sort of already get this with a modular kernel, process nicing, and an intelligent schedular.

--

It's 10 PM. Do you know if you're un-American?
Re:Dotnet won't rule the world. by mrlpz · 2003-04-30 05:10 · Score: 2, Informative

Are you like, high on cattle fodder or something ? Windows Forms is SPECIFICALLY platform DEPENDENT, it sits atop Win32 ( albeit quite poorly...every try to easily change font attributes without having to destroy and re-create objects galore ? ). It's a part of .NET that will NEVER get sent to a standards organization. Probably because the clamoring of OPENING UP the API would be more than they would care to deal with.

DirectX 9.0 for Managed Code (its out already) by tsinbad · 2003-04-30 02:36 · Score: 5, Informative

DirectX 9.0 for Managed Code
(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® .NET
Microsoft Visual C++®
Microsoft JScript® .NET

http://msdn.microsoft.com/library/default.asp?url= /library/en-us/directx9_m/directx/directx9m.asp?fr ame=true

Re:DirectX 9.0 for Managed Code (its out already) by anonymous+loser · 2003-04-30 03:52 · Score: 4, Interesting

Actually a couple of weeks ago I decided to try out the managed directx 9 stuff, so I sat down and wrote a Tetris clone in C# .NET.

The first thing I noticed is that unlike previous versions of DirectX, the managed DirectX API is very different depending upon which language you are using. For example, in C# I used a lot of DirectDraw functions to draw all of my screen elements. When I had my game up and running, I looked into what it would take to port to C++. Well, there is no "DirectDraw" object in the C++ API. According to MS, all of those functions have been folded under the Direct3D object in C++. The names are mostly different, and some of the methods and properties in DirectDraw didn't seem to have directly equivilent methods in the C++ Direct3D API. My question is if they decided to put those functions under Direct3D, that's fine, but why did they make it completely different in C#? Why not just use the same API for all the languages? It's not like C# can't support it.

That, and the documentation was spartan at best. There were several pages of documentation which just had function headers with cryptic parameter type names as the arguments. It sorta reminded me of reading documentation for some of the OSS projects I've developed stuff with. Sure, you can figure it out through educated guesses trial-and-error, but as a developer that's not how I like to spend my time.
Re:DirectX 9.0 for Managed Code (its out already) by nick+this · 2003-04-30 04:19 · Score: 2, Insightful

And there were DirectX interfaces for Visual Basic, too, but for some reason Id decided not to do Doom 3 in VB. Go figure.

It's really a question of appropriateness. C# isn't appropriate for games. My guess is that the whole reason for Managed DirectX is to allow apps to do visualization and stuff... so that managers can look at sales figures as a cluster of three-d spheres or something stupid, not to write a 3d shooter with.

That's not to say you couldn't... wrong tool for the wrong job, but you could probably do it. You could probably fry an egg in a toaster, too... it would just be messy as hell. Not to mention stupid. Kinda like game programming in C#.
Re:DirectX 9.0 for Managed Code (its out already) by djohnsto · 2003-04-30 04:27 · Score: 5, Informative

It looks as though you were using the unmanaged (a.k.a. native) version of DirectX when doing the C++ port. You could use managed C++ and use the managed DX bindings. If you had done that, the DX interfaces would be EXACTLY the same between (managed) C++ and C#. This is because you would be using the exact same interfaces. The managed interfaces to DX are greatly simplified and a little less flexible than the native C/C++ interfaces.

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.

--
Dan

Based on what microsoft has done in .net games NO by will_die · 2003-04-30 02:37 · Score: 4, Informative

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?

Re:maybe developers would wise up then.... by dwgranth · 2003-04-30 02:38 · Score: 2

ACK! There is even a plugin for VB.net in OpenGL oh cruel world

Visual Studio .Net is, Managed code is not by Master_Flash · 2003-04-30 02:38 · Score: 2, Interesting

I asked this question at a .Net seminar and the naswer was. Use the non managed version of C++ for game development but NOT the managed code. Two reasons. Managed code is slower. Also calls into and out of the CLR are very slow if you are mixing managed and unmanaged code.

--
The home of the 3D Socialization and Interaction Engine

Uh huh by stratjakt · 2003-04-30 02:44 · Score: 5, Insightful

Will games be written with .NET?

Yes

Will all games be written with .NET?

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 .NET than are written for Linux?

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!!!!

Re:Uh huh by bogie · 2003-04-30 03:54 · Score: 4, Insightful

"Was this article posted just to give zealots a chance to yammer about MS world conquest and other conspiracy theories?

Yes"

Actually No. The only zealous act here is what you say in your 7th point which bashes linux users. The poster asked directly about the future of gaming on Windows. The entire post along with its many questions on how this relates DIRECTLY TO GAMING ON WINDOWS is below if you feel like reading it again.

"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?"

Zealot - n.
The most overdone word in the geek lexicon.

--
If you wanna get rich, you know that payback is a bitch

XML Thing... by redragon · 2003-04-30 02:46 · Score: 3, Insightful

So what else does .net have to offer? This whole XML thing? Can't say I've ever considered that a necessity for game play. Maybe it'll allow the player to enjoy games which are Office compatible or such, doesn't seem relevant.

XML is great for game development. Would I ever distribute a game that uses XML at run time? Probably not. Will I use it for development, and "compile" things down later? Heck yes. A lot of developers forget how nice it is to be able to let your artists play with all sorts of settings and make things dynamically, XML isn't the nicest interface, but easier than bugging a programmer to tweak something for you. However, you really don't need .NET for XML. It's easy to use, sure. However, Xerces C++ interface isn't that bad, and just about anyone can stick a simpler interface on it.

I tend to agree that the CLR is slower than compiling down to machine code. However, I've also seen some pretty cool Java based game development. I think it comes down to the game itself...if it's pushing hardware limits, then .NET is a no go. If it doesn't push the hardware, why not?

--
- Sighuh?

No, game development will still be the same... by Fallen+Kell · 2003-04-30 02:46 · Score: 4, Interesting

... at least for now. .NET is a "good" idea in theory. But it's performance is just not up to par compared to the execution times of applications using .NET vs C++.

It is the equivelent of placing another abstraction layer on the executable code before it is executed. This inherently decreses performance of the application (its something like the equivelent of writing a game in perl... it relies on the perl interpreter to create the actual executable code which is why something written in perl takes longer to execute then something written in C++ (I know there is a debate on this, but for the majority of cases this is true, however, it is also true that it may be 1000x easier to "code" the application in perl vs C++))

If MS optimizes their interpreter, then in theory, it will eventually become almost as fast as C++, and at that time, it may be worth the benefits of coding in .NET for the applications. .NET is fairly easy to code many types of applications, but when performance of the final executable is your major goal, then .NET is really not the language for you.

--
We were all warned a long time ago that MS products sucked, remember the Magic 8 Ball said, "Outlook not so good"

.NET and Passport are not the same thing by Anonymous Coward · 2003-04-30 02:48 · Score: 2, Informative

People keep asking the (dumb) question "but if you build it with .NET then I'll have to have Passport/reveal my shoe size to Microsoft/bring about the downfall of Western Civilization in order to use it, right? WRONG... RTFM. .NET is just an application development framework (a very comprehensive one at that). You may be thinking instead of the erstwhile "Hailstorm," which is not the same thing as the .NET application development framework, and to my knowledge is basically a failed initiative at this point. People who have never developed any .NET code should probably refrain from pontificating about its shortcomings.

There is already Managed DirectX for .NET, as others have pointed out, and this makes good sense considering how easy it is to call COM code from .NET. To those whining about how slow CLR code is, I suggest you actually try it and benchmark it before opening your mouth... Java it is *not* (hallelujah)...

What exactly is the point of .NET? by Dr.+Bent · 2003-04-30 02:49 · Score: 2, Interesting

Could someone explain to me exactly what .NET is good for, that couldn't be better accomplished using Java, or Win32/C++, or PHP? Seriously.

I can't see it being useful for games, because it's going to be slower than C++.

I can't see it being useful for cross-platform GUI apps because there's no guarantee that .NET really is cross-platform.

I can't see it being better than any of the various web development solutions (PHP, cold fusion, etc...)

I can't see it being useful for enterprise server side apps because Java is more mature, more reliable, and has a VM implementation on lots of different platforms.

I can't see it being useful for PDA/Phone apps because the framework is too heavyweight.

So I know that it's new and shiny and Microsoft....but what, exactly, is it good for? What can you do with .NET that you can't do better with something else?

Re:What exactly is the point of .NET? by telstar · 2003-04-30 03:10 · Score: 2, Insightful
"I can't see it being useful for cross-platform GUI apps because there's no guarantee that .NET really is cross-platform."
- For many users and industries, they don't care if something is cross-platform. They invest their money in a single platform, and as long as their stuff runs on it, they're happy.
Re:What exactly is the point of .NET? by soulhuntre · 2003-04-30 03:38 · Score: 4, Insightful

Could someone explain to me exactly what .NET is good for, that couldn't be better accomplished using Java, or Win32/C++, or PHP? Seriously.

Seriously? I doubt many people will actually pay any attention to the answers.

I can't see it being useful for games, because it's going to be slower than C++.

While it may be slightly slower (and I mean slightly) the problem is easily solved and/or irrelevant. because your calling the highly optimized stuff in DirectX for most of the graphics work your speed issues are minimal and any core routing that is really slowing you down can be coded in something else without forcing the whole project into a less useful environment.

I can't see it being useful for cross-platform GUI apps because there's no guarantee that .NET really is cross-platform.

For most developers the issue of cross platform is irrelevant. In general I can support most biz needs via a web service anyway or in Windows. The rest of the world is Mac (and there WILL be a Mac implementation because Office on the Mac is a good cash source) or Linux - and Linux is irrelevant for this type of thing.

I can't see it being better than any of the various web development solutions (PHP, cold fusion, etc...)

Then you haven't looked very hard. The Web controls, event model and code behind features are light years ahead of CF and PHP. mod_perl isn't even a player.

I can't see it being useful for enterprise server side apps because Java is more mature, more reliable, and has a VM implementation on lots of different platforms.

The enterprise level apps I have been involved with are either Intranet based (and this .NET is perfect) or Windows based. In both cases .NET is a great environment and has strong advantages over Java. Besides, given how much Sun is throwing their weight around with Java most firms see java as a single source tool and Sun is a much less attractive partner.

I can't see it being useful for PDA/Phone apps because the framework is too heavyweight.

You can cut the framework down for custom applications.

So I know that it's new and shiny and Microsoft....but what, exactly, is it good for? What can you do with .NET that you can't do better with something else?

It's as good or better than Java, runs as fast as C++ and is much easier to code for than Win32. The web event model rocks and the ability to mix languages kicks ass.

In short, it's good.

--
--> Fight tyranny and repression.... read /. at -1!
Re:What exactly is the point of .NET? by fgb · 2003-04-30 04:26 · Score: 2, Funny

"I can't see it being useful for cross-platform GUI apps because there's no guarantee that .NET really is cross-platform."

Of course it's cross-platform. It runs on 2000, XP and .NET Server!

.NET is also an IDE, and an optimized C++ compiler by spaten-optimator · 2003-04-30 02:49 · Score: 5, Informative

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.

Re:Doubtful. by salimma · 2003-04-30 02:50 · Score: 5, Informative

Aren't people aware that the things were invented in America in the 1800s by Chinese immigrants seeking to differentiate their restaurants in the mining communities?

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

.Net and Games - It is a reality by Anonymous Coward · 2003-04-30 02:53 · Score: 4, Interesting

way back when .net was still beta and machines were at least 1/2 to 1/4 the speed they are today I saw a demo of Quake 2 models being rendered in .net flawlessly - and this was using OpenGL and an ultra craptastic laptop.

Fast forward two years with Managed DirectX and you have a pretty decent system for writing games with fewer bugs because you are not likely to encounter certain errors (memory leaks for one). Games like Unreal Tournament 2003 and Doom 3 will obviously be tuned using assmebler and written primarily in C/C++ ... but I think many games in the future (maybe 3-5 years) will be using .net simply because it makes developing that much easier.

I have benchmarked some encryption routines I wrote in school back in the day, and they were originally done in Java. The Java code started much slower (stupid JVM - big issues) but once everything was in ram and cruising along it wasn't much slower than C++... with .NET it actually ran slightly faster than my C++ code (probably because of being able to instantiate and destroy objects better). I am a big believer in .net and can't want for better cross platform support

Yes, But by sjvn · 2003-04-30 02:56 · Score: 4, Interesting

It's not like Microsoft developers will have much choice in the matter. The new Visual Studio is bult around .NET, the title gives it away: "Visual Studio .NET 2003."

But, what does that really mean? Good question, Microsoft is backing off from calling everything .NET because they overused it to the point that the term became essentially meaningless. With the newest VS, it boils down to you can use the .NET Framework (think object-oriented, component-based API), try mixing code from different lanaguages with CLI, and run C#. Oh, and it makes easier to use the still betaish ActiveX.

Does any of that make sense for a game programmer? Maybe, but since performance is everything to gamers, I suspect it will be a while before we'll see such games. Learning how to exploit .NET Framework means wrapping your mind around what, for many programmers will be a new way of developing programs. Simply knowing objects by way of C++ won't cut it. Because of that aspect, I don't see that using old languages via CLI will help that much to get killer performance. And, as for C#, I've never liked it that nuch, and while I know lots of folks who will argue over its functionality, especially over Java, and vice-versa, I seldom hear anyone comparing it performance numbers to those of C or C++.

Bottom line, yes, it will get used because for some developers VS .NET will be the only tools they have for Microsoft OSs. But, will it lend itself to producing killer games? Maybe someday, but I don't see it happening for another couple of years myself. For now, were I a game programmer, I'd be sticking to C and C++.

Steven

Re:Doubtful. by reg106 · 2003-04-30 02:57 · Score: 4, Interesting

Hi,

Where did you get that information on chopsticks? It sounded like interesting story to have on hand, so I took a look at Enclopedia Brittanica, which said:

"Chopsticks of bamboo or wood, and subsequently of ivory and precious metals, originated in China as early as the Shang dynasty (c. 1766-c. 1122 BC) and from there spread throughout East Asia. In China, the substitution of chopsticks for knives at the table reflected the ascendancy of the scholar over the warrior as a cultural hero."

Which would seem to indicate that chopsticks were around for several millenia, and also gives some basis for the pretension associated with them. Do you have any further references on the use of chopsticks in mining restaurants in the U.S.?

Is it really the end of COM? by Jack+William+Bell · 2003-04-30 02:59 · Score: 4, Insightful

The rest of the questions asked have already been answered, so I am going to tackle "Is it really the end of COM?"

Uh... Was Windows 95 the end of MS/DOS? Was COM the end of DDE? Microsoft has a tendancy to wrap up stale old code in fresh new interfaces and let their Marketing people slap a new name on it. Sometimes those interfaces aren't all that fresh; ActiveX was mostly just a rename of COM with a couple of extra methods.

So the answer is no. At least not right away. Maybe ten years from now, but by that time Microsoft will be pushing some new technology without admitting that their new thing has .NET under the hood...

--
- -
Are you an SF Fan? Are you a Tru-Fan?

Re:Is it really the end of COM? by johnnliu · 2003-04-30 03:20 · Score: 2, Interesting

.NET is COM interoperable, but is not COM.

When MS tried to make Java COM/MFC interoperable, Sun sued them. That's why there's now .NET.

jliu

VC++ 7 might work by kko · 2003-04-30 02:59 · Score: 2, Interesting

VC++ 7 (which uses the VS.NET IDE) might work for games. AFAIK, VC++ 7 generates native Win32 code, while the other languages generate CLR code.
I have no idea how fast VC++ 7 is compared to the previous versions, but I know for a fact it's way faster than C# code (and I guess it kicks VB.NET in the balls).
Some of the managed classes might be useful for some aspect of a game (savegames is the only thing that I could come up with right off the top of my head), yet .NET code is painfully slow.

--
No, seriously, I just come here for the articles.

C# vs C, DirectX samples by SteveX · 2003-04-30 03:00 · Score: 4, Interesting

Here's one data point: When the SDK came out I compared the framerate of the DirectX samples in C with the framerate of the equivalent samples in C# (most of the samples are available for both, as examples).

The framerates were very similar - the .NET code lost some benchmarks, but it won a few and on the vast majority, they were within a few percent.

There doesn't appear to be any huge disadvantage to using .NET to write games.

One big advantage, however, is CPU portability - with two flavours of 64 bit CPUs just around the corner, plus different optimization strategies for P4 vs Athlon, having bytecode that gets compiled for your CPU when the game is run will be a big advantage if you happen to own anything but a P4.

It's doubtful that anyone's going to ship a game CD with an Itanium build of the binaries, but if it's .NET, then they don't have to.

- Steve

Re:C# vs C, DirectX samples by ZigMonty · 2003-04-30 03:26 · Score: 2, Informative

What were the examples? If they're mostly doing graphics stuff (rotating cubes, etc) then why would there be any difference? That's either native code or hardware accelerated.
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.
Re:C# vs C, DirectX samples by Tattva · 2003-04-30 05:26 · Score: 4, Informative

.NET should be excellent at heavy calculation. Things like math compile down to native code and don't really incur any overhead. The overhead of managed languages like .NET are in method invocation, accessing advanced features like runtime types that aren't available in other languages anyway, exception handling, and a larger memory footprint. Arguably, the last two are the only "real" significant disadvantages.
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

C++ will NEVER replace assembly in Game Coding!! by FortKnox · 2003-04-30 03:01 · Score: 4, Interesting

This is great. So many "NO WAY! .NET IS TOO SLOW!" reminds me of assembly programmers saying "C++? Its slow and a memory hog! Games will NEVER be programmed in C++!!"

Well, you can read some books on using DirectX9 for .Net, or even play some games that were made with directX and .net.

While computers gain more powerful hardware (faster CPUs, bigger memory, etc...) the coding for games will go forward to the newer languages that makes coding easier. You may not like it, but don't worry. There's always jobs for those with assembly knowledge.

And, for what its worth, I think game coding in Java will start becoming a reality in the next five years (and not just on PDAs and mobile phones)...

--
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!

Excuse me by Guilly · 2003-04-30 03:03 · Score: 5, Informative

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.

Will ALL Windows programming be done with .NET?
no. A whole bunch of DirectX developers that use it because they don't know any better will probably move on to .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).

If games aren't developed with .NET and Microsoft is killing COM, then what future for games development on Windows?

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 and COM programming in one step.

Re:Doubtful. by kahei · 2003-04-30 03:05 · Score: 4, Funny

[chopsticks] were invented in America in the 1800s

I think that's probably the most easily-disproved wild assertion I've ever read, even on /.

There should be a special prize or something.

--
Whence? Hence. Whither? Thither.

The future by MagPulse · 2003-04-30 03:07 · Score: 5, Informative

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

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 .NET evangelist, would answer with "a resounding no".

Re:The future by RhymeAndReason · 2003-04-30 06:20 · Score: 2, Interesting

Why would microsoft put effort into developing attributed programming for VC++ 7, which provides a much easier way to create COM components, if they were intending to kill it immediately? .NET is set up to be the successor of COM, but COM seems to be very much alive in the realm of unmanaged C++.

Yes! by GeckoUK · 2003-04-30 03:15 · Score: 2, Informative

Writing lightening fast engines optimised to a specific console is only one small part of writing a game.

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? by Hellraisr · 2003-04-30 03:16 · Score: 2, Informative

You can still make regular C++ programs with Visual Studio .NET and not have to use the .NET framework.

Otherwise, .NET framework is useless to a game programmer. It adds a lot of bulk and crap that you don't even need in the first place. The first thing you do to make a game is to #DEFINE WIN32_LEAN_AND_MEAN which takes out all the crap. Then you create a window and use DirectX through it.

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. .NET Framework is basically dumping a bunch of more libraries and components on top of what you already have, increasing the overhead and forcing you to compile into a not-quite .exe

It's decent for apps but games are high-performance.

Dependency of .NET framework by jalilv · 2003-04-30 03:18 · Score: 4, Interesting

The .NET framework on Windows is entirely dependent on existing Win32 APIs and COM technology. Although Microsoft is encouring people to drop the use of COM and Win32 APIs, they themselves heavily depend on these technologies. As it is now, the .NET framework is just a wrapper around existing APIs (COM and Win32). The C# comipler has been implemented using COM, csc.exe being a wrapper around this COM C# compiler. The VS.NET IDE depends heavily on COM. The .NET framework is huge (more than 3000 classes) but only 15-20% of APIs have been covered by these classes. Apparantly, that is enough to write usual application.

<plug class="shameless" >

I have written an article called Whats the need for .NET where in I argue if there was a real need for MS to come up with .NET. The statements I made above have been backed up in the article by providing links to the comments that MS employees have made about this.

</plug >

Jalil Vaidya

short memories by avandesande · 2003-04-30 03:18 · Score: 4, Insightful

Rember how many years before game programmers moved away from dos booting games to windows games (for performance reasons) the same thing will happen with dot net. Ask me again in 5 years.

--
love is just extroverted narcissism

Re:I call bullshit by RabidOverYou · 2003-04-30 03:19 · Score: 3, Funny

> they were invented by a Japanese American in this century.

Whoa, I could have sworn I saw them as far back as 1998.

Yes - but not where you think by Donut · 2003-04-30 03:20 · Score: 5, Interesting

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.

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

Remember that C# and .NET are robust enough for these - the .NET IDE proves that.

I won't go into why C# and .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.

-Donut

Re:Yes - but not where you think by smallpaul · 2003-04-30 05:03 · Score: 2, 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:Doubtful. by gpinzone · 2003-04-30 03:20 · Score: 3, Insightful

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.

How do you know if the Chinese inventor of the fork just didn't market his or her idea well enough for it to catch on? Either that or maybe people resisted the change since they didn't want to give up the simplicity of braking twigs off trees to eat? Just because a technology is superior doesn't make it the popular choice.

Re:maybe developers would wise up then.... by arkanes · 2003-04-30 03:25 · Score: 2, Interesting

VB .NET isn't really VB anymore. C#, VB .NET, and J# are all more or less the same language (there's slight differences in what they allow you to do at the lower levels of the framework), the main diffrence being what language they're syntatically close to. VB .NET exists soley to move the massive base of VB "developers" to the .NET platform (a huge step up from raw VB, and maybe some of them will earn that title now), C# is the refrence implementation language (kind of a cross between C++ and Java) and J# is almost identical to Java (syntatically), designed to lure Java programmers.

My Exp, with .NET and Game Dev Says Yes by ben+h · 2003-04-30 03:28 · Score: 5, Informative

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.

ExoEngine - A C#, OpenGL .NET 3D Engine

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.

Yahoo! Games by yerricde · 2003-04-30 03:47 · Score: 2, Insightful

How many highgrade professional games are written in Java currently?

Do you claim that Java platform games such as Cubis and Bookworm available at Yahoo! Games either earn low marks, or are not written by professionals, or both?

--
Will I retire or break 10K?

The framework will be the framework by RhettLivingston · 2003-04-30 03:50 · Score: 4, Interesting

By naming their new framework .Net and focusing marketing on XML, MS has taken advantage of the hype that everyone's eyes are currently on to produce a radically improved API. I'd say

The truth is that Visual Studio 7 is the most comprehensively advanced programming environment I've ever seen and it easily supports a 10 fold increase in programmer productivity versus VS97 due to the quadruple whammy of what I see as Microsoft's first truly pro editing environment, a near complete elimination of language wars by forcing all to be equal in capability and to share objects, a far more comprehensive and easy to use object oriented API than Win32, and the end of the registry and associated DLL hell.

While everyone's watching the bouncing hype ball, 95% of what's good in the framework has been ignored. I believe this is Microsoft's intent.

Where will they go? In two to three years I think we'll start hearing about an OS release that has a CLR interpreter that doesn't run on Win32, but has everything needed natively present to run directly on a kernel. Suddenly, all of the .Net code will be vastly faster and Win32 will be scheduled for deprecation. .Net has nothing to do with the net or with XML, it has to do with replacing the Win32 framework with a new framework. For now, its a framework running on a framework and will thus be slow. Eventually, it will be THE framework doing nothing except what IT needs to do and will cook.

As much as they seem to gripe and make noise about other .Net framework implementation efforts, I think they are really hoping that its done and everyone converts to it. A .Net application running on top of a .Net framework running on top of any of Win32, Linux, or OSX will never be as fast as a .Net application running on a .Net OS. If done with enough slight of hand, its a perfect recipe for a complete coup.

A Caviet for .NET by RembrandtX · 2003-04-30 03:52 · Score: 3, Insightful

A while ago our MS rep came in for his bi-monthly visit. And he let something slip.

The next desktop version of windows is supposed to be a database structured OS. SO basically everything from word documents, to e-mail, to images are essentially .NET datatypes.

Sounds kinda cool actually. Now walk with me ...

Any file could be shared with another computer, by basically sending it to a 'routing' computer.
So e-mail wouldn't be like it is now, nor would web pages, they would be sent to a .NET server which would pass the 'package' on to the reciepient. [This is all out of memory, which is fuzzy .. so who knows if im getting it all EXACT.]

What I do remember with shocking clairity was having the epiphany that if everything has to be routed through a .NET server (which our REP said would make it a lot more secure than it is now .. har-har) then WHO is going to be making those servers ?

MS is pushing SOOO very hard for .NET now .. because simply - if it DOESNT get widely adopted than Stage II(tm): Take over the server market by making the desktops REQUIRE MS.NET routing servers, will be as successful as Licence 6.0.

Whats the easiest way to get rid of Apache ? make windows not play with it. They can't control the *nix OS's out there, and they cant put the genie back in the bottle, but they CAN alter their OS to ignore the genie, and maybe make it look like he is wearing a dunce cap.

That being said. .NET [or Dot-Nyet as my russian friends call it.] is kinda neat. Once you get used to the 10-15% loss of speed. And the higher memory requirements on your servers.

I'm just afraid that this innovation in programming languages is more about gaining control, than improving computer science.

After all - most of our cars still run on gasoline WHY ?

--

--Ne auderis delere orbem rigidum meum, non erravi pernicose!

The bigger picture by seangw · 2003-04-30 03:53 · Score: 2, Insightful

We shouldn't be looking at how current implementations of .Net would slow current methodologies in game development.

I remember back in the 80s receiving an apple magazine with printed basic code for games. It was great, you could always reference the code line by line, very simple.

How could we get information out if we're using this new "object oriented" design? Modify class X with method Y and add the following code?

It's a bad example.

With the new Gigabit ethernet going straight past the PCI bus on new motherboards (875?) we are being given a unique chance to utilize remote computing abilities and storage.

CLR is in it's early incarnation as v1.1. When did we all start respecting DirectX (some of us still may not) over openGL as a graphics standard? For me it was probably around DirectX5-7.

Optimizations to the CLR don't have to be done in each language that compiles into it, but in the CLR itself.

In response to some comments about XML usage in .Net, there is definitely going to be a use for XML.

When building BSPs for games, character models, maps, assets, and other game information, we will eventually be able to bring models over from one game to another thanks to a common language (XML) and possibly common framework (.Net).

I'm not a big proponent of .Net currently, it seems to be more of a developing mindset than a language for commercial use right now (as a developer, I infrequently recommend .Net unless there are specific reasons to go with it). Think though how these tools can apply to tomorrows development (both game, application, and networking) methodologies.

Is .NET Relevant to Game Developers? by kewlniss · 2003-04-30 04:17 · Score: 3, Informative

Most definitely, in fact there already is DirectX for .NET -- it is called Managed DirectX. Microsoft developed version 9 to have an entire set of "Managed" components. These are used by the .NET Framework. I have been using the .NET Framework, C# and ASP.NET since October of 2000 (ASP+ at the time and Beta1). I have been using DirectX since version 5 and was involved with the beta testing of the Managed DirectX since June of last year. It was released in December. I am currently writing a 3D level editor and game using C# and Managed DirectX. The code is much more cleaner than typical C++ code. Since memory is managed there aren't any memory leaks and I have found that most things are just fine with that. However, if there is a part of the program that needs to be sped up (which isn't as much as you might think) then it can be done with "unsafe" code within C#, or even talk directly to unmanaged C++ code. Either way, the point is COM programming will be going away -- BUT -- it isn't going to immediate, nor does it need to be. The interops in place allow any COM object to be easily used as a .NET assembly. Don't worry, game development on the Windows OS will not be going anywhere any time soon. .NET will help make more robust games, not hinder.

Sample game written in VB.net by SoCalChris · 2003-04-30 04:18 · Score: 2, Funny

Haven't you people ever played Donkey.Net??? Nothing like driving your car arouns a small 3D area trying to run down donkeys.

Not all windows programs. by blair1q · 2003-04-30 04:18 · Score: 2, Interesting

I've done some .NET work, and it's apparent that it's designed with security in mind (how cleanly only time will tell).

Accordingly, it omits many simple functions that you'll find in other Microsoft libraries that access the machine.

Try changing your screen resolution from within a .NET program. Try just writing the program to do it. Then tell me how you did it, because I couldn't find the API.

Re:.NET is used for game development by egomaniac · 2003-04-30 04:34 · Score: 3, Informative

That's a very misleading statement. Yes, you use Visual Studio .NET, but the XBox does not run CLR code, it runs ordinary native binaries.

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.

--
ZFS: because love is never having to say fsck

NET .COM by KjetilK · 2003-04-30 04:55 · Score: 2, Funny

No, but it has been said that .COM signalled the death of NET... :-)

--
Employee of Inrupt, Project Release Manager and Community Manager for Solid

Re: not the same as with Atari or CBM by ip_vjl · 2003-04-30 04:58 · Score: 4, Insightful

Remember back in the **OLD** days when Atari, Commodore and Apple games weren't launched from the OS, they were loaded from a boot floppy because we really didn't have OS's back then? (Unless you purchased CP/M, of course.)

Well, Knoppix has demonstrated an absolutely ridiculous level of competence at autodetecting hardware, and since . Would the gaming industry consider the possibility of using Linux as a development platform in a trend back to using bootable disks for games?

For those systems, the interactive basic interpreter would probably be considered what most people thought of as the OS.

If I remember correctly, a number of C64 games were launched directly from the basic interpreter.
LOAD "MYPROGRAM, 8, 1"
or something like that.

As far as the Atari, the reason you directly booted into games was that with only 64k of memory in the system, you *needed* to displace the basic interpreter and free up 16k of RAM that it occupied. It still loaded a stub of the DOS (for disk access) and then would autoload any file named AUTORUN.SYS

Additionally, since the OS was ROM based, the systems were "instant on" (or very close). So shutting down the system to play a game (and vice versa) wasn't a huge deal.

Nowadays, I have a computer with 512Mb ram, and it takes a little bit to boot into the OS, so shutting down the system just to play a game seems stupid. As another poster pointed out, thats what consoles are for. For a general purpose computer, not being able to launch games alongside with other apps would be annoying.

Re:.NET is also an IDE, and an optimized C++ compi by Glock27 · 2003-04-30 05:05 · Score: 2, Informative

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

Uh, unless you use DirectX. Which is all COM based.

I prefer cross platform technologies, regardless.

--
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait

Re:Doubtful. by Hideyoshi · 2003-04-30 05:13 · Score: 2, Funny

Dude, it was meant to be a joke! Don't take everything so literally!

Re:Proper implementation would have saved this by quantum+bit · 2003-04-30 06:08 · Score: 2, Funny

I won't use .NET for game development, period. I guess I'm old fashioned, but I like my SDK's as simple as possible, something Microsoft doesn't seem to like making anymore.

But... How would you write efficient code if your functions didn't have helpful names like DDLockBufferAndBlitToSurfaceAndPrayThePointerIsVal id_u ?

Re:We could only hope... by jadams2484 · 2003-04-30 08:28 · Score: 2, Informative

DirectX is more than a graphics library... it has a great input section with DirectInput. You don't have to give up on DirectX to use OpenGL (even the big guys at id software use DirectInput alongside the OpenGL graphics.)

Your problem is thinking of DirectX as a "language" when its not.

.what? by konputer · 2003-04-30 09:00 · Score: 2, Funny

first COM, then .NET, what's next? .ORG? .GOV (forced compliance with PATRIOT act) ..?

OpenGL and .NET by Ridge · 2003-04-30 10:07 · Score: 2, Insightful

So, I worked on CsGL and am doing the new library (which is available as linked off the CsGL homepage). Anyway, from my tests, the .NET examples I've done so far, this includes all of the redbook samples, the majority of the nehe lessons, and a number of others, finds that the .NET versions run between 1-5% slower than the c/c++ versions. Admittedly most of the samples are somewhat simplistic and of course we're ultimately going through the native library and then through (hopefully) hardware accelleration, but to me that's quite acceptable. The main performance issue at this time is array performance, particularly multidimensional arrays, which are extremely slow. However, I understand in the 2.0 version of the .NET framework array performance will be improved, particularly multidimensional arrays.. As always the Mono team is improving performance and support.. Oh I did mention the new OpenGL binding is cross platform didn't I? The new library supports GLUT, as such one could develop cross platform OpenGL apps in their .NET language of choice. It runs fine under Microsoft's runtime as well as Mono on Windows, and I've had reports of many of the samples I've done running under Mono on linux and freebsd. Of course there's bugs (and surprisingly finding linux testers with OpenGL and Mono is like pulling teeth), but hopefully they'll be corrected. It'd also be nice if someone would contribute GLX support, but that's not important for this discussion...

DirectX for .Net? by panic911 · 2003-04-30 11:51 · Score: 2, Informative

Guess you havent seen DirectX 9's changelog. DirectX 9 has native .net support and they produced some pretty good MSDN documentation on implementing DirectX apps with C# and VB.net.

.NET is considerably slower by Headius · 2003-04-30 15:51 · Score: 4, Interesting

Anyone used Visual Studio .NET lately? It's touted as being an amazing piece of work, written mostly in .NET compatible languages and for the .NET platform. And guess what - it's slow. It's noticeably slower than the previous Visual Studios, even the bubblegum version for web and VB developers. In comparison to the previous Visual C++, it's practically standing still.

Furthermore, it's even noticeably slower than, say, Eclipse, a comparable IDE for Java that uses a platform-independent API to native UI widgets, much like .NET does. Visual Studio is not a zippy application.

So keep it C++ but with .NET enhancements you say? Managed C++ is a bloody nightmare. It's really not practical to use it for anything other than tying native C++ code to .NET components. It's also not much easier than using COM components directly, plus you have to limit yourself to .NET management of memory, objects, exceptions, which all add extra cycles you could avoid going totally native.

We're continually fedd technologies from Microsoft that are supposed to be "the next big thing". Look at COM+. Look at ActiveX. The big thing has become old news year after year while other technologies with fewer hard corporate ties expand and proliferate. It's certainly worth learning--Microsoft is pouring the money bucket into .NET very quickly, and there's jobs to be had. Just don't buy into the hype we've been force-fed for the past two years about .NET taking over the world.

No, Virginia, there is no Santa Claus. The emperor is naked.

Wrong question by almaw · 2003-04-30 16:38 · Score: 2, Insightful

Hmmm... it's the wrong question to ask. A much more interesting one is "will there even *be* any major games for PCs in one/two/five years' time?". After all, it's much cheaper developing for xbox, ps2, etc. as you don't have to test on thirty-five different graphics cards, etc. What's more, consoles are steadily increasing in power, and with the advent of consoles with VGA ports and/or HDTV, the last remaining reasons to use a PC for games (higher resolution and a mouse) will go away. Combine that with the cheapness of consoles these days (xbox is now only £130 in the UK, the price of a mid range graphics card for a PC) and what's the point of developing for PC, which has a smaller market and lower returns?

Slashdot Mirror

Is .NET Relevant to Game Developers?

87 of 489 comments (clear)