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?"
Strange... (Score:0, Interesting)
Re:That Giant Sucking Sound... (Score:3, Interesting)
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
Visual Studio .Net is, Managed code is not (Score:2, Interesting)
No, game development will still be the same... (Score:5, Interesting)
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
What exactly is the point of .NET? (Score:2, Interesting)
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
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 and Games - It is a reality (Score:4, Interesting)
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++
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
Re:That Giant Sucking Sound... (Score:0, Interesting)
* you CAN compile to machine code
* many games, like Black and White, use a SCRIPTING ENGINE to implement game logic and fast low-level code to render
Yes, But (Score:5, Interesting)
But, what does that really mean? Good question, Microsoft is backing off from calling everything
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
Bottom line, yes, it will get used because for some developers VS
Steven
Re:Doubtful. (Score:4, Interesting)
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.?
VC++ 7 might work (Score:2, Interesting)
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
C# vs C, DirectX samples (Score:5, Interesting)
The framerates were very similar - the
There doesn't appear to be any huge disadvantage to using
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
- Steve
C++ will NEVER replace assembly in Game Coding!! (Score:5, Interesting)
Well, you can read some books [apress.com] on using DirectX9 for
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)...
Re:Dotnet won't rule the world. (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?
Dependency of .NET framework (Score:4, Interesting)
<plug class="shameless" >
I have written an article called Whats the need for
</plug >
Jalil Vaidya
Yes - but not where you think (Score:5, Interesting)
Tool development takes up an increasing amount of my team's time. We have custom tools for art manipulation, sound manipulation, and data warehousing. Not to mention our tool for level creation, which we hope to release with the game. All of these tools need to be robust, have clean interfaces, and be developed and changed quickly, and grow with the run time modules.
Remember that C# and
I won't go into why C# and
-Donut
Re:Is it really the end of COM? (Score:2, Interesting)
When MS tried to make Java COM/MFC interoperable, Sun sued them. That's why there's now
jliu
Re:maybe developers would wise up then.... (Score:3, Interesting)
Re:.net DirectX (Score:3, Interesting)
FYI, the longhorn APIs will be in the microsoft.* namespace. According to the internal docs, there's a precise distinction between what will go into system.* and what will go into microsoft.*, but basically you can think of it as, system.* goes to ECMA (and thus Mono) and microsoft.* is "intellectual property" (although there are violations on both sides -- system.data.sqlclient.* and microsoft.csharp.* don't fit that pattern.) There's a better definition but I can't remember it, I haven't read the docs for a few months.
But games? Nah, not for a long time. Could be wrong, but there is still a place for unmanaged code in Longhorn. Things like the shell can be managed, but I'd expect 2008 or later before you see a managed code game, just pulling numbers out of my ass.
The framework will be the framework (Score:5, 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.
Re:DirectX 9.0 for Managed Code (its out already) (Score:5, Interesting)
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.
Not all windows programs. (Score:3, Interesting)
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
Re:That Giant Sucking Sound... (Score:5, Interesting)
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.
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... (Score:4, Interesting)
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???
Re:The future (Score:2, Interesting)
.NET is considerably slower (Score:5, Interesting)
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
So keep it C++ but with
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
No, Virginia, there is no Santa Claus. The emperor is naked.